Avec mon exposition limitée à la cybersécurité et le large éventail de sujets qui englobent ce domaine, ma curiosité n'a fait que grandir au fil des ans. Au fur et à mesure que je filtrais les articles et différentes sources de recherche, j'ai voulu partager et documenter un peu plus mon parcours dans la compréhension des cyberattaques. Aujourd'hui, nous allons faire un petit tour d'horizon ensemble sur l'une des cyberattaques les plus courantes : le cross-site scripting (XSS).

Qu'est-ce que le Cross-Site Scripting (XSS) ?

Le cross site scripting , également connu sous son acronyme XSS, est une attaque dans laquelle un attaquant « injecte » des scripts exécutables malveillants dans le code d'une application ou d'un site Web de confiance.

Selon les rapports statistiques d'Edge Scan, les applications Web présentent le risque le plus élevé pour ces types d'attaques.

Comment ces attaques sont-elles autorisées ?

Quelque chose que je me suis toujours demandé était: "Eh bien, comment diable ces attaques sont-elles autorisées en premier lieu?". Ces attaques peuvent se produire en manipulant les requêtes et les réponses HTTP ou le DOM. S'il n'existe aucun protocole de sécurité pour valider ou vérifier les données transmises via les requêtes/réponses HTTP ou même vers le DOM, vous êtes exposé à ces attaques XSS.

Fonctionnement de XSS : une visualisation

• Les pirates sont à la recherche de vulnérabilités de sites Web, dans lesquelles ils peuvent s'introduire dans votre code. Si votre site Web ne prend pas de mesures préventives pour se protéger, les pirates peuvent profiter de ces espaces non protégés pour injecter leurs scripts malveillants.
• Si les scripts sont placés avec succès, les scripts de l'attaquant sont déclenchés.

• Les informations personnelles sont envoyées au pirate.
• Les frappes de l'utilisateur sont capturées.
• Un utilisateur est redirigé vers un site Web malveillant.
• Les informations sur les cookies proviennent d'un utilisateur connecté à un site Web (compromettant ainsi le compte de la victime).

• Attaque XSS réfléchie
• Attaque XSS stockée
• Attaque basée sur DOM

Les attaques réfléchies impliquent que l'entrée d'une requête HTTP est immédiatement reflétée en tant que réponse. Un exemple simple peut être démontré si quelqu'un devait injecter ces attaques de script à l'intérieur du champ de recherche d'un formulaire. Après qu'un utilisateur a « cliqué » sur soumettre, le navigateur reconnaît cette entrée comme HTML, n'y voit rien de malveillant et continue malgré tout à exécuter ce script malveillant. Le code injecté se rend sur le site Web auquel l'utilisateur accède. L'attaque apparaît alors sur le navigateur de l'utilisateur (OWASP).

Vous trouverez ci-dessous un exemple de cela. Un attaquant insère un script malveillant dans le champ de recherche du site Web et, par conséquent, une boîte de dialogue d'alerte apparaît indiquant "xss". Il y a évidemment plus d'intentions malveillantes qu'un attaquant voulant qu'une boîte d'alerte apparaisse sur votre page, mais cet exemple montre à quel point il est facile d'exécuter ces scripts injectés.

Remarque : les attaques réfléchies ne sont PAS enregistrées de manière permanente et ne sont PAS persistantes. Ils ne vivent pas dans une application. Les attaques réfléchies se produisent généralement lorsqu'un utilisateur ouvre un lien suspect ou ouvre une certaine page Web.

Signes d'un lien XSS :

• Un attaquant attire émotionnellement l'attention d'un lecteur, en inventant des scénarios du pire des cas qui rendent une personne très curieuse de cliquer, ce qui peut être illustré dans l'image ci-dessus.
• Il existe une URL raccourcie qui imite l'URL d'une entreprise de confiance. Cela donne à un utilisateur inexpérimenté l'impression qu'il est authentique, s'attendant à ce que le lien redirige vers la page de cette entreprise.
• Cependant, ce lien ne redirige pas vers la vidéo TikTok et à la place, les informations de cookie de l'utilisateur ont été volées, permettant à un attaquant d'accéder à la connexion de l'utilisateur.

