Le document présente les 10 principaux risques de sécurité liés aux applications mobiles selon l'OWASP. Chaque risque est détaillé, accompagné de conseils de prévention pour améliorer la sécurité des données et des applications. Les thèmes abordés incluent le stockage non sécurisé des données, des contrôles serveurs défaillants, et des failles d'authentification, entre autres.

1. The OWASP Foundation
http://www.owasp.org
Les 10 Risques sur les
mobiles
Sébastien Gioria
OWASP France Leader
OWASP Global Education Committee
Confoo.ca
29 Février 2012 - Montréal - Canada
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

2. 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é
2
2

3. 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é
2
2

4. Top 10 Risques

5. 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

6. 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

7. M1 - Stockage de données non sécurisé
• 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 ne sont par
normalement prévue • Violation de vie
• Permission globales ou faibles privée
• Non suivi des bonnes pratiques de la • Non-compliance
plateforme
6

8. M1 - Stockage de données non sécurisé
7

9. M1 - Stockage de données non sécurisé
7

10. M1 - Stockage de données non sécurisé
7

11. M1 - Stockage de données non sécurisé
7

12. M1 - Prévention
8

13. M1 - Prévention
1. Ne stocker que ce qui est réellement
nécessaire
8

14. M1 - Prévention
1. Ne stocker que ce qui est réellement
nécessaire
2. Ne jamais stocker de données sur des
éléments publiques (SD-Card...)
8

15. M1 - Prévention
1. Ne stocker que ce qui est réellement
nécessaire
2. Ne jamais stocker de données sur des
éléments publiques (SD-Card...)
3. Utiliser les APIs de chiffrement et les
conteneurs sécurisés fournis par la plateforme.
8

16. M1 - Prévention
1. Ne stocker que ce qui est réellement
nécessaire
2. Ne jamais stocker de données sur des
éléments publiques (SD-Card...)
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”
8

17. 9

18. 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
10

19. M2 - Contrôles serveur défaillants
OWASP Top 10 OWASP Cloud Top 10
• https://www.owasp.org/index.php/ • https://www.owasp.org/images/4/47/Cloud-
Category:OWASP_Top_Ten_Project Top10-Security-Risks.pdf
11

20. M2- Prévention
12

21. M2- Prévention
1. Comprendre les nouveaux risques induits par
les applications mobiles sur les architectures
existantes
12

22. M2- Prévention
1. Comprendre les nouveaux risques induits par
les applications mobiles sur les architectures
existantes
12

23. M2- Prévention
1. Comprendre les nouveaux risques induits par
les applications mobiles sur les architectures
existantes
3. OWASP Top 10, Cloud Top 10, Web Services Top 10
12

24. M2- Prévention
1. Comprendre les nouveaux risques induits par
les applications mobiles sur les architectures
existantes
3. OWASP Top 10, Cloud Top 10, Web Services Top 10
12

25. M2- Prévention
1. Comprendre les nouveaux risques induits par
les applications mobiles sur les architectures
existantes
3. OWASP Top 10, Cloud Top 10, Web Services Top 10
5. Voir les Cheat sheets, guides de développement,
l’ESAPI
12

26. 13

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

28. M3 - Protection insuffisante lors du
transport de données
Exemple : Protocol d’authentification des clients
Google
• L’entete d’authenfication 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
15

29. M3 - Prévention
16

30. M3 - Prévention
1. Vérifier que les données sensibles quittent
l’appareil chiffrées.
16

31. M3 - Prévention
1. Vérifier que les données sensibles quittent
l’appareil chiffrées.
2. Quelque soit les données et les réseaux : Wifi,
NFC, GSM, ....
16

32. M3 - Prévention
1. Vérifier que les données sensibles quittent
l’appareil chiffrées.
2. Quelque soit les données et les réseaux : Wifi,
NFC, GSM, ....
3. Ne pas ignorer les erreurs de sécurité !
16

33. 17

34. 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 • Fraude à
connues
• 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 ?
18

35. M4 - Injection client
XSS
19

36. M4 - Injection client
XSS Acces aux SMS
19

37. M4 - Prévention
20

38. M4 - Prévention
1. Valider les données d’entrée avant utilisation
20

