2012 11-07-owasp mobile top10 v01

The OWASP Foundation
http://www.owasp.org

OWASP Top10 Mobile
Risks
Sébastien Gioria
OWASP France Leader
OWASP Global Education Committee

Applica'on*Security*Forum*3*2012*
Western'Switzerland'
'
708'novembre'2012'0'Y0Parc'/'Yverdon0les0Bains'
Permission is h?ps://www.appsec0forum.ch' the terms of the OWASP License.
Copyright © The OWASP Foundation
granted to copy, distribute and/or modify this document under

Saturday, November 10, 12

http://www.google.fr/#q=sebastien gioria
‣Responsable de la branche Audit S.I et Sécurité
au sein du cabinet Groupe Y

‣OWASP France Leader & Founder - Evangéliste
‣OWASP Global Education Comittee Member
(sebastien.gioria@owasp.org)

‣Responsable du Groupe Sécurité des
Applications Web au CLUSIF
Twitter :@SPoint

CISA && ISO 27005 Risk Manager

‣ +13 ans d’expérience en Sécurité des Systèmes d’Information
‣ Différents postes de manager SSI dans la banque, l’assurance et les télécoms
‣ Expertise Technique
- PenTesting,
- Secure-SDLC
- Gestion du risque, Architectures fonctionnelles, Audits
- Consulting et Formation en Réseaux et Sécurité
'
Western'Switzerland' 2
2
h?ps://www.appsec0forum.ch'


Top 10 Risques

'


Top 10 Risques
• Vision multi-plateforme :
• Android, IOS, Nokia, Windows, ...
• Focus sur les risques plutôt que les
vulnérabilités.
• Utilisation de l’OWASP Risk Rating
Methodology pour le classement
• https://www.owasp.org/index.php/
OWASP_Risk_Rating_Methodology
'

4


Les 10 risques
Risque
M1 - Stockage de données non sécurisé

M2 - Contrôles serveur défaillants

M3 - Protection insuffisante lors du transport de données

M4 - Injection client

M5 - Authentification et habilitation defaillante

M6 - Mauvaise gestion des sessions

M7- Utilisation de données d’entrée pour effectuer des décisions sécurité.

M8 - Perte de données via des canaux cachés

M9 - Chiffrement défectueux

M10 - Perte d’information sensible
'

5


'

6



• Les données sensibles ne sont pas Impact
protégées
• Perte de
• S’applique aux données locales, tout confidentialité sur
comme celles disponibles dans le cloud
les données
• Généralement du à :
• Divulgation
• Défaut de chiffrement des données
d’authentifiants
• Cache de données qui n’est pas
généralement prévu • Violation de vie
• Permissions globales ou faibles privée
• Non suivi des bonnes pratiques de la • Non-compliance
plateforme
'

7



'

8


M1 - Prévention

'

9


M1 - Prévention

1. Ne stocker que ce qui est réellement
nécessaire

'

9


M1 - Prévention

nécessaire
2. Ne jamais stocker de données sur des
éléments publics (SD-Card...)

'

9


M1 - Prévention

nécessaire
3. Utiliser les APIs de chiffrement et les
conteneurs sécurisés fournis par la plateforme.

'

9


M1 - Prévention

nécessaire
3. Utiliser les APIs de chiffrement et les
conteneurs sécurisés fournis par la plateforme.
4. Ne pas donner des droits en “world writeable”
ou “world readable”
'

9


'

10


M2- Contrôles serveur défaillants

• S’applique uniquement aux Impact
services de backend.
• Perte de
• Non spécifique aux mobiles. confidentialité
sur des
• Il n’est pas plus facile de
données
faire confiance au client.
• Il est nécessaire de revoir les • Perte
d’intégrité sur
contrôles actuels classiques.
des données
'

11


M2 - Contrôles serveur défaillants

OWASP Top 10 OWASP Cloud Top 10

• https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project • https://www.owasp.org/images/4/47/Cloud-
Top10-Security-Risks.pdf
'

