Attaque XSS pour contourner la fonction htmlspecialchars () dans l'attribut value

disons que nous avons ce formulaire, et le possible pour un utilisateur d'injecter du code malveillant est en-dessous de

...
<input type=text name=username value=
       <?php echo htmlspecialchars($_POST['username']); ?>>
...

nous ne pouvons pas simplement mettre une balise, ou un JavaScript:alert(); appeler, parce que la valeur sera interprétée comme une chaîne de caractères, et les caractères spéciaux de HTML filtrent les ,',", de sorte que nous ne pouvons pas fermer la valeur avec des citations.

on peut utiliser String.fromCode(.....), afin de contourner les citations, mais je n'ai toujours pas pu obtenir d'une simple alerte boîte de pop up.

tous des idées?

22
demandé sur L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ 2010-05-24 06:35:57

3 réponses

de plus, il est important de mentionner que le fait de permettre aux gens d'injecter du HTML ou du JavaScript dans votre page (et non dans votre source de données) ne comporte aucun risque de sécurité inhérent en soi. Il existe déjà des extensions de navigateur qui vous permettent de modifier le DOM et les scripts sur les pages web, mais comme c'est seulement côté client, ils sont les seuls qui savent.

où XSS devient un problème est quand les gens a) l'utilisent pour contourner la validation côté client ou le filtrage d'entrée ou b) quand les gens l'utilisent pour manipuler les champs d'entrée (par exemple, changer les valeurs des options dans un ACL pour leur accorder des permissions qu'ils ne devraient pas avoir). La seule façon de prévenir ces attaques est d'épurer et de valider les entrées côté serveur au lieu ou en plus de la validation côté client.

pour assainir HTML hors de l'entrée, les caractères spéciaux HTML sont parfaitement adéquats sauf si vous voulez autoriser certaines balises, auquel cas vous pouvez utiliser une bibliothèque comme HTMLPurifier. Si vous placez l'entrée de l'utilisateur dans HREF, ONCLICK, ou tout attribut qui permet le script, vous demandez juste des problèmes.

EDIT: en regardant votre code, on dirait que vous ne citez pas vos attributs! C'est assez ridicule. Si quelqu'un a mis son nom d'utilisateur:

john onclick="alert('hacking your megabits!1')"

Alors votre script d'analyser:

<input type=text name=username value=john onclick="alert('hacking your megabits!1')">

toujours utiliser des guillemets autour des attributs. Même si elles ne sont pas l'utilisateur saisi, c'est une bonne habitude à prendre.

<input type="text" name="username" value="<?php echo htmlspecialchars($_POST['username']); ?>">
17
répondu Daniel 2010-05-24 03:11:46

Il y a un moyen. Vous ne passez pas htmlspécialchars () le troisième paramètre d'encodage ou la vérification d'encodage correctement, donc:

$source = '<script>alert("xss")</script>';
$source = mb_convert_encoding($source, 'UTF-7');
$source = htmlspecialchars($source); //defaults to ISO-8859-1
header('Content-Type: text/html;charset=UTF-7');
echo '<html><head>' . $source . '</head></html>';

fonctionne seulement si vous pouvez A) définir la page à la sortie UTF-7 ou b) tromper la page à le faire (par exemple iframe sur une page sans un jeu de caractères clair). La solution est de s'assurer que toutes les entrées sont du bon encodage, et que le codage attendu est correctement positionné sur htmlspécialchars().

Comment ça marche? En UTF-7, < > " les caractères sont différents les points de code que UTF-8 / ISO / ASCII de sorte qu'ils ne sont pas échappés à moins de convertir la sortie en UTF-8 pour l'assurance (voir l'extension iconv).

10
répondu padraicb 2010-06-25 16:54:52

value est un attribut HTML normal, et n'a rien à voir avec Javascript.

Par conséquent, String.fromCharCode est interprété comme une valeur littérale, et n'est pas exécutée.

pour injecter script, vous devez d'abord forcer l'analyseur à fermer l'attribut, ce qui sera difficile à faire sans >'".

vous avez oublié de mettre des guillemets autour de la valeur de l'attribut, donc tout ce dont vous avez besoin est un espace.

même si vous citez la valeur, elle peut toujours être vulnérables; voir cette page.

1
répondu SLaks 2010-05-24 02:47:20