Sichere Codierungstechnik: Das Problem mit benutzerdefinierten Berechtigungen
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
Durch die Definition benutzerdefinierter Berechtigungen kann eine App ihre Ressourcen und Funktionen mit anderen Apps teilen.
Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchen
Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand
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
Klicken Sie auf den Link unten und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenEine Demo buchen
Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand
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
Inhaltsverzeichniss
Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Securecode-Schulung
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um der sich ständig ändernden Softwareentwicklungslandschaft unter Berücksichtigung Ihrer Rolle gerecht zu werden. Themen, die alles von KI bis XQuery Injection abdecken und für eine Vielzahl von Rollen angeboten werden, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Einblick in das Angebot unseres Inhaltskatalogs nach Themen und Rollen.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Ressourcen für den Einstieg
Cybermon is back: Beat the Boss KI-Missionen jetzt auf Abruf verfügbar
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzt fortschrittliche KI/LLM-Sicherheitsanforderungen ein, um die sichere KI-Entwicklung in einem großen Maßstab zu stärken.
Cyber-Resilienz-Gesetz erklärt: Was das für die Entwicklung von Secure by Design-Software bedeutet
Erfahren Sie, was der EU Cyber Resilience Act (CRA) verlangt, für wen er gilt und wie sich Entwicklungsteams mit sicheren Methoden, der Vorbeugung von Sicherheitslücken und dem Aufbau von Fähigkeiten für Entwickler darauf vorbereiten können.