12


M2- Prévention

'

13


M2- Prévention

1. Comprendre les nouveaux risques induits par
les applications mobiles sur les architectures
existantes

'

13


M2- Prévention

existantes

3. OWASP Top 10, Cloud Top 10, Web Services Top 10

'

13


M2- Prévention

existantes

3. OWASP Top 10, Cloud Top 10, Web Services Top 10

5. Voir les Cheat sheets, guides de développement,
l’ESAPI
'

13


'

14


M3 - Protection insuffisante lors du
transport de données
• Perte complète de chiffrement Impact
des données transmises.
• Attacks MITM
• Faible chiffrement des
données transmises.
• Modification
des données
• Fort chiffrement, mais oubli transmises
des alertes sécurité
• Perte de
• Ignorer les erreurs de validation de certificats
confidentialité
• Retour en mode non chiffré après erreurs

'

15


M3 - Protection insuffisante lors du
transport de données
Exemple : Protocole d’authentification des clients
Google
• L’entete d’authentification est envoyé sur HTTP
• Lorsqu’un utilisateur se connecte via un WIFI,
l’application automatiquement envoie le jeton dans
le but de synchroniser les données depuis le serveur.
• Il suffit d’écouter le réseau et de voler cet élément
pour usurper l’identité
• http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html

'

16


M3 - Prévention

'

17


M3 - Prévention

1. Vérifier que les données sensibles quittent
l’appareil chiffrées.

'

17


M3 - Prévention

2. Quelque soit les données et les réseaux : Wifi,
NFC( coucou Renaud :) ), GSM, ....

'

17


M3 - Prévention

2. Quelque soit les données et les réseaux : Wifi,
NFC( coucou Renaud :) ), GSM, ....
3. Ne pas ignorer les erreurs de sécurité !

'

17


'

18


M4- Injection Client
• Utilisation des fonctions de Impact
navigateurs dans les applications
• Apps pure Web
• Compromissio
• Apps hybrides
n de l’appareil
• On retrouve les vulnérabilités
connues • Fraude à
• Injection XSS et HTML l’appel
• SQL Injection
• Augmentation
• Des nouveautés interessantes
de privilèges
• Abus d’appels et de SMS

• Abus de paiements ?
'

19



XSS

'

20



XSS Acces aux SMS

'

20


M4 - Prévention

'

21


M4 - Prévention

1. Valider les données d’entrée avant utilisation

'

21


M4 - Prévention

2. Nettoyer les données en sortie avant affichage.

'

21


M4 - Prévention

3. Utilisation des requetes paramétrées
(correctement ! ) pour les appels bases de
données.

'

21


M4 - Prévention

3. Utilisation des requetes paramétrées
(correctement ! ) pour les appels bases de
données.
4. Minimiser les capacités/privilèges des applications
hybrides Web.
'

21


'

22


M5- Authentification et habilitation
defaillante
• 50% du a des problèmes d’architecture, Impact
50% du à des problèmes du mobile
• Certaines applications se reposent • Elevation de
uniquement sur des éléments Privileges
théoriquement inchangeables, mais
pouvant être compromis (IMEI, IMSI,
UUID)
• Accès non
autorisé.
• Les identifiants matériels persistent
apres les resets ou les nettoyages de
données.
• De l’information contextuelle ajoutée,
est utile, mais pas infaillible.
'

23


M5- Authentification et habilitation
defaillante

'

24


M5 - Prevention

'

25


M5 - Prevention

1. De l’information contextuelle peut améliorer
les choses, mais uniquement en cas
d’implementation d’authentification multi-
facteur.

'

25


M5 - Prevention

facteur.
2. Impossible de faire du “Out-of-band” sur le
même matériel (eg SMS...)

'

25


M5 - Prevention

facteur.
2. Impossible de faire du “Out-of-band” sur le
même matériel (eg SMS...)
3. Ne jamais utiliser l’ID machine ou l’ID
opérateur (subscriber ID), comme élément
unique d’authentification.
'

