• 10 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 23/12/2019

Stoppez le cross-site scripting (XSS)

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Dans ce chapitre, nous allons aborder les failles de cross-site scripting ou XSS.

Définissez le cross-site scripting ?

Les attaques cross-site scripting ou XSS sont faites pour prendre le contrôle de votre navigateur. Un attaquant qui y parvient aura potentiellement accès à vos cookies et à vos sessions qui peuvent contenir des données sensibles ! Ces attaques peuvent également permettre d’apporter des modifications non autorisées à une application web et créer des liens qui vous mèneront vers des sites malveillants !

Découvrez les attaques utilisant XSS

Avec une attaque XSS, un attaquant va essayer de prendre le contrôle de votre navigateur en injectant un script JavaScript dans l'application web. Il pourra l’injecter directement dans un formulaire, mais il peut également l’injecter dans l'URL, l'en-tête HTTP ou d'autres parties du framework utilisé.

Contrairement aux injections SQL, il ne s'agit pas de requêtes et de commandes SQL sur une base de données. Une faille XSS s’exécute dans le code de l'application web. 

Revenons à la page de connexion avec le nom d'utilisateur et le mot de passe. Au lieu du nom d'utilisateur, le pirate va entrer :

<script> I haxx000red you </script>

Sur une page de connexion qui n'est pas sécurisée, il y aura une boîte de dialogue qui s’affichera. De plus, l'URL qui se trouve maintenant dans votre barre d'adresse peut être utilisée pour exécuter directement ce script. Il est également possible d'effectuer la même attaque avec une image, par exemple.

<img src oneerror= “alert(haaxxxx000red 4ever!)>

L'URL dans la barre d'adresse après l'exécution du script pourrait ressembler à ceci :

webdevfightshacker.bla/index.html?query=<img src + onerror%3Dalert%45%haaxxxx%87”....>

Notez que le domaine sur l'URL a l'air légitime, mais à la fin de l'URL, on peut voir le script qui a été ajouté. Ce lien peut exécuter du code arbitraire sur le navigateur. Un attaquant pourra transmettre cette URL à une cible qui exécutera l'attaque XSS dans son environnement.

Les attaques XSS ciblent également les cookies, exposant leur contenu dans une fenêtre pop-up. Par exemple, si vous avez envoyé une demande de connexion à un serveur web et qu'il répond par un cookie avec vos identifiants en texte clair, un script XSS s'exécutera sur votre navigateur et affichera une fenêtre pop-up avec vos identifiants qui étaient sur le cookie.

Comment puis-je éviter cette attaque de cookie ?

Une option consiste à ajouter un flag  HttpOnly à vos cookies. Ce flag permet d’empêcher un script d'accéder aux cookies. HttpOnly  est un flag à mettre à  true  dans la plupart des frameworks. Par exemple, Node.js a un module de cookies avec HttpOnly, et un middleware appelé Helmet

Express PHP a une fonction setcookie()  qui permet de configurer HttpOnly  comme paramètre, et ASP.NET a l'option CookieHTTpOnly et CookieSecure

Respectez les bonnes pratiques

  • Appliquez la validation des données d'entrée : pour empêcher les attaques communes, il est possible de blacklister certains caractères comme les balises script.

  • Appliquez la transformation des entrées : vous pouvez encoder toutes vos entrées dans une entité de caractères HTML ou du texte pour qu'il n'exécute aucun script. Il existe des fonctions simples et des bibliothèques qui peuvent vous aider à encoder tout votre HTML et JavaScript.

  • Configurez vos cookies avec le flag HttpOnly.

Découvrez les vulnérabilités CSRF (Cross-Site Request Forgery) ?

Un pirate peut créer un lien XSS et le distribuer par le biais de l'ingénierie sociale pour accéder au navigateur d'un utilisateur.

Si l'utilisateur clique sur le lien alors qu'une session est encore ouverte sur sa banque, le pirate peut détourner un jeton de session dans le navigateur (en temps réel) pour accéder à cette session.

Ces requêtes peuvent également rester inactives jusqu'à ce que l'utilisateur ait créé une session sur son navigateur. Regardons l’exemple ci-dessous :

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

 Dans notre exemple, ce lien XSS est un formulaire de demande GET, mais il pourrait aussi bien s'agir d'un formulaire de demande POST. Ce lien effectue une transaction bancaire.

Cette transaction bancaire se produit à l'insu de l'utilisateur qui peut ou non réaliser que le navigateur a toujours la session bancaire ouverte.

Protégez votre application contre une faille CSRF ?

  1. Exiger la réauthentification pour toutes les demandes des utilisateurs.

  2. Utiliser un jeton unique pour chaque demande.

  3. Utiliser des jetons anti-falsification qui valident le jeton côté client par rapport au jeton côté serveur web.

  4. Effectuer des recherches sur les bibliothèques CSRF basées sur la sécurité.

En résumé

  • Une faille cross-site scripting ou XSS est un script qui peut être exécuté dans votre site web.

  • Empêcher une faille XSS avec validation de l'entrée et un encodage de l'entrée.

  • Protégez vos cookies en activant l'option HttpOnly.

  • Les attaques CSRF peuvent se produire via social engineering.

  • Les attaques CSRF effectuent des transactions à l'insu de l'utilisateur.

Dans le prochain chapitre, nous verrons les vulnérabilités XXE et comment s’en prémunir.

Exemple de certificat de réussite
Exemple de certificat de réussite