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 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約する
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 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。
レポートを表示するデモを予約する
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 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約するダウンロード
%20(1).avif)
.avif)