25


'

26


M6 - Mauvaise gestion des sessions
• Les sessions applicatives mobiles sont Impact
généralement plus longues que sur une
application normale.
• Dans un but de facilité d’utilisation • Elévation de
• Parceque le réseau est plus “lent” et moins
privilèges.
“sur”
• Accès non
• Le maintien de session applicative se fait via autorisé.
• HTTP cookies
• OAuth tokens
• Contournement
des licenses et
• SSO authentication services
des éléments de
• Très mauvaise idée d’utiliser l’ID matériel
paiements
comme identification de session.
'

27


M6- Prévention

'

28


M6- Prévention

1. Ne pas avoir peur de redemander aux utilisateurs
de se ré-authentifier plus souvent.

'

28


M6- Prévention

2. S’assurer que les ID/token peuvent rapidement
être révoqués en cas de perte.

'

28


M6- Prévention

2. S’assurer que les ID/token peuvent rapidement
être révoqués en cas de perte.
3. Utiliser des outils de gestion des sessions
éprouvés

'

28


'

29


M7- Utilisation de données d’entrée pour
effectuer des décisions sécurité.
• Peut être exploité pour passer Impact
outre les permissions et les
modèles de sécurité. • Utilisation de
ressources
• Globalement similaires sur les
payantes.
différentes plateformes
• Des vecteurs d’attaques • Exfiltration de
importants données
• Applications malveillantes • Elevation de
• Injection client privilèges.
'

30


M7- Utilisation de données d’entrée pour effectuer
des décisions sécurité.
Exemple : gestion de skype dans l’URL sur
IOS...

• http://software-security.sans.org/blog/2010/11/08/
insecure-handling-url-schemes-apples-ios/
'

31


M7- Prévention

'

32


M7- Prévention

1. Vérifier les permissions lors de l’utilisation de
données d’entrée.

'

32


M7- Prévention

2. Demander à l’utilisateur une confirmation
avant l’utilisation de fonctions sensibles.

'

32


M7- Prévention

2. Demander à l’utilisateur une confirmation
avant l’utilisation de fonctions sensibles.
3. Lorsqu’il n’est pas possible de vérifier les
permissions, s’assurer via une étape
additionnelle du lancement de la fonction
sensible.
'

32


'

33


M8- Perte de données via des canaux
cachés
• Mélange de fonctionnalités de la Impact
plateforme et de failles de programmation.
• Les données sensibles se trouvent un peu
partout. ou l’on ne s’attend pas.... • Perte
• Web caches définitive de
• Logs de clavier... données.
• Screenshots
• Logs (system, crash)
• Violation de la
• Répertoires temporaires.
vie privée.
• Faire attention a ce que font les librairies
tierces avec les données
utilisateurs( publicité, analyse, ...)
'

34


M8- Perte de données via des canaux
Screenshots cachés

Logging

'

35


M8- Prévention

'

36


M8- Prévention
1. Ne jamais stocker des authentifiants/passwds ou d’autres
informations sensibles dans les logs.

'

36


M8- Prévention
2. Supprimer les données sensibles avant les screenshots,
utiliser les capacités des caches pour les contenu des
applications Web, ...

'

36


M8- Prévention
3. Debugger avec attention les applications avant mise en
production pour vérifier les fichiers produits, modifiés, lus, ....

'

36


M8- Prévention
4. Porter une attention particulière aux librairies tierces.

'

36


M8- Prévention
4. Porter une attention particulière aux librairies tierces.
5. Tester les applications sur différentes versions de la
plateforme....

'

36


'

37


M9- Chiffrement défectueux
• 2 catégories importantes
Impact
• Implémentations défectueuses via
l’utilisation de librairies de • Perte de
chiffrement.
confidentialité.
• Implementations personnelles de
chiffrement.... • Elevation de
• Bien se rappeler les bases !!! privilèges
• Codage (Base64) != chiffrement
• Contournemen
• Obfuscation != chiffrement t de la logique
• Serialization != chiffrement métier.
• Vous vous appelez Bruce ?
'