39. M4 - Prévention
1. Valider les données d’entrée avant utilisation
2. Nettoyer les données en sortie avant affichage.
20

40. M4 - Prévention
1. Valider les données d’entrée avant utilisation
2. Nettoyer les données en sortie avant affichage.
3. Utilisation des requetes paramétrées pour les
appels bases de données.
20

41. M4 - Prévention
1. Valider les données d’entrée avant utilisation
2. Nettoyer les données en sortie avant affichage.
3. Utilisation des requetes paramétrées pour les
appels bases de données.
4. Minimiser les capacités/privilèges des
applications hybrides Web.
20

42. 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
authorisé.
• 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.
21

43. M5- Authentification et habilitation
defaillante
22

44. M5 - Prevention
23

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

46. M5 - Prevention
1. De l’information contextuelle peut améliorer
les choses, mais uniquement en cas
d’implementation d’authentification multi-
facteur.
2. Impossible de faire du “Out-of-band” sur le
même matériel (eg SMS...)
23

47. M5 - Prevention
1. De l’information contextuelle peut améliorer
les choses, mais uniquement en cas
d’implementation d’authentification multi-
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.
23

48. 24

49. M6 - Mauvaise gestion des sessions
• Les sessions applicatives mobiles sont Impact
générallement plus longue que sur une
application normale. • Elévation de
• Dans un but de facilité d’utilisation privilèges.
• Le maintien de session applicative se fait • Accès non
via
authorisé.
• 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.
25

50. M6- Prévention
26

51. M6- Prévention
1. Ne pas avoir peur de redemander aux utilisateurs de
se ré-authentifier plus souvent.
26

52. M6- Prévention
1. Ne pas avoir peur de redemander aux utilisateurs de
se ré-authentifier plus souvent.
2. S’assurer que les ID/token peuvent rapidement être
révoqués dan cas de perte de Ensure that tokens can
be revoked quickly in the event of a lost/stolen device
26

53. M6- Prévention
1. Ne pas avoir peur de redemander aux utilisateurs de
se ré-authentifier plus souvent.
2. S’assurer que les ID/token peuvent rapidement être
révoqués dan cas de perte de Ensure that tokens can
be revoked quickly in the event of a lost/stolen device
3. Utilisation des outils de gestion des sessions éprouvés
et surs
26

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

55. 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/
28

56. M7- Prévention
29

57. M7- Prévention
1. Vérifier les permissions lors de l’utilisations de
données d’entrée.
29

58. M7- Prévention
1. Vérifier les permissions lors de l’utilisations de
données d’entrée.
2. Demander à l’utilisateur une confirmation
avant l’utilisation de fonctions sensibles.
29

59. M7- Prévention
1. Vérifier les permissions lors de l’utilisations de
données d’entrée.
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.
29

60. 30

61. 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 • Perte
partout. ou l’on ne s’attend pas....
définitive de
• Web caches
données.
• Logs de clavier...
• Screenshots • Violation de la
• Logs (system, crash) vie privée.
• Répertoires temporaires.
• Faire attention a ce que font les librairies
tierces avec les données
utilisateurs( publicité, analyse, ...)
31

62. M8- Perte de données via des canaux
Screenshots cachés
Logging
32

63. M8- Prévention
33

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

65. M8- Prévention
1. Ne jamais stocker des authentifiants/passwds ou d’autres
informations sensibles dans les logs.
2. Supprimer les données sensibles avant les screenshots,
utiliser les capacités des caches pour les contenu des
applications Web, ...
33

66. M8- Prévention
1. Ne jamais stocker des authentifiants/passwds ou d’autres
informations sensibles dans les logs.
2. Supprimer les données sensibles avant les screenshots,
utiliser les capacités des caches pour les contenu des
applications Web, ...
3. Debugger avec attention les applications avant mise en
production pour vérifier les fichiers produits, modifiés, lus, ....
33

67. M8- Prévention
1. Ne jamais stocker des authentifiants/passwds ou d’autres
informations sensibles dans les logs.
2. Supprimer les données sensibles avant les screenshots,
utiliser les capacités des caches pour les contenu des
applications Web, ...
3. Debugger avec attention les applications avant mise en
production pour vérifier les fichiers produits, modifiés, lus, ....
4. Porter une attention particulière aux librairies tierces.
33

