Failles des applications Web. Ce document est extrait du travail de diplôme de M. DIZON dans l état.

Please download to get full document.

View again

of 22
37 views
PDF
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Document Description
Failles des applications Web Ce document est extrait du travail de diplôme de M. DIZON dans l état. 1 Introduction Contournement de validation javascript Introduction Principe de
Document Share
Documents Related
Document Transcript
Failles des applications Web Ce document est extrait du travail de diplôme de M. DIZON dans l état. 1 Introduction Contournement de validation javascript Introduction Principe de fonctionnement Suppression du code de validation Tests Modification du code de validation Tests Conclusion Vol et manipulation des sessions HTTP Introduction Principe de fonctionnement Application web Cookies Test Conclusion Cross site scripting Introduction Principe de fonctionnement Injection du code Type de code à injecter Méthode d injection Contournement des filtres HTML Exploitation Démonstration XSS Objectif Description de la plate-forme de test Démonstration Conclusion Introduction La plus grande source de failles des applications Web provient d une mauvaise (ou même inexistante) validation des entrées utilisateurs. En effet, certains développeurs ne sont pas sensibilisés aux problèmes de sécurité lié aux applications Web et font confiance aux données envoyées par le client Ce document étudie et fait l implémentation des attaques suivantes : Contournement de validation javascript Vol des sessions HTTP avec des cookies Cross-site scripting (XSS) Laboratoire de transmission de données / EIG 1 2 Contournement de validation javascript 2.1 Introduction Dans certains sites Web, du javascript est utilisé pour valider les données saisies par l utilisateur dans un formulaire d une page Web avant d être envoyées à un programme de traitement du côté serveur. Cette validation permet d alléger la charge du serveur en déportant une partie du traitement de données du côté client. Cette validation du côté client est une vulnérabilité qu un utilisateur peut exploiter de façon triviale. L utilisateur désirant contourner la validation peut le faire en interceptant et modifiant la réponse HTTP envoyé par le serveur par l intermédiaire d un proxy. Dans les sections suivantes du document, nous allons montrer comment intercepter les réponses HTTP et montrer les deux variantes possibles du contournement : la suppression du code de validation ; la modification du code de validation. Une plate-forme de démonstration sera mise en place pour démontrer l exploit. 2.2 Principe de fonctionnement Comme outils, l utilisateur doit posséder sur son poste de travail un navigateur web : Internet Explorer (IE) et un logiciel servant de proxy HTTP : Achilles. Utilisateur: Client V18: Poste client V13: Serveur web IE: Navigateur requête index.html index.html Achilles: Proxy requête index.html index.html Apache: Serveur interception et modification des données Figure 2-1. Interception des échanges navigateur et serveur avec Achilles Le proxy Achilles sert comme relais entre le client et le serveur. Il permet de capturer et modifier des données HTTP émises par le client ou renvoyées par le serveur. C est grâce à cet outil que l utilisateur peut modifier la réponse serveur et comme sera expliquée par la suite, contourner le javascript. L attaque est de type man-in-the-middle, la différence est que la personne tierce est l utilisateur lui-même. La technique la plus simple à effectuer est la suppression du code de validation. Laboratoire de transmission de données / EIG 2 2.3 Suppression du code de validation Pour montrer comment exploiter la vulnérabilité, nous avons écrit et mise à disposition dans le serveur web V13 une page HTML contenant un formulaire HTML. Le client accédera à la page web validation.html avec son navigateur web et devra saisir les données demandées dans le formulaire. Figure 2-2. Formulaire de demande d adresse Nous pouvons en tirer des informations intéressantes dans le code HTML de la page web. Ces informations donnent des indices sur le mécanisme de validation. 01 html 02 head title validation de formulaire /title 03 script language= javascript src= ./jscript/validation.js 04 /script 05 body h3 veuillez entrer les données suivantes: /h3 09 table 10 form name= formulaire method= post enctype= multipart/form-data onsubmit= return validerformulaire() 11 tr td 12 Adresse /td td input type= text name= 13 /td /tr 14 tr td 15 Utilisateur: /td td input type= text name= utilisateur 16 /td /tr 17 tr td /td 18 td input type=submit value= submit 19 /td /tr 20 /form 21 /table 22 /body 23 /html Code source 2-1. validation.html Dans le code source 9-1 et la ligne 10, le formulaire fait une requête POST pour envoyer les données. Lorsque le client cliquera sur le bouton Submit les données entrées subiront une validation javascript avant l envoi de la requête sur le serveur. La validation est faite par la fonction validerformulaire() : Laboratoire de transmission de données / EIG 3 form name= formulaire method= post enctype= multipart/form-data onsubmit= return validerformulaire() La fonction est déclarée dans le fichier javascript validation.js qui est référencé à la ligne 3 du code source 9-1. Sur le poste client V18 avec Windows 2000 SP4, ce fichier et d autres fichiers téléchargés par le navigateur web sont stockés dans le répertoire temporaire : C:\Documents and Settings\Utilisateur\Local Settings\Temporary Internet Files\ où Utilisateur correspond au nom de login de l utilisateur courant. Le fichier n est pas accessible directement dans ce répertoire car il est protégé en lecture et écriture par l OS. Il faut faire une copie du fichier et le mettre dans un autre répertoire pour consulter comment la validation est faite. 01 function validerformulaire() { 02 if == document.formulaire. .value == ) { 04 alert( veuillez entrer une adresse correcte. ); 05 return false; 06 } if (document.formulaire.utilisateur.value == ) { 09 alert( veuillez entrer votre nom d'utilisateur. ); 10 return false; 11 } 12 } Code source 2-2. La fonction validerformulaire La fonction vérifie si tous les champs du formulaire ont étés remplis et si l adresse e- mail saisie est valable, c est-à-dire s il contient le caractère Elle retourne la valeur booléenne vraie lorsque tous les tests ont été effectués avec succès. Dans ce cas les données entrées dans le formulaire sont envoyées sur le serveur web. Par contre si un des tests échoue, la valeur booléenne fausse est retournée par la fonction puis une fenêtre popup est affichée par le navigateur pour demander à l utilisateur de corriger l entrée en question. Si l utilisateur intercepte et modifie le code HTML de la page validation.html sur le proxy Achilles en remplaçant l expression validerformulaire() par l expression true dans le code HTML, la fonction de validation sera supprimé. En conséquence, les données saisies seront directement envoyées sur le serveur sans aucune validation. Nous résumons les actions qui s effectuent avec un diagramme de séquence : Laboratoire de transmission de données / EIG 4 V12: Client IP: V13: Serveur web IP: Personne: Utilisateur IE: Navigateur Achilles: Proxy validation.py: Application web Saisit l'url validation.html requête HTTP de validation.html requête HTTP de validation.html L'utilisateur intercepte les données et modifie le code HTML réponse HTTP validation.html form type= post onsubmit= return validerformulaire() /form réponse HTTP form type= post onsubmit= return true /form Saisit les données dans le formulaire, clique Submit pas de validation!! requête POST requête POST Figure 2-3. Scénario de test : contournement de validation Tests Pour effectuer l exploit grâce à Achilles nous procédons comme suite : Lancer le programme Achilles. Cocher l option Intercept Server Data puis activer le proxy en cliquant sur le bouton Play. Il y d autres options disponibles sur le proxy Achilles mais pour cette démonstration Intercept Server est le seul nécessaire. Le lecteur peut trouver plus d informations sur les options Achilles dans l annexe 17.5 de ce document. Le navigateur web doit être configuré pour qu il renvoi les requêtes HTTP au proxy. Dans la fenêtre d Internet Explorer : Cliquer sur le menu Tools puis sélectionner Internet Options. Cliquer sur l onglet Connections puis cliquer sur le bouton Lan Settings Cocher l option Use Proxy Server for your LAN, puis entrer le l adresse du proxy et le port sur lequel il est en écoute Cliquer sur le bouton OK deux fois pour effectuer les changements. Nous accédons ensuite à la page de validation en saisissant l URL dans la barre d adresse du navigateur: Laboratoire de transmission de données / EIG 5 Nous verrons ensuite afficher sur l interface d Achilles la réponse envoyée par le serveur web. Il suffit maintenant de remplacer l expression validerformulaire() par true puis cliquer sur le bouton Send dans l interface d Achilles. Figure 2-4. Remplacement de la fonction validerformulaire() par true La réponse HTTP sera ensuite interprétée par le navigateur puis affichée sur la fenêtre d IE. L utilisateur peut maintenant tester en saisissant des données quelconques sur le formulaire puis en cliquant sur Submit pour les renvoyer sur le serveur. Figure 2-5. L entrée de la accépté par le serveur Laboratoire de transmission de données / EIG 6 L analyse du code javascript montre que l adresse saisie n est pas correctement validée par le javascript car il vérifie seulement si le apparaît. Il n y a pas de vérification s il est au moins suivi d un domaine ou précédé d un nom. C est une autre problématique qui est malheureusement encore présente dans beaucoup de sites web demandant la saisie des adresses Modification du code de validation Un autre moyen de contournement de validation est par la modification du code javascript. Comme mentionné plus haut les fichiers dans le répertoire Temporary Internet Files sont protégés en lecture et en écriture. Il faut donc trouver un moyen pour éditer et référencer un nouvel emplacement du fichier javascript validation.js. Les étapes à faire pour le contournement par modification sont : télécharger préalablement le fichier javascript.js ; éditer le code du script ; stocker le fichier dans un serveur web local au client ; intercepter et modifier le code HTML envoyé par le serveur en indiquant comme adresse source du fichier l adresse locale du fichier modifié. Le serveur web locale permet d avoir une copie du fichier javascript ayant les droits de modification Tests Nous installons un serveur web Apache sur notre machine cliente V18. Dans le répertoire C:\Program Files\Apache Group\Apache2\htdocs nous mettons une copie du fichier javascript modifié. Internet Explorer Achilles Apache Apache réponse HTTP interception et modification Utilisateur C:\Documents and Settings\Utilisateur\Local Settings\Temporary Internet Files\validation.js validation avec du javascript modifié C:\Program Files\Apache Group\Apache2\htdocs\ validation.js W2K SP4 V13: Client IP: Linux V18: Serveur web IP: Nous éditions ensuite le script : Figure 2-6. Scénario de contournement de validation 01 function validerformulaire() { 02 alert( nous venons de contourner le javascript. ); 03 } Code source 2-3. Modification de la fonction validerformulaire() Laboratoire de transmission de données / EIG 7 Dans cette fonction nous faisons afficher une fenêtre popup lorsque la fonction est appelée. La fonction retournera la valeur booléenne vraie par défaut. Depuis le navigateur nous essayons d accéder à la page validation.html sur le serveur web V13 et interceptons la réponse du serveur sur le proxy Achilles. Nous modifions ensuite le code source de HTML pour indiquer l adresse absolue du fichier javascript modifié : Figure 2-7. URL du javascript modifié Le code HTML est envoyé et affiché sur le navigateur du poste client. Lorsque l utilisateur cliquera sur le bouton Submit dans son navigateur, la validation aura lieu mais par une fonction modifiée. Laboratoire de transmission de données / EIG 8 2.5 Conclusion Grâce à la mise en place de la plate-forme de test nous avons pu voir comment effectuer l exploit. Il faut en premier faire une analyse du code HTML envoyé par le serveur et étudier comment le mécanisme de validation fonctionne. Nous avons vu que la validation a lieu lors de l appel de la fonction écrit en javascript par le formulaire. Et que le test est contourné en modifiant la fonction pour qu il retourne la valeur booléenne vraie lors de l événement onsubmit. Nous avons vu deux moyens pour effectuer l exploit. La méthode par modification est le moins compliqué à mettre en place. Par contre cette implémentation peut servir comme plate-forme d autres attaques basées sur la modification des fichiers téléchargés par le navigateur (modification des applets java par la décompilation puis récompilation). Pour un développeur d une application web, il est en effet important de vérifier la validité des données saisie par l utilisateur. Ceci doit être effectué systématiquement à chaque saisie de l utilisateur. Par contre l application ne doit pas uniquement dépendre sur la validation du côté client car elle peut être facilement contournée. Laboratoire de transmission de données / EIG 9 3 Vol et manipulation des sessions HTTP 3.1 Introduction Le protocole HTTP est une connexion sans état. Des extensions ont été rajoutées dans le protocole pour pouvoir sauvegarder l état des sessions HTTP : Cookies ; Champs cachés dans les formulaires ; Paramètres sur l URL. Avec ces moyens de sauvegarde d état de session, une application web peut mémoriser des données propres à un client tel que son IP, le type de browser web ou son système d exploitation. L application peut avec les données, afficher sur le navigateur du contenu basé sur ces paramètres client. Les applications web utilisent et attribuent un identificateur unique à un utilisateur connectant sur le site web. Cet identificateur est envoyé au client dans un cookie lorsque le client visite un site web ou lorsqu il s authentifie à l application pour la première fois. Le cookie est renvoyé sur le site la prochaine fois que le client se reconnecte sur le site web, permettant l affichage du contenu sur le navigateur tel qu il a été visité la dernière fois. Dans les sous-sections qui suivent, nous allons montrer comment un hacker peut utiliser les cookies pour voler la session d un utilisateur légitime. En même temps nous allons voir comment les cookies fonctionnent. Pour ce faire nous allons mettre en place une plate-forme de test et expliquer sa configuration. L objectif du hacker est de voler les informations stockées dans un cookie du client. L information stockée dans le cookie peut être volée avec des méthodes différentes, pour notre cas nous allons montrer comment récupérer le cookie en utilisant un proxy web. 3.2 Principe de fonctionnement Pour voler un cookie via un proxy web il faut : Ecouter (sniffer) le trafic HTTP entre en poste client et un serveur web ; Copier l en-tête Cookie et sa valeur lorsqu un cookie est envoyé. Pour voler la session HTTP : Envoyer une requête web au site en utilisant le navigateur ; Modifier la requête en insérant l en-tête du cookie précédemment ; Envoyer la requête modifiée sur le site web. Idéalement nous devrions avoir le schéma logique comme indiqué dans la figure 9-1. Laboratoire de transmission de données / EIG 10 requête réponse avec cookie requête réponse avec cookie Client Proxy Serveur vol du cookie Hacker Figure 3-1. Vol du cookie via un proxy Mais pour des raisons de simplicité et pour démontrer l attaque, nous allons utiliser l architecture décrite dans la figure ci-dessous. browser IE: client browser IE: hacker requête insertion cookie volé réponse OK Proxy Achilles requête avec cookie volé réponse OK application web: autoriser.py, login.py Apache 1.3 W2K SP4 V18 IP SuSE 8.0 V13 IP Figure 3-2 Architecture de la plate-forme de test ; exploit du cookie volé Dans la figure 9.2 le hacker représenté par le browser IE aura préalablement récupérée le cookie du client légitime. L application CGI autoriser.py redirige l URL du browser d un utilisateur vers une page HTML protégée si un cookie valide est envoyé avec la requête sinon le browser est redirigé vers l application login.py qui fait l authentification et donne le cookie au client. 3.3 Application web L application web que nous avons développée autoriser.py permet l accès à http :// /access_protege.html si l utilisateur possède un cookie. # Chercher la variable d environnement HTTP_COOKIE dans la liste for k in keys: # Verification de l ID de session hard-coded if (escape(k)== http_cookie and escape(os.environ[k])== IDAuth= ): # Redirection si le cookie est valide redirect( /access_rotégé.html ) # Le client a maintenant un cookie valide, sortir de la boucle Laboratoire de transmission de données / EIG 11 cookie_auth = 1 break # Si le client n as pas de cookie valide, lui envoyer une page de login if cookie_auth==0: redirect( /login.html ) Code source 3-1 autoriser.py : recherche de cookie et redirection Si l utilisateur ne possède pas de cookie contenant un identificateur de session valable, une redirection sur http :// /login.html est faite. Une fois authentifiée, il reçoit l accès à la page protégé et un cookie. # Fonction pour l authentication simple»hard-coded» def authentifie(user, passwd): if (user== bob and passwd== 1234 ): return «true» # Lire les variables du formulaire HTML donneesform = cgi.fieldstorage() user = donneesform[ login ].value passwd = donneesform[ pass ].value # Le coeur du programme : # L acces sur la page protege est donnee si l authentification # réussi sinon une redirection sur la page de login est faite. If (authentifie(user, passwd)== true ): # Donner un cookie print Set-Cookie : IDAuth= ; expires=fri, 12 Dec :00 :00 GMT # Aller sur la page protege redirect( /access_rotégé.html ) else : # Aller sur la page login.html redirect( /login.html ) Code source 3-2 login.py : authentification(hard-coded) et redirection Une application web donne un cookie au client en insérant une entête Set-Cookie suivi d une valeur et des options dans sa réponse HTTP. 3.4 Cookies Le format de l en-tête et sa valeur est comme suit : Set-Cookie : nom=valeur [ ; option=option ] nom = valeur : l information à stocker et sa valeur correspondante. expires = date : détermine la durée de validité du cookie. Si cette option est omise le cookie est stocké dans la mémoire temporaire et effacé lorsque le browser web est fermé. Un cookie de ce type est appelé session cookie. Les cookies persistent sont des cookies qui sont stockés dans des fichiers textes dans un répertoire temporaire ( Temporary Internet Files pour le navigateur IE dans un système W2K SP4). domain = domaine : détermine dans quel domaine le cookie est valide. path = url : détermine dans quelle URL le cookie est valide. Laboratoire de transmission de données / EIG 12 Le cookie donne par login.py est comme suivant Set-Cookie: IDAuth= ; expires=fri, 12 Dec :00:00 GMT L information importante stockée dans le cookie est IDAuth. L option domain et path ne sont pas explicitement donnée : par défaut la valeur de domain est l adresse du site web, le path sera l URL ou le cookie a été donnée. Dans notre cas, le cookie a été donnée par le programme CGI login.py se trouvant dans le répertoire cgi-bin de la racine du serveur web http :// /cgi-bin/login.py domain = path = /cgi-bin Le cookie restera dans le répertoire temporaire de la machine jusqu à la date de l expiration 12 décembre Chaque fois que le browser se connectera sur le site web du http :// et sur l url /cgi-bin, le cookie sera transmis avec la requête du browser avec l entête : et concrètement : Cookie : nom=valeur Cookie : IDAuth= L application web doit lire la variable d environnement HTTP_COOKIE pour extraire le cookie. Si plusieurs cookies sont envoyés
Similar documents
View more...
Search Related
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x