📣#Hiring : un-e ingénieur-e avant-vente #cybersécurité pour rejoindre notre équipe 🎉👋 Vous accompagnerez nos clients depuis le diagnostic technique de leurs besoins jusqu’à la proposition de solutions adaptées à leur contexte 🤝 👉 https://t.co/45lwHRqFSd #cyberjob

[Hiring 👀] Nous recherchons un-e stagiaire #pentester pour rejoindre notre équipe sur Lyon 🎉👋 L’annonce et toutes les infos → https://t.co/Vh06YRigFe #infosecjobs #cyberjob #stage

XSS, a.k.a (Cross-site Scripting), une vulnérabilité particulièrement répandue sur les applications web : un thread 🧵 1/15 #devweb #websecurite

Nous serons à #TechRocks 🤗 Qui sera aussi de la partie ? Allons prendre un café ensemble ☕️ #cto #tech #it

Dans un prochain thread, nous expliquerons comment se prémunir des failles XSS, cependant si vous ne pouvez pas attendre 🤓, vous trouverez plus d’informations ici 👉 https://t.co/dZK7CXaJJZ 15/15

3️⃣ les DOM based XSS : Ce type de XSS est moins connu que les deux précédentes, mais l’idée est que cette attaque est uniquement exécutée coté client sans intervention du serveur. Vous trouverez plus d’informations sur les DOM-XSS ici 👉 https://t.co/4TG4ujgLw5 14/15

2️⃣ les XSS reflétées : Dans ce cas-là, le script malveillant est fourni dans l’URL et repris dans la réponse du serveur. Cette attaque nécessite donc une interaction de l’utilisateur (cliquer sur le lien) 13/15

1️⃣ les XSS stockées : Comme dans l’exemple ci-dessus, le script malveillant (le script src…) sera stocké sur le serveur. Cela aura pour conséquence que tous les utilisateurs qui affichent la donnée non nettoyée exécuteront le script 12/15

Pour en revenir aux XSS, il faut savoir qu’il en existe 3️⃣ types 11/15

Dans le cas où le back office est filtré par IP, il est toujours possible avec le JavaScript de récupérer toutes les informations de la page (DOM) et aussi d’exécuter les requêtes, donc un attaquant pourra quand même exploiter la XSS 10/15

Comme l’attaquant possède maintenant un jeton de session, il peut maintenant usurper le compte du backoffice et donc être super admin 9/15

<auto_promo> Si vous ne connaissez pas les #JWT, nous y avons dédié un article, disponible ici 👉 https://t.co/20Y87ANT1S </auto_promo /> 8/15

Peu après l’attaquant reçoit une alerte, il voit que l’URL est superbackofficecache.sitevulnerable.local (superbe interface superadministrateur), et même s’il n’a pas réussi à voler le cookie de session, il a pu avoir un token JWT d’authentification dans le local storage 7/15

L’algorithme du script est le suivant : · essayer de récupérer le cookie de session (si possible) · récupérer le local storage · récupérer l’URL qui a exécuté le code · prévenir l’attaquant 6/15

Exemple : Une application permet à un utilisateur de saisir son nom d’utilisateur, un attaquant va par exemple saisir le code suivant : 5/15

Avec du JavaScript interprété, plusieurs scénarios sont possibles comme le vol de session, la récupération d’informations sensibles sur la page… 4/15

Mais du coup les XSS ça injecte quoi ? Les attaques XSS vont injecter du code JavaScript qui sera interprété par le navigateur du client 💣 Cette injection va donc cibler les utilisateurs de l’application vulnérable, contrairement à une injection SQL qui va viser le serveur

Qu’est-ce qu’une faille XSS ? Une #XSS est une vulnérabilité de type injection 💉, tout comme les injections SQL L’idée est donc d’injecter du code qui sera interprété   2/15 #codeinjection #vulnerabilité

XSS, a.k.a (Cross-site Scripting), une vulnérabilité particulièrement répandue sur les applications web : un thread 🧵 1/15 #devweb #websecurite

Contourner le login via une injection SQL Un thread  1/10 #SQLi #injectionSQL #websecurite