XSS (Cross-Site Scripting) explique pour les dirigeants d'entreprise

Qu'est-ce que le XSS, sans le jargon

Le Cross-Site Scripting, universellement abrege en XSS, est un type d'attaque ou quelqu'un injecte du code JavaScript malveillant dans un site web de sorte qu'il s'execute dans les navigateurs d'autres personnes. Quand un visiteur charge la page affectee, son navigateur execute le code de l'attaquant comme s'il faisait legitimement partie du site.

Pensez-y ainsi : votre site web est un document que les navigateurs de vos visiteurs lisent et affichent. Si un attaquant parvient a glisser ses propres instructions dans ce document, le navigateur de chaque visiteur suivra ces instructions. Le navigateur n'a aucun moyen de distinguer votre code legitime du code injecte par l'attaquant. Il execute tout.

Le XSS figure sur la liste OWASP Top 10 des risques de securite des applications web depuis plus de vingt ans. Malgre cela, il reste l'une des vulnerabilites les plus courantes. La raison est simple : prevenir le XSS exige de la discipline a chaque point ou des donnees entrent et sortent de votre application, et la plupart des developpeurs ne maintiennent pas cette discipline de maniere coherente.

Comment fonctionne le XSS : un exemple concret

Le scenario

Imaginez que le site web de votre entreprise a une fonction de recherche. Un utilisateur tape "chaises de bureau" dans la barre de recherche, et la page affiche : "Vous avez recherche : chaises de bureau" avec les resultats. Le terme de recherche est renvoye sur la page.

Si le developpeur n'a pas encode cet input, un attaquant peut creer une requete de recherche speciale contenant du code JavaScript. Quand une victime clique sur un lien contenant cette requete, le navigateur de la victime execute le code. Le JavaScript envoie les cookies de session de la victime au serveur de l'attaquant. Avec ces cookies, l'attaquant peut usurper l'identite de la victime.

Trois types de XSS

1. XSS Reflechi

Le script malveillant fait partie de la requete (generalement dans un parametre URL) et est renvoye dans la reponse. L'attaque necessite que la victime clique sur un lien specialement concu.

Persistance : Aucune. L'attaque ne fonctionne que lorsque la victime clique sur le lien specifique.

2. XSS Stocke

C'est la variante la plus dangereuse. Le script malveillant est sauvegarde dans la base de donnees du site web et affiche a chaque visiteur qui consulte la page concernee. Les points d'injection courants incluent les champs de commentaires, les posts de forum, les profils utilisateurs et les avis sur les produits.

Persistance : Permanente jusqu'a ce que le contenu malveillant soit supprime de la base de donnees.

Gravite : Elevee a critique. Chaque visiteur est affecte.

3. XSS base sur le DOM

Ce type se produit entierement dans le navigateur, sans que le payload malveillant soit envoye au serveur. La vulnerabilite existe dans le code JavaScript cote client qui traite des fragments d'URL ou d'autres sources de donnees du navigateur de maniere non securisee.

Ce que les attaquants peuvent faire avec le XSS

• Detournement de session : L'attaquant vole le cookie de session de la victime et l'utilise pour usurper son identite. Si la victime est connectee en tant qu'administrateur, l'attaquant a maintenant un acces admin a votre site.
• Recolte de credentials : Le script modifie la page de connexion pour envoyer les identifiants a un serveur externe quand l'utilisateur se connecte.
• Keylogging : Le script capture chaque frappe de l'utilisateur sur la page, y compris mots de passe et numeros de carte de credit.
• Defacement : Le script peut modifier le contenu visible de la page, changer des prix, alterer des descriptions de produits.
• Redirection vers des sites malveillants : Le script redirige silencieusement le visiteur vers un site de phishing ou une page de distribution de malware.
• Minage de cryptomonnaie : Le script utilise le navigateur du visiteur pour miner de la cryptomonnaie en arriere-plan.

Exemples reels de XSS dans les plugins CMS populaires

• CVE-2024-4345 (Starter Templates de Brainstorm Force) : XSS stocke affectant plus d'un million d'installations WordPress.
• CVE-2024-1071 (Ultimate Member Plugin) : XSS stocke dans les champs de profil utilisateur.
• CVE-2023-6961 (WP Meta SEO) : XSS reflechi dans la page de parametres du plugin.
• Contact Form 7 (divers CVE) : Multiples vulnerabilites XSS dans l'un des plugins WordPress les plus populaires, avec plus de 5 millions d'installations actives.

Le schema est constant : partout ou l'input utilisateur est affiche sans encodage correct, le XSS est possible.

