Secure coding technique: The Custom Permission Problem
When developing for mobile, applications often have to request some permissions from the system. They might need access to the user's contacts, to the Bluetooth connection or the ability to send SMS messages. All of the permissions mentioned above are platform permissions, defined by the Android framework.
But there are cases for when these don't suffice and the application needs to define their own custom permission. I'll use our own company as an example. Secure Code Warrior might create an app that saves some private data as part of a profile, including the user's performance on the SCW platform. And we would like to allow another security training app, say DevTrainer, to use this data if the user gives them permission to do this. This is sensitive data, the user certainly wouldn't want just anybody to know this, but the SCWApp shouldn't completely hide and protect it as it might be useful. So we wish to let the user have control over it. This is where custom permissions come in.
The SCWApp creates a custom permission, DevTrainer requests this permission and the user can decide whether he wants to allow this or not. This is a common practice and a good way to restrict access to white-listed applications.
Unfortunately, there are some unintuitive behaviors around custom permissions which makes them risky from a security standpoint. Concrete, custom permissions can be defined by any app at any time, and "first one wins", and this strategy comes with some consequences.
For the following scenario, we define two app profiles which we introduced above (all of these applications are fictional for demonstrative purposes):
1. SCWApp: the app that defines a custom permission and defends a component using this permission.
2. DevTrainer: this app defines the same permission as SCWApp and declares to the user that it wishes to hold this permission.
This is a common scenario coined the Peer Apps Case. If the DevTrainer app was just a plugin for the SCWApp it would not have to define the custom permission. The assumption, in this case, is that SCWApp would be installed before DevTrainer and no unexpected behavior will happen. If somehow the user does install DevTrainer first, the user is not informed about the request for the permission. If the user then later installs SCWApp, DevTrainer is not retroactively granted the permission, so the DevTrainer app's attempts at using the secured component will fail.
This is where the Peers App Case comes in. In some cases, you cannot expect one app to be installed before the other. Say if Facebook and Twitter both want to use each other's components, they have to define each other's custom permissions.
However, this is where it gets tricky. If the DevTrainer app is installed first, the user is not informed about its request for the custom permission. At this point, even though the user was not informed, DevTrainer holds the custom permission and can access the secured component.
It gets even trickier. The DevTrainer app can change the permissions protection level. Android does not use the defender's protection level but the protection level that is defined first, meaning whichever app was installed first can define it. This means that if DevTrainer changes the permission level to normal, then any future apps that request this permission will not have to be confirmed by the user but are automatically granted access.
This scenario was inspired by the explanation for this problem found on the cwac-security github.
The "first one wins" strategy has some dangerous consequences and not knowing its behavior might lead the developer to make security decisions based on untrusted input and allow unintended apps to access sensitive data or protected services. To learn more about avoiding security decisions via untrusted input, visit our platform. This behavior was changed as of Android 5.0 (Lollipop). But since currently, more than 22% of Android devices are still running a lower version of Android it is important to mitigate the risks of the original behavior in your app. Check if the permission has already been defined at the first run of your app and take appropriate actions if this is the case to resolve any security risks.
Good luck coding, and see you next week!
By defining custom permissions, an app can share its resources and capabilities with other apps.
https://developer.android.com/guide/topics/permissions/defining.html
By defining custom permissions, an app can share its resources and capabilities with other apps.
Application Security Researcher - R&D Engineer - PhD Candidate
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo
Application Security Researcher - R&D Engineer - PhD Candidate
When developing for mobile, applications often have to request some permissions from the system. They might need access to the user's contacts, to the Bluetooth connection or the ability to send SMS messages. All of the permissions mentioned above are platform permissions, defined by the Android framework.
But there are cases for when these don't suffice and the application needs to define their own custom permission. I'll use our own company as an example. Secure Code Warrior might create an app that saves some private data as part of a profile, including the user's performance on the SCW platform. And we would like to allow another security training app, say DevTrainer, to use this data if the user gives them permission to do this. This is sensitive data, the user certainly wouldn't want just anybody to know this, but the SCWApp shouldn't completely hide and protect it as it might be useful. So we wish to let the user have control over it. This is where custom permissions come in.
The SCWApp creates a custom permission, DevTrainer requests this permission and the user can decide whether he wants to allow this or not. This is a common practice and a good way to restrict access to white-listed applications.
Unfortunately, there are some unintuitive behaviors around custom permissions which makes them risky from a security standpoint. Concrete, custom permissions can be defined by any app at any time, and "first one wins", and this strategy comes with some consequences.
For the following scenario, we define two app profiles which we introduced above (all of these applications are fictional for demonstrative purposes):
1. SCWApp: the app that defines a custom permission and defends a component using this permission.
2. DevTrainer: this app defines the same permission as SCWApp and declares to the user that it wishes to hold this permission.
This is a common scenario coined the Peer Apps Case. If the DevTrainer app was just a plugin for the SCWApp it would not have to define the custom permission. The assumption, in this case, is that SCWApp would be installed before DevTrainer and no unexpected behavior will happen. If somehow the user does install DevTrainer first, the user is not informed about the request for the permission. If the user then later installs SCWApp, DevTrainer is not retroactively granted the permission, so the DevTrainer app's attempts at using the secured component will fail.
This is where the Peers App Case comes in. In some cases, you cannot expect one app to be installed before the other. Say if Facebook and Twitter both want to use each other's components, they have to define each other's custom permissions.
However, this is where it gets tricky. If the DevTrainer app is installed first, the user is not informed about its request for the custom permission. At this point, even though the user was not informed, DevTrainer holds the custom permission and can access the secured component.
It gets even trickier. The DevTrainer app can change the permissions protection level. Android does not use the defender's protection level but the protection level that is defined first, meaning whichever app was installed first can define it. This means that if DevTrainer changes the permission level to normal, then any future apps that request this permission will not have to be confirmed by the user but are automatically granted access.
This scenario was inspired by the explanation for this problem found on the cwac-security github.
The "first one wins" strategy has some dangerous consequences and not knowing its behavior might lead the developer to make security decisions based on untrusted input and allow unintended apps to access sensitive data or protected services. To learn more about avoiding security decisions via untrusted input, visit our platform. This behavior was changed as of Android 5.0 (Lollipop). But since currently, more than 22% of Android devices are still running a lower version of Android it is important to mitigate the risks of the original behavior in your app. Check if the permission has already been defined at the first run of your app and take appropriate actions if this is the case to resolve any security risks.
Good luck coding, and see you next week!
By defining custom permissions, an app can share its resources and capabilities with other apps.
https://developer.android.com/guide/topics/permissions/defining.html
When developing for mobile, applications often have to request some permissions from the system. They might need access to the user's contacts, to the Bluetooth connection or the ability to send SMS messages. All of the permissions mentioned above are platform permissions, defined by the Android framework.
But there are cases for when these don't suffice and the application needs to define their own custom permission. I'll use our own company as an example. Secure Code Warrior might create an app that saves some private data as part of a profile, including the user's performance on the SCW platform. And we would like to allow another security training app, say DevTrainer, to use this data if the user gives them permission to do this. This is sensitive data, the user certainly wouldn't want just anybody to know this, but the SCWApp shouldn't completely hide and protect it as it might be useful. So we wish to let the user have control over it. This is where custom permissions come in.
The SCWApp creates a custom permission, DevTrainer requests this permission and the user can decide whether he wants to allow this or not. This is a common practice and a good way to restrict access to white-listed applications.
Unfortunately, there are some unintuitive behaviors around custom permissions which makes them risky from a security standpoint. Concrete, custom permissions can be defined by any app at any time, and "first one wins", and this strategy comes with some consequences.
For the following scenario, we define two app profiles which we introduced above (all of these applications are fictional for demonstrative purposes):
1. SCWApp: the app that defines a custom permission and defends a component using this permission.
2. DevTrainer: this app defines the same permission as SCWApp and declares to the user that it wishes to hold this permission.
This is a common scenario coined the Peer Apps Case. If the DevTrainer app was just a plugin for the SCWApp it would not have to define the custom permission. The assumption, in this case, is that SCWApp would be installed before DevTrainer and no unexpected behavior will happen. If somehow the user does install DevTrainer first, the user is not informed about the request for the permission. If the user then later installs SCWApp, DevTrainer is not retroactively granted the permission, so the DevTrainer app's attempts at using the secured component will fail.
This is where the Peers App Case comes in. In some cases, you cannot expect one app to be installed before the other. Say if Facebook and Twitter both want to use each other's components, they have to define each other's custom permissions.
However, this is where it gets tricky. If the DevTrainer app is installed first, the user is not informed about its request for the custom permission. At this point, even though the user was not informed, DevTrainer holds the custom permission and can access the secured component.
It gets even trickier. The DevTrainer app can change the permissions protection level. Android does not use the defender's protection level but the protection level that is defined first, meaning whichever app was installed first can define it. This means that if DevTrainer changes the permission level to normal, then any future apps that request this permission will not have to be confirmed by the user but are automatically granted access.
This scenario was inspired by the explanation for this problem found on the cwac-security github.
The "first one wins" strategy has some dangerous consequences and not knowing its behavior might lead the developer to make security decisions based on untrusted input and allow unintended apps to access sensitive data or protected services. To learn more about avoiding security decisions via untrusted input, visit our platform. This behavior was changed as of Android 5.0 (Lollipop). But since currently, more than 22% of Android devices are still running a lower version of Android it is important to mitigate the risks of the original behavior in your app. Check if the permission has already been defined at the first run of your app and take appropriate actions if this is the case to resolve any security risks.
Good luck coding, and see you next week!
By defining custom permissions, an app can share its resources and capabilities with other apps.
https://developer.android.com/guide/topics/permissions/defining.html
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demo
Application Security Researcher - R&D Engineer - PhD Candidate
When developing for mobile, applications often have to request some permissions from the system. They might need access to the user's contacts, to the Bluetooth connection or the ability to send SMS messages. All of the permissions mentioned above are platform permissions, defined by the Android framework.
But there are cases for when these don't suffice and the application needs to define their own custom permission. I'll use our own company as an example. Secure Code Warrior might create an app that saves some private data as part of a profile, including the user's performance on the SCW platform. And we would like to allow another security training app, say DevTrainer, to use this data if the user gives them permission to do this. This is sensitive data, the user certainly wouldn't want just anybody to know this, but the SCWApp shouldn't completely hide and protect it as it might be useful. So we wish to let the user have control over it. This is where custom permissions come in.
The SCWApp creates a custom permission, DevTrainer requests this permission and the user can decide whether he wants to allow this or not. This is a common practice and a good way to restrict access to white-listed applications.
Unfortunately, there are some unintuitive behaviors around custom permissions which makes them risky from a security standpoint. Concrete, custom permissions can be defined by any app at any time, and "first one wins", and this strategy comes with some consequences.
For the following scenario, we define two app profiles which we introduced above (all of these applications are fictional for demonstrative purposes):
1. SCWApp: the app that defines a custom permission and defends a component using this permission.
2. DevTrainer: this app defines the same permission as SCWApp and declares to the user that it wishes to hold this permission.
This is a common scenario coined the Peer Apps Case. If the DevTrainer app was just a plugin for the SCWApp it would not have to define the custom permission. The assumption, in this case, is that SCWApp would be installed before DevTrainer and no unexpected behavior will happen. If somehow the user does install DevTrainer first, the user is not informed about the request for the permission. If the user then later installs SCWApp, DevTrainer is not retroactively granted the permission, so the DevTrainer app's attempts at using the secured component will fail.
This is where the Peers App Case comes in. In some cases, you cannot expect one app to be installed before the other. Say if Facebook and Twitter both want to use each other's components, they have to define each other's custom permissions.
However, this is where it gets tricky. If the DevTrainer app is installed first, the user is not informed about its request for the custom permission. At this point, even though the user was not informed, DevTrainer holds the custom permission and can access the secured component.
It gets even trickier. The DevTrainer app can change the permissions protection level. Android does not use the defender's protection level but the protection level that is defined first, meaning whichever app was installed first can define it. This means that if DevTrainer changes the permission level to normal, then any future apps that request this permission will not have to be confirmed by the user but are automatically granted access.
This scenario was inspired by the explanation for this problem found on the cwac-security github.
The "first one wins" strategy has some dangerous consequences and not knowing its behavior might lead the developer to make security decisions based on untrusted input and allow unintended apps to access sensitive data or protected services. To learn more about avoiding security decisions via untrusted input, visit our platform. This behavior was changed as of Android 5.0 (Lollipop). But since currently, more than 22% of Android devices are still running a lower version of Android it is important to mitigate the risks of the original behavior in your app. Check if the permission has already been defined at the first run of your app and take appropriate actions if this is the case to resolve any security risks.
Good luck coding, and see you next week!
By defining custom permissions, an app can share its resources and capabilities with other apps.
https://developer.android.com/guide/topics/permissions/defining.html
Table of contents
Application Security Researcher - R&D Engineer - PhD Candidate
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Secure by Design: Defining Best Practices, Enabling Developers and Benchmarking Preventative Security Outcomes
In this research paper, Secure Code Warrior co-founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., along with expert contributors, Chris Inglis, Former US National Cyber Director (now Strategic Advisor to Paladin Capital Group), and Devin Lynch, Senior Director, Paladin Global Institute, will reveal key findings from over twenty in-depth interviews with enterprise security leaders including CISOs, a VP of Application Security, and software security professionals.
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
Finding meaningful data on the success of Secure-by-Design initiatives is notoriously difficult. CISOs are often challenged when attempting to prove the return on investment (ROI) and business value of security program activities at both the people and company levels. Not to mention, it’s particularly difficult for enterprises to gain insights into how their organizations are benchmarked against current industry standards. The President’s National Cybersecurity Strategy challenged stakeholders to “embrace security and resilience by design.” The key to making Secure-by-Design initiatives work is not only giving developers the skills to ensure secure code, but also assuring the regulators that those skills are in place. In this presentation, we share a myriad of qualitative and quantitative data, derived from multiple primary sources, including internal data points collected from over 250,000 developers, data-driven customer insights, and public studies. Leveraging this aggregation of data points, we aim to communicate a vision of the current state of Secure-by-Design initiatives across multiple verticals. The report details why this space is currently underutilized, the significant impact a successful upskilling program can have on cybersecurity risk mitigation, and the potential to eliminate categories of vulnerabilities from a codebase.
Resources to get you started
Revealed: How the Cyber Industry Defines Secure by Design
In our latest white paper, our Co-Founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., sat down with over twenty enterprise security leaders, including CISOs, AppSec leaders and security professionals, to figure out the key pieces of this puzzle and uncover the reality behind the Secure by Design movement. It’s a shared ambition across the security teams, but no shared playbook.
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
