Et voici à quoi ressemblait le code source de la page :
<html><meta HTTP-EQUIV="REFRESH"
CONTENT="0;URL=">/></head><body></body>
Ainsi, un script de redirection tout bête, qui prend une url et redirige l'utilisateur dessus se trouve être une ouverture aux attaques par XSS et également un outil de DOS (Denial Of Service, un trop grand nombre de requêtes en peu de temps sature le serveur).
Un autre trou dans lequel aiment à se lover les failles XSS est les pages d'erreurs. Nottament ces 404 qui ressortent, sans le filtrer, le referer, ou n'importe quelle information des headers.
Ceci démontre deux choses, la première est la difficulté de se protéger contre les failles XSS (deux furent découvertes sur le site de papal cette semaine!), la seconde est l'ampleur des attaques qui peuvent être menées via de telles failles, encore considérées par certains comme des failles mineures.
Peut être car les preuves de concept semblent enfantines, ("Qu'ils sont mignons ces hackers avec leurs petites boites de dialogue qui leur disent "Hello" ou "XSS").
Petit hors sujet pour terminer cet article :
Une XSS dans un webmail est plus qu'ennuyeux, si vous désirez tester la fiabilité du votre, il existe un outil efficace, le mailgun de Mario Heiderich (from Gnucitizen quand même...). Cet outil à utiliser avec prudence tout de même vous envoi un email contenant toute la base de vecteurs XSS du Gnucitizen think-tank!
2 commentaires:
Ce type de DOS (côté client) n'est pas plus efficace qu'une SYN storm, c'est-à-dire négligeable étant donné la différence de puissance et de bande passante entre le serveur et une connexion ADSL. Par contre c'est vrai que ca cause un gros problème niveau pishing :/
Je ne parlais pas de l'effet causé par un seul client, mais plutôt de celui qui pourrait être généré par le renvoi (par exemple via des CSRF, avec d'autres XSS) d'un nombre important d'utilisateurs sur cette page.
Enregistrer un commentaire