Technique de codage sécurisée : le problème des autorisations personnalisées
Lors du développement pour mobile, les applications doivent souvent demander certaines autorisations au système. Ils peuvent avoir besoin d'accéder aux contacts de l'utilisateur, à la connexion Bluetooth ou de pouvoir envoyer des SMS. Toutes les autorisations mentionnées ci-dessus sont des autorisations de plate-forme, définies par le framework Android.
Mais dans certains cas, cela ne suffit pas et l'application doit définir sa propre autorisation personnalisée. Je vais utiliser notre propre entreprise comme exemple. Secure Code Warrior peut créer une application qui enregistre certaines données privées dans le cadre d'un profil, y compris les performances de l'utilisateur sur la plateforme SCW. Et nous aimerions autoriser une autre application de formation à la sécurité, par exemple DevTrainer, à utiliser ces données si l'utilisateur l'autorise. Il s'agit de données sensibles, l'utilisateur ne voudrait certainement pas que n'importe qui les sache, mais la SCWapp ne doit pas complètement les cacher et les protéger car cela peut être utile. Nous souhaitons donc permettre à l'utilisateur d'en avoir le contrôle. C'est là qu'entrent en jeu les autorisations personnalisées.
Le SCWApp crée une autorisation personnalisée, DevTrainer demande cette autorisation et l'utilisateur peut décider s'il souhaite l'autoriser ou non. Il s'agit d'une pratique courante et d'un bon moyen de restreindre l'accès aux applications figurant sur la liste blanche.
Malheureusement, certains comportements peu intuitifs entourent les autorisations personnalisées, ce qui les rend risquées du point de vue de la sécurité. Des autorisations concrètes et personnalisées peuvent être définies par n'importe quelle application à tout moment, et « le premier gagne », et cette stratégie a des conséquences.
Pour le scénario suivant, nous définissons deux profils d'applications que nous avons présentés ci-dessus (toutes ces applications sont fictives à des fins de démonstration) :
1. Appli SCW: l'application qui définit une autorisation personnalisée et défend un composant à l'aide de cette autorisation.
2. DevTrainer: cette application définit la même autorisation que SCWapp et déclare à l'utilisateur qu'il souhaite détenir cette autorisation.
Il s'agit d'un scénario courant appelé Peer Apps Case. Si l'application DevTrainer n'était qu'un plugin pour SCWapp, elle n'aurait pas à définir l'autorisation personnalisée. Dans ce cas, l'hypothèse est que SCWapp serait installé avant DevTrainer et qu'aucun comportement inattendu ne se produira. Si, d'une manière ou d'une autre, l'utilisateur installe DevTrainer en premier, il n'est pas informé de la demande d'autorisation. Si l'utilisateur installe ensuite SCWapp, l'autorisation n'est pas accordée rétroactivement à DevTrainer. Les tentatives de l'application DevTrainer pour utiliser le composant sécurisé échoueront.
C'est là qu'intervient le Peers App Case. Dans certains cas, vous ne pouvez pas vous attendre à ce qu'une application soit installée avant l'autre. Supposons que si Facebook et Twitter souhaitent tous deux utiliser les composants de l'autre, ils doivent définir les autorisations personnalisées de chacun.
Cependant, c'est là que les choses se compliquent. Si l'application DevTrainer est installée en premier, l'utilisateur n'est pas informé de sa demande d'autorisation personnalisée. À ce stade, même si l'utilisateur n'en a pas été informé, DevTrainer détient l'autorisation personnalisée et peut accéder au composant sécurisé.
Cela devient encore plus délicat. L'application DevTrainer peut modifier le niveau de protection des autorisations. Android n'utilise pas le niveau de protection du défenseur mais le niveau de protection défini en premier, ce qui signifie que l'application installée en premier peut le définir. Cela signifie que si DevTrainer ramène le niveau d'autorisation à la normale, les futures applications qui demanderont cette autorisation n'auront pas à être confirmées par l'utilisateur mais se verront automatiquement accorder l'accès.
Ce scénario a été inspiré par l'explication de ce problème trouvée sur github cwac-security.
La stratégie du « premier gagnant » a des conséquences dangereuses et ne pas connaître son comportement peut amener le développeur à prendre des décisions de sécurité sur la base d'entrées non fiables et à autoriser des applications indésirables à accéder à des données sensibles ou à des services protégés. Pour en savoir plus sur la manière d'éviter de prendre des décisions de sécurité via une saisie non fiable, visitez notre plateforme. Ce comportement a été modifié à partir d'Android 5.0 (Lollipop). Mais depuis ce jour, plus de 22 % Si des appareils Android utilisent toujours une version inférieure d'Android, il est important d'atténuer les risques liés au comportement initial de votre application. Vérifiez si l'autorisation a déjà été définie lors de la première exécution de votre application et, le cas échéant, prenez les mesures appropriées pour résoudre les risques de sécurité.
Bonne chance pour coder, et à la semaine prochaine !
En définissant des autorisations personnalisées, une application peut partager ses ressources et ses fonctionnalités avec d'autres applications.
https://developer.android.com/guide/topics/permissions/defining.html
En définissant des autorisations personnalisées, une application peut partager ses ressources et ses fonctionnalités avec d'autres applications.
Chercheur en sécurité des applications - Ingénieur R&D - Candidat au doctorat
Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchen
Chercheur en sécurité des applications - Ingénieur R&D - Candidat au doctorat
Lors du développement pour mobile, les applications doivent souvent demander certaines autorisations au système. Ils peuvent avoir besoin d'accéder aux contacts de l'utilisateur, à la connexion Bluetooth ou de pouvoir envoyer des SMS. Toutes les autorisations mentionnées ci-dessus sont des autorisations de plate-forme, définies par le framework Android.
Mais dans certains cas, cela ne suffit pas et l'application doit définir sa propre autorisation personnalisée. Je vais utiliser notre propre entreprise comme exemple. Secure Code Warrior peut créer une application qui enregistre certaines données privées dans le cadre d'un profil, y compris les performances de l'utilisateur sur la plateforme SCW. Et nous aimerions autoriser une autre application de formation à la sécurité, par exemple DevTrainer, à utiliser ces données si l'utilisateur l'autorise. Il s'agit de données sensibles, l'utilisateur ne voudrait certainement pas que n'importe qui les sache, mais la SCWapp ne doit pas complètement les cacher et les protéger car cela peut être utile. Nous souhaitons donc permettre à l'utilisateur d'en avoir le contrôle. C'est là qu'entrent en jeu les autorisations personnalisées.
Le SCWApp crée une autorisation personnalisée, DevTrainer demande cette autorisation et l'utilisateur peut décider s'il souhaite l'autoriser ou non. Il s'agit d'une pratique courante et d'un bon moyen de restreindre l'accès aux applications figurant sur la liste blanche.
Malheureusement, certains comportements peu intuitifs entourent les autorisations personnalisées, ce qui les rend risquées du point de vue de la sécurité. Des autorisations concrètes et personnalisées peuvent être définies par n'importe quelle application à tout moment, et « le premier gagne », et cette stratégie a des conséquences.
Pour le scénario suivant, nous définissons deux profils d'applications que nous avons présentés ci-dessus (toutes ces applications sont fictives à des fins de démonstration) :
1. Appli SCW: l'application qui définit une autorisation personnalisée et défend un composant à l'aide de cette autorisation.
2. DevTrainer: cette application définit la même autorisation que SCWapp et déclare à l'utilisateur qu'il souhaite détenir cette autorisation.
Il s'agit d'un scénario courant appelé Peer Apps Case. Si l'application DevTrainer n'était qu'un plugin pour SCWapp, elle n'aurait pas à définir l'autorisation personnalisée. Dans ce cas, l'hypothèse est que SCWapp serait installé avant DevTrainer et qu'aucun comportement inattendu ne se produira. Si, d'une manière ou d'une autre, l'utilisateur installe DevTrainer en premier, il n'est pas informé de la demande d'autorisation. Si l'utilisateur installe ensuite SCWapp, l'autorisation n'est pas accordée rétroactivement à DevTrainer. Les tentatives de l'application DevTrainer pour utiliser le composant sécurisé échoueront.
C'est là qu'intervient le Peers App Case. Dans certains cas, vous ne pouvez pas vous attendre à ce qu'une application soit installée avant l'autre. Supposons que si Facebook et Twitter souhaitent tous deux utiliser les composants de l'autre, ils doivent définir les autorisations personnalisées de chacun.
Cependant, c'est là que les choses se compliquent. Si l'application DevTrainer est installée en premier, l'utilisateur n'est pas informé de sa demande d'autorisation personnalisée. À ce stade, même si l'utilisateur n'en a pas été informé, DevTrainer détient l'autorisation personnalisée et peut accéder au composant sécurisé.
Cela devient encore plus délicat. L'application DevTrainer peut modifier le niveau de protection des autorisations. Android n'utilise pas le niveau de protection du défenseur mais le niveau de protection défini en premier, ce qui signifie que l'application installée en premier peut le définir. Cela signifie que si DevTrainer ramène le niveau d'autorisation à la normale, les futures applications qui demanderont cette autorisation n'auront pas à être confirmées par l'utilisateur mais se verront automatiquement accorder l'accès.
Ce scénario a été inspiré par l'explication de ce problème trouvée sur github cwac-security.
La stratégie du « premier gagnant » a des conséquences dangereuses et ne pas connaître son comportement peut amener le développeur à prendre des décisions de sécurité sur la base d'entrées non fiables et à autoriser des applications indésirables à accéder à des données sensibles ou à des services protégés. Pour en savoir plus sur la manière d'éviter de prendre des décisions de sécurité via une saisie non fiable, visitez notre plateforme. Ce comportement a été modifié à partir d'Android 5.0 (Lollipop). Mais depuis ce jour, plus de 22 % Si des appareils Android utilisent toujours une version inférieure d'Android, il est important d'atténuer les risques liés au comportement initial de votre application. Vérifiez si l'autorisation a déjà été définie lors de la première exécution de votre application et, le cas échéant, prenez les mesures appropriées pour résoudre les risques de sécurité.
Bonne chance pour coder, et à la semaine prochaine !
En définissant des autorisations personnalisées, une application peut partager ses ressources et ses fonctionnalités avec d'autres applications.
https://developer.android.com/guide/topics/permissions/defining.html
Lors du développement pour mobile, les applications doivent souvent demander certaines autorisations au système. Ils peuvent avoir besoin d'accéder aux contacts de l'utilisateur, à la connexion Bluetooth ou de pouvoir envoyer des SMS. Toutes les autorisations mentionnées ci-dessus sont des autorisations de plate-forme, définies par le framework Android.
Mais dans certains cas, cela ne suffit pas et l'application doit définir sa propre autorisation personnalisée. Je vais utiliser notre propre entreprise comme exemple. Secure Code Warrior peut créer une application qui enregistre certaines données privées dans le cadre d'un profil, y compris les performances de l'utilisateur sur la plateforme SCW. Et nous aimerions autoriser une autre application de formation à la sécurité, par exemple DevTrainer, à utiliser ces données si l'utilisateur l'autorise. Il s'agit de données sensibles, l'utilisateur ne voudrait certainement pas que n'importe qui les sache, mais la SCWapp ne doit pas complètement les cacher et les protéger car cela peut être utile. Nous souhaitons donc permettre à l'utilisateur d'en avoir le contrôle. C'est là qu'entrent en jeu les autorisations personnalisées.
Le SCWApp crée une autorisation personnalisée, DevTrainer demande cette autorisation et l'utilisateur peut décider s'il souhaite l'autoriser ou non. Il s'agit d'une pratique courante et d'un bon moyen de restreindre l'accès aux applications figurant sur la liste blanche.
Malheureusement, certains comportements peu intuitifs entourent les autorisations personnalisées, ce qui les rend risquées du point de vue de la sécurité. Des autorisations concrètes et personnalisées peuvent être définies par n'importe quelle application à tout moment, et « le premier gagne », et cette stratégie a des conséquences.
Pour le scénario suivant, nous définissons deux profils d'applications que nous avons présentés ci-dessus (toutes ces applications sont fictives à des fins de démonstration) :
1. Appli SCW: l'application qui définit une autorisation personnalisée et défend un composant à l'aide de cette autorisation.
2. DevTrainer: cette application définit la même autorisation que SCWapp et déclare à l'utilisateur qu'il souhaite détenir cette autorisation.
Il s'agit d'un scénario courant appelé Peer Apps Case. Si l'application DevTrainer n'était qu'un plugin pour SCWapp, elle n'aurait pas à définir l'autorisation personnalisée. Dans ce cas, l'hypothèse est que SCWapp serait installé avant DevTrainer et qu'aucun comportement inattendu ne se produira. Si, d'une manière ou d'une autre, l'utilisateur installe DevTrainer en premier, il n'est pas informé de la demande d'autorisation. Si l'utilisateur installe ensuite SCWapp, l'autorisation n'est pas accordée rétroactivement à DevTrainer. Les tentatives de l'application DevTrainer pour utiliser le composant sécurisé échoueront.
C'est là qu'intervient le Peers App Case. Dans certains cas, vous ne pouvez pas vous attendre à ce qu'une application soit installée avant l'autre. Supposons que si Facebook et Twitter souhaitent tous deux utiliser les composants de l'autre, ils doivent définir les autorisations personnalisées de chacun.
Cependant, c'est là que les choses se compliquent. Si l'application DevTrainer est installée en premier, l'utilisateur n'est pas informé de sa demande d'autorisation personnalisée. À ce stade, même si l'utilisateur n'en a pas été informé, DevTrainer détient l'autorisation personnalisée et peut accéder au composant sécurisé.
Cela devient encore plus délicat. L'application DevTrainer peut modifier le niveau de protection des autorisations. Android n'utilise pas le niveau de protection du défenseur mais le niveau de protection défini en premier, ce qui signifie que l'application installée en premier peut le définir. Cela signifie que si DevTrainer ramène le niveau d'autorisation à la normale, les futures applications qui demanderont cette autorisation n'auront pas à être confirmées par l'utilisateur mais se verront automatiquement accorder l'accès.
Ce scénario a été inspiré par l'explication de ce problème trouvée sur github cwac-security.
La stratégie du « premier gagnant » a des conséquences dangereuses et ne pas connaître son comportement peut amener le développeur à prendre des décisions de sécurité sur la base d'entrées non fiables et à autoriser des applications indésirables à accéder à des données sensibles ou à des services protégés. Pour en savoir plus sur la manière d'éviter de prendre des décisions de sécurité via une saisie non fiable, visitez notre plateforme. Ce comportement a été modifié à partir d'Android 5.0 (Lollipop). Mais depuis ce jour, plus de 22 % Si des appareils Android utilisent toujours une version inférieure d'Android, il est important d'atténuer les risques liés au comportement initial de votre application. Vérifiez si l'autorisation a déjà été définie lors de la première exécution de votre application et, le cas échéant, prenez les mesures appropriées pour résoudre les risques de sécurité.
Bonne chance pour coder, et à la semaine prochaine !
En définissant des autorisations personnalisées, une application peut partager ses ressources et ses fonctionnalités avec d'autres applications.
https://developer.android.com/guide/topics/permissions/defining.html
Klicken Sie auf den untenstehenden Link und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenDemo buchen
Chercheur en sécurité des applications - Ingénieur R&D - Candidat au doctorat
Lors du développement pour mobile, les applications doivent souvent demander certaines autorisations au système. Ils peuvent avoir besoin d'accéder aux contacts de l'utilisateur, à la connexion Bluetooth ou de pouvoir envoyer des SMS. Toutes les autorisations mentionnées ci-dessus sont des autorisations de plate-forme, définies par le framework Android.
Mais dans certains cas, cela ne suffit pas et l'application doit définir sa propre autorisation personnalisée. Je vais utiliser notre propre entreprise comme exemple. Secure Code Warrior peut créer une application qui enregistre certaines données privées dans le cadre d'un profil, y compris les performances de l'utilisateur sur la plateforme SCW. Et nous aimerions autoriser une autre application de formation à la sécurité, par exemple DevTrainer, à utiliser ces données si l'utilisateur l'autorise. Il s'agit de données sensibles, l'utilisateur ne voudrait certainement pas que n'importe qui les sache, mais la SCWapp ne doit pas complètement les cacher et les protéger car cela peut être utile. Nous souhaitons donc permettre à l'utilisateur d'en avoir le contrôle. C'est là qu'entrent en jeu les autorisations personnalisées.
Le SCWApp crée une autorisation personnalisée, DevTrainer demande cette autorisation et l'utilisateur peut décider s'il souhaite l'autoriser ou non. Il s'agit d'une pratique courante et d'un bon moyen de restreindre l'accès aux applications figurant sur la liste blanche.
Malheureusement, certains comportements peu intuitifs entourent les autorisations personnalisées, ce qui les rend risquées du point de vue de la sécurité. Des autorisations concrètes et personnalisées peuvent être définies par n'importe quelle application à tout moment, et « le premier gagne », et cette stratégie a des conséquences.
Pour le scénario suivant, nous définissons deux profils d'applications que nous avons présentés ci-dessus (toutes ces applications sont fictives à des fins de démonstration) :
1. Appli SCW: l'application qui définit une autorisation personnalisée et défend un composant à l'aide de cette autorisation.
2. DevTrainer: cette application définit la même autorisation que SCWapp et déclare à l'utilisateur qu'il souhaite détenir cette autorisation.
Il s'agit d'un scénario courant appelé Peer Apps Case. Si l'application DevTrainer n'était qu'un plugin pour SCWapp, elle n'aurait pas à définir l'autorisation personnalisée. Dans ce cas, l'hypothèse est que SCWapp serait installé avant DevTrainer et qu'aucun comportement inattendu ne se produira. Si, d'une manière ou d'une autre, l'utilisateur installe DevTrainer en premier, il n'est pas informé de la demande d'autorisation. Si l'utilisateur installe ensuite SCWapp, l'autorisation n'est pas accordée rétroactivement à DevTrainer. Les tentatives de l'application DevTrainer pour utiliser le composant sécurisé échoueront.
C'est là qu'intervient le Peers App Case. Dans certains cas, vous ne pouvez pas vous attendre à ce qu'une application soit installée avant l'autre. Supposons que si Facebook et Twitter souhaitent tous deux utiliser les composants de l'autre, ils doivent définir les autorisations personnalisées de chacun.
Cependant, c'est là que les choses se compliquent. Si l'application DevTrainer est installée en premier, l'utilisateur n'est pas informé de sa demande d'autorisation personnalisée. À ce stade, même si l'utilisateur n'en a pas été informé, DevTrainer détient l'autorisation personnalisée et peut accéder au composant sécurisé.
Cela devient encore plus délicat. L'application DevTrainer peut modifier le niveau de protection des autorisations. Android n'utilise pas le niveau de protection du défenseur mais le niveau de protection défini en premier, ce qui signifie que l'application installée en premier peut le définir. Cela signifie que si DevTrainer ramène le niveau d'autorisation à la normale, les futures applications qui demanderont cette autorisation n'auront pas à être confirmées par l'utilisateur mais se verront automatiquement accorder l'accès.
Ce scénario a été inspiré par l'explication de ce problème trouvée sur github cwac-security.
La stratégie du « premier gagnant » a des conséquences dangereuses et ne pas connaître son comportement peut amener le développeur à prendre des décisions de sécurité sur la base d'entrées non fiables et à autoriser des applications indésirables à accéder à des données sensibles ou à des services protégés. Pour en savoir plus sur la manière d'éviter de prendre des décisions de sécurité via une saisie non fiable, visitez notre plateforme. Ce comportement a été modifié à partir d'Android 5.0 (Lollipop). Mais depuis ce jour, plus de 22 % Si des appareils Android utilisent toujours une version inférieure d'Android, il est important d'atténuer les risques liés au comportement initial de votre application. Vérifiez si l'autorisation a déjà été définie lors de la première exécution de votre application et, le cas échéant, prenez les mesures appropriées pour résoudre les risques de sécurité.
Bonne chance pour coder, et à la semaine prochaine !
En définissant des autorisations personnalisées, une application peut partager ses ressources et ses fonctionnalités avec d'autres applications.
https://developer.android.com/guide/topics/permissions/defining.html
Inhaltsverzeichnis
Chercheur en sécurité des applications - Ingénieur R&D - Candidat au doctorat
Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen, die Ihnen den Einstieg erleichtern
Themen und Inhalte der Schulung zum sicheren Code
Unsere hochmodernen Inhalte werden ständig weiterentwickelt, um mit den ständigen Veränderungen in der Softwareentwicklungslandschaft Schritt zu halten und gleichzeitig Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis hin zu XQuery-Injection und sind für eine Vielzahl von Positionen konzipiert, von Architekten über Ingenieure bis hin zu Produktmanagern und Qualitätssicherungsmitarbeitern. Verschaffen Sie sich einen Überblick über die Inhalte unseres Katalogs, sortiert nach Themen und Rollen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen, die Ihnen den Einstieg erleichtern
Cybermon ist zurück: Die missions „Beat the Boss“ sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzen Sie fortschrittliche Sicherheitsherausforderungen im Zusammenhang mit KI und LLM ein, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet das für die Entwicklung sicherer Software bereits ab der Konzeption?
Entdecken Sie, was das europäische Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams durch Sicherheitsmaßnahmen bereits in der Entwurfsphase, durch die Vermeidung von Schwachstellen und durch die Stärkung der Fähigkeiten der Entwickler darauf vorbereiten können.
Moderator 1: Definierte und messbare Erfolgskriterien
Enabler 1 gibt den Startschuss für unsere 10-teilige Serie mit dem Titel „Enablers of Success“ und zeigt, wie sichere Codierung mit geschäftlichen Ergebnissen wie Risikominderung und Schnelligkeit kombiniert werden kann, um die langfristige Reife von Programmen sicherzustellen.