68. M8- Prévention
1. Ne jamais stocker des authentifiants/passwds ou d’autres
informations sensibles dans les logs.
2. Supprimer les données sensibles avant les screenshots,
utiliser les capacités des caches pour les contenu des
applications Web, ...
3. Debugger avec attention les applications avant mise en
production pour vérifier les fichiers produits, modifiés, lus, ....
4. Porter une attention particulière aux librairies tierces.
5. Tester les applications sur différentes versions de la
plateforme....
33

69. 34

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

71. 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
36

72. M9- Prévention
37

73. M9- Prévention
1. Stocker la clef et les données chiffrées n’est
pas correct.
37

74. M9- Prévention
1. Stocker la clef et les données chiffrées n’est
pas correct.
2. Il vaut mieux utiliser des librairies connues de
chiffrement que sa propre librairie....
37

75. M9- Prévention
1. Stocker la clef et les données chiffrées n’est
pas correct.
2. Il vaut mieux utiliser des librairies connues de
chiffrement que sa propre librairie....
3. Utiliser les avantages éventuels de la
plateforme !
37

76. Dark side ?
38

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

78. M10- Perte d’information sensible
40

79. M10- Prévention
41

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

81. M10- Prévention
1. Les clefs d’API privées portent bien leur nom.
Il ne faut pas les stocker sur le client.
2. Si il existe une logique métier propriétaire, il
convient de la faire executée par le serveur !
41

82. M10- Prévention
1. Les clefs d’API privées portent bien leur nom.
Il ne faut pas les stocker sur le client.
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...)
41

83. Conclusion

84. Conclusion
43

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

86. Conclusion
• La sécurité mobile en est au début.
• Nous venons d’identifier quelques problèmes,
il est nécessaire de les corriger !
43

87. Conclusion
• La sécurité mobile en est au début.
• Nous venons d’identifier quelques problèmes,
il est nécessaire de les corriger !
• Les plateformes deviennent plus matures, les
applications le doivent aussi...
43

88. Conclusion
• La sécurité mobile en est au début.
• Nous venons d’identifier quelques problèmes,
il est nécessaire de les corriger !
• Les plateformes deviennent plus matures, les
applications le doivent aussi...
• Ne pas oublier que la sécurité mobile
comporte une partie application
serveur !
43

89. 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
44

90. Autres sessions liées
Web Security (Hampstead - 29/02 a 13h15)
Threat modeling d'une application: étude de cas (St-Pierre -
29/02 à 14h30)
Sécurité et Ruby on Rails, une introduction (Fontaine F -
01/03 à 16h)
Beware of the dark side, Luke! (Hampstead - 02/03 à 8h30 )
Trouvez la faille! (Côte-St-Luc - 2/03 à 14h45)
45

91. Autres sessions liées
Web Security (Hampstead - 29/02 a 13h15)
Threat modeling d'une application: étude de cas (St-Pierre -
29/02 à 14h30)
Sécurité et Ruby on Rails, une introduction (Fontaine F -
01/03 à 16h)
Beware of the dark side, Luke! (Hampstead - 02/03 à 8h30 )
Trouvez la faille! (Côte-St-Luc - 2/03 à 14h45)
45

92. Autres sessions liées
Web Security (Hampstead - 29/02 a 13h15)
Threat modeling d'une application: étude de cas (St-Pierre -
29/02 à 14h30)
Sécurité et Ruby on Rails, une introduction (Fontaine F -
01/03 à 16h)
Beware of the dark side, Luke! (Hampstead - 02/03 à 8h30 )
Trouvez la faille! (Côte-St-Luc - 2/03 à 14h45)
45

93. Autres sessions liées
Web Security (Hampstead - 29/02 a 13h15)
Threat modeling d'une application: étude de cas (St-Pierre -
29/02 à 14h30)
Sécurité et Ruby on Rails, une introduction (Fontaine F -
01/03 à 16h)
Beware of the dark side, Luke! (Hampstead - 02/03 à 8h30 )
Trouvez la faille! (Côte-St-Luc - 2/03 à 14h45)
45

94. 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
46

95. Vous pouvez donc vous
protéger de lui maintenant...
@SPoint
sebastien.gioria@owasp.org
47

96. 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]
47