Suite à notre article récapitulant et décrivant les attaques du TOP 10 OWASP, nous allons revenir sur chacune d’entre elles et expliquer ce qui a été mis en place au sein de notre Cloud de très haute sécurité CerberHost pour y pallier. L’un des fléaux majeurs du Web sont les attaques par Cross Site Scripting, souvent appelées XSS.

Les différents types de Cross Site Scripting (XSS)

XSS - Cross Site ScriptingLes cross site scripting (XSS) sont un des fléaux principaux du Web en termes de volume et de conséquences. Cette attaque est très répandue et une IP est souvent « scannée » plusieurs fois par jour à la recherche de failles de ce type.

Il en existe plusieurs formes, dont les plus courantes sont :

  1. Stored (stockée)
  2. Reflected (réfléchie)

… que nous allons détailler ci dessous.

Les concepts sous-jacent des XSS

Il existe de nombreux moyens d’exploiter les failles dites « XSS ».

Le principe sous-jacent reste le même pour les différents types : faire exécuter à un navigateur du langage JavaScript / HTML (ou parfois d’autres types) pour l’amener à avoir un comportement utile pour le pirate. Le « Cross Site Scripting » consiste littéralement à mettre du code dans le site concerné.

La plupart des XSS réussissent à voir le jour à partir d’une même faille : le contrôle des entrées utilisateurs. Par exemple dans le formulaire d’un site web, si le programmeur (ou son Framework comme Symfony ou Zend le font) a pris soin de contrôler les données envoyées par l’utilisateur, la XSS ne peut avoir lieu. Cependant, très fréquemment, ces entrées ne sont pas contrôlées proprement, voire pas du tout.

Au final, si un pirate envoie du JavaScript dans un champ censé n’accepter qu’un nom de famille, ce JavaScript pourra, dans certaines conditions, être exploité par un pirate. Le programmeur aurait alors du vérifier que seules des lettres pouvant composer un nom de famille puissent être acceptées par son formulaire et non des caractères spécifiques au JavaScript comme < > ‘ %  » etc.

Si le programmeur ne l’a pas fait, un WAF (Web Application Firewall) peut s’en charger s’il est proprement configuré.

La XSS réfléchie

Une explication très simple pour la XSS réfléchie est l’exemple d’un site disposant d’un moteur de recherche, et qui, lorsque l’on tape « ABC » dans la case de recherche, affichera un message « Résultats pour votre recherche ABC ». Alors, si le filtrage ou l’encoding des caractères dangereux n’est pas réalisé, un pirate pourra réaliser une recherche sur « A<script>alert(1)</script> ». Ici, l’effet de la charge JavaScript est inoffensive, mais ce langage peut être utilisé par exemple pour dérober le cookie de l’utilisateur (son jeton d’authentification du site). L’attaquant (dans le cadre d’une XSS réflechie) doit ensuite arriver à convaincre sa victime de suivre un lien spécialement conçu. Dans un contexte e-Commerce, cette étape est souvent triviale.

La XSS stockée

La XSS stockée est en tout point similaire aux XSS réfléchies. Cependant, la XSS stockée est persistante, ce qui la rend souvent encore plus dangereuse. Un cas typique pourrait être celui d’un forum ou tout autre site communautaire, dans lequel le pirate trouverait un moyen d’injection du HTML/JS dans son message. Il sera alors en mesure d’exécuter du code HTML/JS dans le navigateur de toute victime qui visitera le/les sujets sur lesquels il a posté.

L’utilité du WAF dans le cas des XSS

Un WAF (Web Application Firewall) comme NAXSI est un outil capable de faire du nettoyage de trafic et d’interdire les requêtes GET ou POST dangereuses. Ce nettoyage est indispensable pour permettre de protéger un site dont le code source peut être vulnérable.

Son travail consiste essentiellement à étudier si des caractères dangereux sont utilisés en conjonctions avec certains mots. Par exemple, si dans le champs nom d’un formulaire on trouve « robert<script>alert(document.cookie)</script> », c’est anormal.

Les WAF traditionnels (hors NAXSI) utilisent en général un système de signatures et sont donc susceptibles de se faire leurrer si la signature d’une attaque est nouvelle ou modifiée, mais s’ils détectent une signature qui ait la trace d’une action malveillante, il la bloque même si celle-ci est connue.

Les réponses de CerberHost aux attaques de cross site scripting

cerberhostCerberHost dispose naturellement d’un jeu de règles avancées permettant de filtrer une majorité des XSS.

Avant tout mise en production, les sites sont soumis à un audit applicatif intrusif, qui permet par ailleurs d’en révéler les potentielles failles et de générer un jeu de règles encore plus strictes afin de le protéger au mieux.

CerberHost permet aussi, grâce à NAXSI, de faire ce que l’on appelle du Virtual Patching. Cette technique consiste à corriger en amont, sur les reverse proxy ou sur le WAF, des bugs ou failles applicatives, sans corriger le code en lui-même. Il suffit alors de mettre en place des règles protégeant systématiquement l’accès à cette faille en amont.

NAXSI étant très léger, il peut filtrer toutes les requêtes, GET et POST, ce que ne peuvent pas toujours faire les WAF reposants sur des signatures et non sur des règles.

L’exemple type est la faille XML-RPC qu’a connu Magento il y a quelques mois. En appliquant une règle de protection en amont des sites, sur tout notre parc, nous avons pu donner le temps aux Web Agencies et à nos clients de corriger le bug, sans être en risque dans l’intervalle.

Découvrir CerberHost

video de présentation de CerberHost

CerberHost protège contre toutes les failles du TOP 10 Owasp et bien plus.

Pour découvrir CerberHost en images, venez visionner sa vidéo de présentation : ICI

 

Lucie Saunois
Lucie Saunois
Passionnée d'informatique, en particulier de sécurité, depuis qu'elle a rejoint l'OT Group en 2015, Lucie se spécialise dans la vulgarisation technique pour permettre à tous d'appréhender ces sujets parfois complexes.