38


M9- Chiffrement défectueux

ldc literal_876:"QlVtT0JoVmY2N2E=”
invokestatic byte[] decode( java.lang.String ) // Base 64
invokespecial_lib java.lang.String.<init> // pc=2
astore 8

private final byte[]
com.picuploader.BizProcess.SendRequest.routine_12998
(com.picuploader.BizProcess.SendRequest, byte[],
byte[] );
{
enter
new_lib net.rim.device.api.crypto.TripleDESKey

'

39


M9- Prévention

'

40


M9- Prévention

1. Stocker la clef et les données chiffrées n’est
pas correct.

'

40


M9- Prévention

pas correct.
2. Il vaut mieux utiliser des librairies connues de
chiffrement que sa propre librairie....

'

40


M9- Prévention

pas correct.
2. Il vaut mieux utiliser des librairies connues de
chiffrement que sa propre librairie....
3. Utiliser les avantages éventuels de la
plateforme !

'

40


Dark side ?

'

41


M10- Perte d’information sensible
• M10(enfoui dans le matériel) est Impact
différent de M1 (stocké)
• Il est assez simple de faire du reverse- • Perte
engineer sur des applications mobiles...
d’authentifiants
• L’obfuscation de code ne supprime pas
le risque. • Exposition de
propriété
• Quelques informations classiques
trouvées : intellectuelle ?
• clefs d’API
• Passwords
• Logique métier sensible.
'

42


M10- Perte d’information sensible

'

43


M10- Prévention

'

44


M10- Prévention
1. Les clefs d’API privées portent bien leur nom.
Il ne faut pas les stocker sur le client.

'

44


M10- Prévention
2. Si il existe une logique métier propriétaire, il
convient de la faire executée par le serveur !

'

44


M10- Prévention
2. Si il existe une logique métier propriétaire, il
convient de la faire executée par le serveur !
3. Il n’y a jamais ou presque de réelle raison de
stocker des mots de passes en dur (si vous le
pensez, vous avez d’autres problèmes à
venir...)

'

44


Conclusion

'


Conclusion

'

46


Conclusion
• La sécurité mobile en est au début.

'

46


Conclusion
• Nous venons d’identifier quelques problèmes,
il est nécessaire de les corriger !

'

46


Conclusion
• Les plateformes deviennent plus matures, les
applications le doivent aussi...

'

46


Conclusion
• Les plateformes deviennent plus matures, les
applications le doivent aussi...
• Ne pas oublier que la sécurité mobile
comporte une partie application
serveur !
'

46


Remerciements
OWASP Mobile Project Leaders
Jack Mannino jack@nvisiumsecurity.com

• http://twitter.com/jack_mannino

Zach Lanier zach.lanier@intrepidusgroup.com

• http://twitter.com/quine

Mike Zusman mike.zusman@carvesystems.com

• http://twitter.com/schmoilito

'

47


Liens
•OWASP Mobile Project :
https://www.owasp.org/index.php/
OWASP_Mobile_Security_Project
•HTML5 Sécurité :
http://www.slideshare.net/Eagle42/2011-0207html5securityv1
•OWASP Top10
https://www.owasp.org/index.php/
Category:OWASP_Top_Ten_Project

'

48


Vous pouvez donc vous
protéger de lui maintenant...

@SPoint

sebastien.gioria@owasp.org

'
49


Vous pouvez donc vous
protéger de lui maintenant...

@SPoint

sebastien.gioria@owasp.org

Il n'y a qu'une façon d'échouer, c'est d'abandonner avant
d'avoir réussi [Olivier Lockert]
'
49


2012 11-07-owasp mobile top10 v01

Contenu connexe

Tendances

En vedette

Similaire à 2012 11-07-owasp mobile top10 v01

Plus de Sébastien GIORIA

2012 11-07-owasp mobile top10 v01