Sécurité des applications mobile et Web Services

1 566 vues

Publié le

une petite présentation sur la découverte de l’infrastructure Android , les mécanismes de sécurité introduit dessus , les failles les plus répondus ; mais aussi tout ce qui est Web Services et leurs sécurité ( inclus les failles les plus répondues )

Publié dans : Ingénierie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 566
Sur SlideShare
0
Issues des intégrations
0
Intégrations
19
Actions
Partages
0
Téléchargements
113
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Sécurité des applications mobile et Web Services

  1. 1. 7/25/2014 1 Réalisé par : Kondah Hamza Sécurité des application mobiles et Web Services
  2. 2. INTRODUCTION 7/25/2014 2
  3. 3. ARCHITECTURE ANDROID 7/25/2014 3
  4. 4. Architecture ANDROID  Au niveau système, Android est organisé autour de plusieurs instances de la machine virtuel Dalvik, dans différents processus.  Les instances communiquent entre elles à l'aide d'un mécanisme IPC (Inter Processus Call)  Une instance particulière de Dalvik, portée par le processus SystemServer, expose des composants et des services aux applications  2 modes de lancement d’application 1.Terminal monoprocess: 1 classloader / appli 2.Terminal monoprocess: 1 process / appli 4
  5. 5. Architecture ANDROID  Pour optimiser l'instanciation des machines virtuelles, Android utilise un processus spécifique apellé Zygote  Zygote porte une première instance de Dalvik comme modèle.  Zygote écoute sur un socket local.  Sur réception d'une ligne de commande, celle-ci est interprétée par Zygote, après avoir effectué un fork() du processus. 5
  6. 6. 7/25/2014 6 Architecture ANDROID
  7. 7. 7/25/2014 7 Architecture ANDROID – Linux Kernel Caractéristiques :  Architecture ARM  Basé sur Linux 2.6  Système de fichier support : FAT32  Support de TCP/IP,UDP... Adaptation à la plateforme mobile :  Alarm : timers pour réveiller des périphériques  Ashmem : partage de mémoire entre processus  Binder : driver IPC pour la communication inter processus  Power Management  Low Memory Killer  Kernel Debugger  Logger
  8. 8. 7/25/2014 8 Architecture ANDROID – Librairies • Bibliotèques C/C++ • Accès à travers des interfaces Java • Surface Manager • 2D and 3D graphics • Codecs Media , SQLite etc….
  9. 9. 7/25/2014 9 • Machine virtuelle Dalvik • Un ensemble de librairies noyau qui fournissent la plupart des fonctionnalités disponibles dans les librairies noyau du langage de programmation Java Architecture ANDROID – Android Runtime
  10. 10. 7/25/2014 10 • Interfaces API • Activity manager – permet de gérer le cycle de vie d’une application Architecture ANDROID – Application Framework
  11. 11. 7/25/2014 11 Architecture ANDROID – Applications • un client mail, • un programme pour les SMS, • calendrier, • cartes, • navigateur, • contacts, et d’autres.
  12. 12. 7/25/2014 12 Sécurité Android
  13. 13. 7/25/2014 13 Sécurité Android – Threat modeling Threat Modelin g Menace s Scénari os d'attaqu e Assets Threat agents
  14. 14. 7/25/2014 14 Assets  Finances  Equipement réseau, consommation réseau  Fonctionnement du téléphone  Intégrité des informations  Informations confidentielles  Disponibilité des informations  Informations environnementales  Productivité Threat Agents  Pirate neutre  Entités ennemies  Ancien employé  Script Kiddie  Hasard
  15. 15. 7/25/2014 15 Scénarios d'attaque  Abus de la confiance de l'utilisateur  Utilisation d'une faille du système ou d'une application  Utilisation du téléphone par une personne tierce  Saturation de l'équipement réseau  Ecoute du réseau  Réception répétée de messages  Panne matérielle Menaces
  16. 16. 7/25/2014 16 Sécurité Android – Approche de l’étude
  17. 17. 7/25/2014 17 TOP 5 FAILLES ANDROID
  18. 18. 18 INSECURE DATA STORAGE
  19. 19. 19 FAIBLAISSE COTÉ SERVEUR •OWASP Top 10 • https://www.owasp.org/index.php/Category:OWASP_ Top_Ten_Project OWASP Cloud Top 10
  20. 20. 20 CLIENT SIDE INJECTION • Applications utilisantdes libraries navigateurs • Applications web pure • Hybrid web/native • Attaques les plus connues • XSS et HTML Injection • SQL Injection • Nouvelles attaques • Appels non autorisés+ SMS • Paiment non autorisés
  21. 21. 21 CLIENT SIDE INJECTION • XSS : Avec un accès à :
  22. 22. 22 AUTHENTIFICATION ET HABILITATION DEFAILLANTE •50% du a des problèmes d’architecture, 50% du à des problèmes du mobile • Certaines applications se reposent uniquement sur des éléments théoriquement inchangeables, mais pouvant être compromis (IMEI, IMSI, UUID) • 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. 23. 23 AUTHENTIFICATION ET HABILITATION DEFAILLANTE
  24. 24. UTILISATION DE DONNÉES D’ENTRÉE POUR EFFECTUER DES DÉCISIONS SÉCURITÉ. • Peut être exploité pour passer outre les permissions et les modèles de sécurité. • Globalement similaires sur les différentes plateformes • Des vecteurs d’attaques importants • Applications malveillantes • Injection client 7/25/2014 24
  25. 25. 7/25/2014 25 UTILISATION DE DONNÉES D’ENTRÉE POUR EFFECTUER DES DÉCISIONS SÉCURITÉ.
  26. 26. 7/25/2014 26
  27. 27. SÉCURITÉ ANDROID – MÉCANISMES DE SÉCURITÉ 7/25/2014 27 Il existe 2 catégories :  Mécanisme de sécurité au niveau de Linux (SandBoxing)  Mécanismes spécifiques à Android
  28. 28. 7/25/2014 28 SÉCURITÉ ANDROID MÉCANISMES DE SÉCURITÉ LINUX
  29. 29. SÉCURITÉ ANDROID – MÉCANISMES DE LINUX - SANDBOXING 7/25/2014 29 Les mécanismes de linux isolent les applications les unes des autres ainsi que des ressources systèmes • Les fichiers système sont la propriété des utilisateurs « System» ou « Root» • Le « Sandboxing» est assuré au niveau du noyau de l’OS • Le code de chaque application est exécuté par une machine virtuelle DalviK VM séparée dans un processus portant un UID unique
  30. 30. SÉCURITÉ ANDROID – MÉCANISMES DE LINUX - SANDBOXING 7/25/2014 30
  31. 31. SÉCURITÉ ANDROID – MÉCANISMES DE LINUX 7/25/2014 31  Portable Operating System Interface user (POSIX) - Chaque application se voit attribuer un UID différent - Chaque processus se voit attribuer un environnement d’exécution isolé  Linux File Access - Chaque application possède son propre répertoire, et elle est la seule à pouvoir y accéder. - Empêche l’accès non autorisé aux données privées des applications
  32. 32. SÉCURITÉ ANDROID – MÉCANISMES DE LINUX 7/25/2014 32  Discretionary Access Control - DAC - Les Applications (Sujet) se voit attribuer un UID , GID et un ou plusieurs groupe d’utilisateurs - Les règles d’accès sont spécifiées pour chaque fichier(Objet) - - Lecture/écriture/Exécution pour le Owner / les utilisateurs du même groupe / et le reste des utilisateurs - Ce schéma est utilisé par le Kernel de linux pour renforcer les règles d’accès aux fichiers et ressources systèmes
  33. 33. SÉCURITÉ ANDROID MÉCANISMES DE SÉCURITÉ ANDROID 7/25/2014 33
  34. 34. 7/25/2014 34 Sécurité Android – Mécanismes de sécurité Android o Séparation des utilisateurs o Cloisonnement o Accès aux fichiers o Unité de gestion de mémoire o Permissions des applications o Signatures des applications o Déverrouillage par pattern o Services et internet o Bluetooth o Suppression et mise à jour d'applications à distance
  35. 35. LES WEB SERVICES PRINCIPES ET FAILLES 7/25/2014 35
  36. 36. CONTEXTE • Avènement d’Internet • Utiliser et fournir des services • Services à valeur ajoutée • Architecture distribuée • Différents sites pour une entreprise • Hétérogénéité des applications • Des entreprises demandeuses de services • Proposer des standards
  37. 37. WEB SERVICE = ? Un Web Service « minimal » c’est : • Mise à disposition d’une application via : • Internet • Intranet • Utilisation du XML • Requête • Réponse • Alternative aux solutions distribuées (CORBA, EJB, …)
  38. 38. L’IDÉE Réseau Web Service
  39. 39. LES ATTENTES 0 10 20 30 40 50 60 70 80 Commerce électronique B to B Relation Client Commerce électronique C to C Logistique Progiciel de gestion Résultats d’une enquête sur les attentes des entreprises
  40. 40. INTÉRÊTS DES WEB SERVICES • Orientés vers l’extérieur : • « Plus vite, meilleur, moins cher » • Indépendant des technologies internes • Services aux entreprises (B2B) • Services aux particuliers (B2C) • En interne • Utilisation de ressources distantes • Outils de travail, communication, …
  41. 41. EXEMPLE SIMPLE D’APPLICATION Émetteur Intermédiaire Récepteur Valide les signatures numériques Donne le cours des actions
  42. 42. MISE EN ŒUVRE ACTUELLE • XML (eXtensible Markup Language) • Échange de messages XML entre client et serveur • Lisible, structuré • HTTP, SMTP, BEEP… • Réutilisation des standards « habituels » d’Internet • SOAP (Simple Object Access Protocol) • Protocole définissant les échanges XML entre entités • WSDL (Web Services Description Language) • Description technique des services web proposés • UDDI (Universal Description Discovery and Integration) • Annuaire des services web disponibles
  43. 43. Entreprise A Entreprise B Serveur HTTP (WSDL) Serveur HTTP (WSDL)
  44. 44. ÉCHANGES D’INFORMATIONS Fournisseur de Web Services Annuaire UDDI WebServices référencés Description WSDLDescription WSDL Back Office Et Système d’ entreprise Serveur web Serveur d’application Business Object Business Object Business Object Description WSDLDescription WSDL Web Service 2 Web Service 1 Description WSDLDescription WSDL
  45. 45. ÉCHANGES D’INFORMATIONS Annuaire UDDI WebServices référencés Description WSDLDescription WSDL Fournisseur de Web Services Back Office Et Système d’ entreprise Serveur web Serveur d’application Business Object Business Object Business Object Web Service 2 Web Service 1 Description WSDLDescription WSDL Client du Web Service Business Object Description WSDL Description WSDL
  46. 46. ÉCHANGES D’INFORMATIONS Annuaire UDDI WebServices référencés Description WSDLDescription WSDL Fournisseur de Web Services Back Office Et Système d’ entreprise Serveur web Serveur d’application Business Object Business Object Business Object Web Service 2 Web Service 1 Description WSDLDescription WSDL Client du Web Service Business Object Description WSDL Requête SOAP
  47. 47. PILE DE PROTOCOLES Discovery (UDDI) Description (WSDL) Packaging (SOAP) Transport (HTTP, SMTP, Jabber, BEEP, …) Réseau
  48. 48. DÉMYSTIFICATION DES TECHNOLOGIES 7/25/2014 48 • Languages :  • XML : La base  • xPath, xQuery : équivalent à SQL  • WSDL : Descripteur de Services • Protocoles  • Transport : HTTP  • Message : SOAP (SOAP = HTTP + XML) • Autres éléments :  • SAML : Security Assertion Markup Language  • WS-Security : Web Services Security
  49. 49. DÉMYSTIFICATION DES PROTOCOLES XML 7/25/2014 49 • Ensemble non fini de balises • L’utilisateur peut créer de nouvelles balises • Définition de grammaires : XML est un Meta-Langage • MathML, NewsML, XMI, Doc, Slides, … • Séparation de la forme et du fond • Un document XML peut être constitué de deux entités (le fond et la forme)
  50. 50. EXEMPLE 7/25/2014 50 <livre> <titre> le super livre </titre> <chapitre> <numero> 1 </numero> <titre> titre du chapitre 1 </titre> <contenu> blabla blabla </contenu> </chapitre> <chapitre> … </chapitre> </livre
  51. 51. XPATH 7/25/2014 51 <?xml version="1.0" encoding="ISO-8859-1"?> <users> <user> <username>gandalf</username> <password>!c3</password> <account>admin</account> </user> <user> <username>Stefan0</username> <password>w1s3c</password> <account>guest</account> </user> </users> //username => Renvoi tous les username //user[username = 'gandalf’]/account => Renvoi le champ account du compte gandalf
  52. 52. SOAP 7/25/2014 52 SOAP : Simple Object Access Protocol Permet l’envoi de messages XML
  53. 53. SOAP - TYPE DE COMMUNICATION 7/25/2014 53 - RPC • Le document XML transmis dans la requête SOAP est calqué sur la syntaxe de la méthode invoquée • Traitement synchrone - Document • Le document XML transmis dans la requête SOAP est traité par le serveur, qui renvoie un document XML en retour • Le Client ne sait pas comment le service est implémenté, ni comment le message est traité • Traitement asynchrone
  54. 54. EXEMPLE 7/25/2014 54
  55. 55. 7/25/2014 55
  56. 56. 7/25/2014 56
  57. 57. XML SIGNATURE 7/25/2014 57 Objectif: signature numérique d’un document XML  Garantir l’authenticité et l’intégrité du document  Signature de tout ou partie du document XML  Recommandation W3C: XML Signature Syntax and Processing  http://www.w3.org/TR/xmldsig-core/ Types de signature 1. Enveloppante (‘enveloping’) 2. Enveloppée (‘enveloped’) 3. Détachée (‘detached’)
  58. 58. XML ENCRYPTION 7/25/2014 58 Objectif: chiffrement d’un document XML Garantir la confidentialité de bout en bout du document Recommandation W3C: XML Encryption Syntax and Processing /http://www.w3.org/TR/xmlenc-core Flexible Possibilité d’encrypter tout ou partie du document, avec 1 ou différentes clés
  59. 59. XMLENCRYPTION 7/25/2014 59  Chiffrement symétrique  Quid de la clé? Clé connue des deux parties Plusieurs clés communes et identifiant de la clé utilisée transmis  Transmission de la clé partagée encryptée avec la clé publique du correspondant
  60. 60. XML ENCRYPTION 7/25/2014 60  Chiffrement XML 1. Choix d’un algorithme (3DES ou AES) 2. Obtention ou génération de la clé 3. Sérialisation des données à encrypter 4. Chiffrement  Déchiffrement 1. Identifier l’algorithme et la clé utilisés 2. Obtenir la clé 3. Déchiffrer les données 4. Intégrer les données déchiffrées dans le document
  61. 61. WS SECURITY 7/25/2014 61  Objectifs Authentification Confidentialité des messages Intégrité des messages  Fondation d’autres standards
  62. 62. WS-SECURITY 7/25/2014 62 Notion de jeton de sécurité (security token) Pour l’authentification ou l’autorisation • Ex: username/password, certificat X509, …  Extension de SOAP  Définition d’un header SOAP contenant l’information de sécurité • Jetons de sécurité • Signatures numériques • Élements encryptés
  63. 63. WS-SECURITY 7/25/2014 63 Confidentialité des messages SOAP  Utilisation de XML-Encryption • Encryption d’un ou plusieurs éléments du message SOAP • Référence vers les éléments encryptés dans le header  Clé partagée  Possibilité d’encrypter différents éléments avec des clés différentes
  64. 64. WS-POLICY 7/25/2014 64 Objectif: spécifier des informations et des exigences pour un WS  S’applique aussi bien au serveur qu’au client Exemples:  utilisation d’une version spécifique de SOAP  Exigence de signature  Information sur le format de la réponse (encrypté, signée…)
  65. 65. WS-TRUST 7/25/2014 65  Modèles de confiance nombreux et variés • Et transorganisations  Problèmes • Émettre et obtenir des jetons de sécurité • Etablir et valider des relations de confiance  Définition d’un Security Token Service • Émet, valide ou échange un jeton de sécurité
  66. 66. LES PARSEURS XML 7/25/2014 66 2 grandes familles : SAX : • Simplistes • Analyse du document en fonction des événements • Appel de fonction lorsque des noeuds sont trouvés  DOM : • Plus complexes et utiles • Basés sur des principes d’arbres pour créer des hiérarchies du document • Compatibles xPath !
  67. 67. LES ATTAQUES SUR LES WEBSERVICES 7/25/2014 67
  68. 68. XML BOMB 7/25/2014 68 o Trivial à effectuer : • Référence récursive à une entité du même document :
  69. 69. INJECTION XML ENTITY 7/25/2014 69 La possibilité d’injecter du code XML de type entity system peut être catastrophique:
  70. 70. INJECTION XML 7/25/2014PROJET FIN D’ETUDES 70
  71. 71. INJECTION CDATA 7/25/2014PROJET FIN D’ETUDES 71 Le contenu des élément CDATA est éliminé lors du parsing. Soit :
  72. 72. INJECTION XPATH 7/25/2014PROJET FIN D’ETUDES 72 Imaginons la base d’authentification Xml suivante:
  73. 73. MESSAGES SOAP 7/25/2014 73  SOSOAP est un protocole d’échanges  AP ne dispose pas d’un mécanisme de sessions :  Aucune relation entre les messages  Rejeu possible très facilement : • Authentification • Messages
  74. 74. 7/25/2014PROJET FIN D’ETUDES 74

×