Les attaques stockées "stockent" les scripts injectés dans des endroits, comme une base de données ou un serveur, puis utilisent ces données plus tard dans une réponse HTTP. Ces scripts s'injectent directement dans une application Web. Un exemple est lorsqu'un site Web vous permet d'écrire un commentaire. Après avoir soumis votre commentaire, le site Web stocke vos commentaires dans son serveur/base de données. Ainsi, un attaquant peut stocker ses scripts dans la base de données d'un site Web en les commentant. Par conséquent, tous les autres utilisateurs qui parcourent ces pages qui affichent ces commentaires exécutent sans le savoir ces scripts qui sont enregistrés et stockés dans la base de données.

Remarque : les attaques stockées sont enregistrées de manière permanente et sont persistantes . Ils sont également connus sous le nom de « XSS persistants » et sont connus pour être plus dommageables que les attaques réfléchies (Imperva.com). Ils vivent dans une application et peuvent avoir des effets durables.

Attaque XSS basée sur DOM

Le DOM est une API Web. Essentiellement, c'est juste une façon de structurer et une représentation de la façon dont une page Web apparaît. Les langages de script, comme Javascript, utilisent le DOM pour manipuler les éléments DOM qui modifient la structure, le style et l'apparence d'une page Web. Ceci est vital pour l'édition de pages Web.

En raison de sa nature facilement accessible, il a des implications qui permettent une autre forme de XSS : les attaques basées sur DOM. Il est important de noter que les attaques XSS basées sur DOM sont différentes des attaques XSS réfléchies et stockées, car elles "ne touchent pas le serveur Web", contrairement aux attaques XSS réfléchies et stockées.

Cependant, les attaques basées sur DOM peuvent être considérées comme une sous-classe d'attaques réfléchies car elles reflètent une réponse immédiatement, mais plutôt sur le code côté client. (Wikipédia).

Taint Flow et XSS basé sur DOM

Taint-flow est un moyen de visualiser le XSS basé sur DOM. Taint-flow est le processus par lequel des données contaminées circulent dans votre corps de code, au moyen de deux termes clés : sources et puits .

Les sources permettent aux données souillées d'entrer. J'aime utiliser des analogies, donc j'aime envisager les sources comme un portail ou une entrée. Certains exemples bien connus incluent : document.cookie, document.URL, localStorage, sessionStorage.
" En fin de compte, toute propriété pouvant être contrôlée par l'attaquant est une source potentielle" (Portswigger.net).

Les récepteurs exécutent les données fournies par la source. Certains exemples bien connus incluent : document.write , document.body.innerHTML, setTimeOut. Un récepteur courant pour l'injection JavaScript est : eval . Les données entrées à partir de la source sont utilisées comme entrée pour un récepteur, et le récepteur s'exécute lui-même .

Conclusion

Au total, XSS est le processus d'injection de scripts avec une intention malveillante. Les requêtes et les réponses HTTP sont importantes pour comprendre comment les attaques réfléchies et stockées se produisent, tandis que la manipulation DOM et le flux de contamination sont des processus clés pour comprendre comment se produit le XSS basé sur DOM.

Les principales différences entre chaque attaque sont que les attaques XSS réfléchies impliquent que l'entrée d'une requête HTTP est immédiatement reflétée comme une réponse sur votre navigateur, tandis que les attaques XSS stockées "stockent" cette entrée dans quelque chose comme une base de données externe, puis utilisent ces données plus tard dans un Réponse HTTP. Les attaques basées sur DOM impliquent l'injection de scripts malveillants dans le DOM et constituent une sous-classe d'attaques réfléchies.

Les attaques réfléchies sont plus courantes, mais les attaques stockées sont plus dommageables.

Il est important de penser à sécuriser vos applications pour éviter ces types d'attaques qui peuvent sauver de la gymnastique mentale et apaiser votre esprit.

Sources

https://portswigger.net/web-security/dom-based#:~:text=The%20Document%20Object%20Model%20(DOM,of%20how%20modern%20websites%20work

https://www.imperva.com/learn/application-security/cross-site-scripting-xss-attacks/#:~:text=Stored%20XSS%2C%20also%20known%20as,application%2C%20onto%20a%20user's%20browser.