owasp mobile top 2016
1.0.0
OWASP Mobile Top 10 2016 LISTE:
Cette catégorie couvre l'utilisation abusive d'une fonctionnalité de plate-forme ou l'échec de l'utilisation des contrôles de sécurité de la plate-forme. Il peut inclure des intentions Android, des autorisations de plate-forme, une mauvaise utilisation de TouchID, le porte-clés ou un autre contrôle de sécurité qui fait partie du système d'exploitation mobile. Il existe plusieurs façons dont les applications mobiles peuvent ressentir ce risque.
Cette nouvelle catégorie est une combinaison de M2 + M4 du Top Ten 2014 mobile.
Cela couvre une mauvaise étagère, des versions SSL incorrectes, une négociation faible, une communication en texte clair des actifs sensibles, etc.
Cette catégorie capture les notions d'authentification de l'utilisateur final ou de la mauvaise gestion de session. Cela peut inclure:
Le code applique la cryptographie à un actif d'information sensible. Cependant, la cryptographie est insuffisante d'une manière ou d'une autre. Notez que tout et tout ce qui concerne TLS ou SSL va dans M3. De plus, si l'application n'utilise pas du tout la cryptographie quand elle le devrait, cela appartient probablement à M2. Cette catégorie est destinée aux problèmes où la cryptographie a été tentée, mais elle n'a pas été fait correctement.
Il s'agit d'une catégorie pour saisir tout échec dans l'autorisation (par exemple, les décisions d'autorisation du côté client, la navigation forcée, etc.). Il est distinct des problèmes d'authentification (par exemple, inscription de l'appareil, identification de l'utilisateur, etc.).
Si l'application n'authentifie pas du tout les utilisateurs dans une situation où elle devrait (par exemple, l'octroi d'un accès anonyme à certaines ressources ou services lorsque l'accès authentifié et autorisé est requis), il s'agit d'un échec d'authentification et non d'un échec d'autorisation.
Il s'agissait des «décisions de sécurité via des intrants non fiables», l'une de nos catégories moins utilisées. Ce serait le fourre-tout pour les problèmes d'implémentation au niveau du code dans le client mobile. C'est distinct des erreurs de codage côté serveur. Cela capturerait des choses comme les débordements de tampon, les vulnérabilités de chaîne de format et diverses autres erreurs de niveau de code où la solution consiste à réécrire un code qui s'exécute sur l'appareil mobile.
Cette catégorie couvre le correctif binaire, la modification des ressources locales, le crochet de méthode, le swizzling de méthode et la modification de la mémoire dynamique.
Une fois l'application livrée à l'appareil mobile, le code et les ressources de données y résident. Un attaquant peut soit modifier directement le code, modifier dynamiquement le contenu de la mémoire, modifier ou remplacer les API système utilisées par l'application, soit modifier les données et les ressources de l'application. Cela peut fournir à l'attaquant une méthode directe de renversement de l'utilisation prévue du logiciel pour un gain personnel ou monétaire.
Cette catégorie comprend une analyse du binaire de noyau final pour déterminer son code source, ses bibliothèques, ses algorithmes et ses autres actifs. Des logiciels tels que IDA Pro, Hopper, Otool et d'autres outils d'inspection binaire donnent à l'attaquant un aperçu du fonctionnement interne de l'application. Cela peut être utilisé pour exploiter d'autres vulnérabilités naissantes dans l'application, ainsi que pour révéler des informations sur les serveurs arrière, les constantes cryptographiques et les chiffres et la propriété intellectuelle.
Souvent, les développeurs comprennent une fonctionnalité de porte dérobée cachée ou d'autres contrôles de sécurité du développement interne qui ne sont pas destinés à être libérés dans un environnement de production. Par exemple, un développeur peut inclure accidentellement un mot de passe comme commentaire dans une application hybride. Un autre exemple comprend la désactivation de l'authentification à 2 facteurs lors des tests.