Comment tester le XSS (en toute securite)

Test manuel de base

Essayez d'entrer cette chaine dans n'importe quel champ de saisie de votre site web :

<script>alert('XSS')</script>

Si une boite popup apparait, cet input est vulnerable au XSS. Si le texte est affiche comme des caracteres litteraux sur la page, l'input est correctement encode.

Essayez aussi ces variantes :

• <img src=x onerror=alert('XSS')>
• <svg onload=alert('XSS')>

Outils automatises gratuits

• OWASP ZAP : Un outil d'analyse de securite gratuit et open-source.
• Nikto : Un scanner de serveur web open-source.

Prevention : comment stopper le XSS

1. Encodage de la sortie

C'est la defense primaire. Chaque fois que des donnees fournies par l'utilisateur sont inserees dans une page HTML, elles doivent etre encodees pour que le navigateur les traite comme du texte, pas comme du code. La plupart des frameworks web modernes fournissent un encodage automatique de la sortie par defaut (React, Angular, Vue.js, Twig, Blade).

2. Validation des entrees

Validez toutes les entrees cote serveur. Si un champ doit contenir une adresse email, verifiez qu'elle correspond au format email et rejetez tout le reste.

3. Content Security Policy (CSP)

Content Security Policy est un en-tete HTTP qui dit au navigateur quelles sources de JavaScript sont fiables. Une CSP bien configuree peut empecher l'execution de XSS meme s'il est injecte avec succes. Pour en savoir plus sur les en-tetes de securite, consultez notre article sur les en-tetes HTTP de securite pour les sites web.

4. Flags HttpOnly et Secure sur les cookies

Le flag HttpOnly sur les cookies de session empeche JavaScript de les lire. Le flag Secure garantit que les cookies ne sont envoyes que via HTTPS.

Pourquoi la plupart des developpeurs web en Suisse ne testent pas le XSS

• La securite ne fait pas partie de la formation. La plupart des developpeurs web apprennent a faire fonctionner les choses, pas a les securiser.
• Les tests de securite prennent du temps et ne se voient pas. Un site teste pour la securite est visuellement identique a un site non teste, mais il a coute plus cher a construire.
• On suppose que les plugins CMS sont surs. Cette supposition est fausse bien plus souvent qu'elle ne devrait l'etre.
• Personne ne le demande. Les dirigeants d'entreprise demandent rarement "avez-vous teste le XSS ?" pendant un projet web.

L'impact commercial des vulnerabilites XSS

Vol de donnees

Si votre site web traite des donnees personnelles, le XSS peut etre utilise pour les voler. Selon la nLPD suisse et le RGPD europeen, vous etes responsable de la protection des donnees personnelles avec des mesures techniques adequates.

Responsabilite juridique

Si les donnees d'un client sont volees via votre site web a cause d'une classe de vulnerabilite connue que vous n'avez pas testee, votre exposition juridique est significative.

Confiance des clients

Quand les clients decouvrent que votre site web a ete utilise pour voler leurs identifiants, le dommage a la confiance est severe et durable.

SEO et reputation

Google signale activement les sites web qui servent du contenu malveillant. Une attaque XSS qui redirige les visiteurs declenchera les avertissements Google Safe Browsing.

Que faire maintenant

1. Demandez a votre developpeur : "Quelles mesures avez-vous prises pour prevenir le XSS sur notre site ? Pouvez-vous me montrer les resultats des tests ?"
2. Verifiez vos en-tetes de securite : Visitez securityheaders.com et entrez votre domaine. Cherchez l'en-tete Content-Security-Policy.
3. Faites faire une evaluation de securite : Une evaluation professionnelle de la securite identifiera les vulnerabilites XSS et d'autres problemes.
4. Implementez CSP : Meme si vous ne pouvez pas corriger immediatement chaque vulnerabilite XSS, une Content Security Policy fournit un filet de securite.
5. Verifiez vos parametres de cookies : Assurez-vous que les cookies de session ont les flags HttpOnly et Secure.

Le XSS est l'une de ces vulnerabilites qui semblent abstraites jusqu'a ce qu'elles vous arrivent. Mais l'exploitation est reelle, les dommages sont mesurables, et la prevention est bien etablie. Il n'y a aucune raison pour qu'un site web d'entreprise en 2025 soit vulnerable aux attaques XSS.

Si vous avez besoin d'aide pour evaluer l'exposition XSS de votre site web ou implementer des protections, contactez-nous. Nous aidons les entreprises suisses a identifier et corriger les vulnerabilites des applications web avant que les attaquants ne les trouvent.