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 aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.
Reserve una demostración
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
Haga clic en el enlace siguiente y descargue el PDF de este recurso.
Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.
Mostrar el informeReserve una demostración
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
Índice
Chercheur en sécurité des applications - Ingénieur R&D - Candidat au doctorat
Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.
Reserve una demostraciónDescargarRecursos para ayudarle a empezar
Temas y contenidos de formación sobre el código seguro
Nuestro contenido de vanguardia evoluciona constantemente para adaptarse al panorama en constante cambio del desarrollo de software, teniendo en cuenta su función. Temas que abarcan desde la IA hasta la inyección de XQuery, ofrecidos para una variedad de puestos, desde arquitectos hasta ingenieros, pasando por jefes de producto y control de calidad. Descubra una visión general de lo que nuestro catálogo de contenidos tiene para ofrecer por tema y por función.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
%20(1).avif)
.avif)
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
Recursos para ayudarle a empezar
Cybermon está de vuelta: las missions Beat the Boss ya están disponibles bajo demanda.
Cybermon 2025 Beat the Boss ya está disponible todo el año en SCW. Implemente desafíos de seguridad avanzados relacionados con la IA y el LLM para reforzar el desarrollo seguro de la IA a gran escala.
Explicación de la ley sobre ciberresiliencia: lo que significa para el desarrollo de software seguro desde el diseño.
Descubra qué exige la ley europea sobre ciberresiliencia (CRA), a quién se aplica y cómo los equipos de ingenieros pueden prepararse mediante prácticas de seguridad desde el diseño, la prevención de vulnerabilidades y el refuerzo de las capacidades de los desarrolladores.
Facilitador 1: Criterios de éxito definidos y medibles
El facilitador 1 da inicio a nuestra serie de 10 partes titulada «Facilitadores del éxito», mostrando cómo combinar la codificación segura con resultados comerciales, como la reducción de riesgos y la rapidez, para garantizar la madurez a largo plazo de los programas.
