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 귀사의 조직이 소프트웨어 개발 주기 전반에 걸쳐 코드를 안전하게 보호하고 사이버보안이 최우선 과제인 문화를 조성하도록 Secure Code Warrior . 애플리케이션 보안 담당자, 개발자, IT 보안 책임자 또는 보안 관련 업무에 종사하는 모든 분들을 위해, 저희는 귀사의 조직이 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.
데모 예약하기
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
아래 링크를 클릭하고 이 자료의 PDF를 다운로드하세요.
Secure Code Warrior 귀사의 조직이 소프트웨어 개발 주기 전반에 걸쳐 코드를 안전하게 보호하고 사이버보안이 최우선 과제인 문화를 조성하도록 Secure Code Warrior . 애플리케이션 보안 담당자, 개발자, IT 보안 책임자 또는 보안 관련 업무에 종사하는 모든 분들을 위해, 저희는 귀사의 조직이 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.
보고서 표시데모 예약하기
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
목차
Chercheur en sécurité des applications - Ingénieur R&D - Candidat au doctorat
Secure Code Warrior 귀사의 조직이 소프트웨어 개발 주기 전반에 걸쳐 코드를 안전하게 보호하고 사이버보안이 최우선 과제인 문화를 조성하도록 Secure Code Warrior . 애플리케이션 보안 담당자, 개발자, IT 보안 책임자 또는 보안 관련 업무에 종사하는 모든 분들을 위해, 저희는 귀사의 조직이 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.
데모 예약하기Télécharger
%20(1).avif)
.avif)
