2010-05-24 10 views
21

Disons que nous avons cette forme, et la partie possible pour un utilisateur d'injecter du code malveillant est ce ci-dessousfonction attaque XSS à htmlspecialchar dérivation() dans l'attribut de valeur

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

Nous ne pouvons pas simplement mettre un , ou un javascript: alert(); appeler, parce que la valeur sera interprétée comme une chaîne, et htmlspecialchars filtre les <,>, ",", donc nous ne pouvons pas fermer la valeur avec des citations.

Nous pouvons utiliser String.fromCode (... ..) pour contourner les citations, mais je reste incapable d'obtenir une simple boîte d'alerte pour faire apparaître.

Toutes les idées?

+0

Excellente question, parce que je Je me fie à htmlspecialchars() pour la sécurité - comme le font, j'en suis sûr, beaucoup de gens ... je me demande si vous pouvez glisser un eval() ou quelque chose ... d'autant plus que je crois que le navigateur se déshabilite avant de passer Je pense que ce serait plus exploitable si vous insérez des données utilisateur dans un attribut onclick ou href ou un autre exécutable, l'exploitation d'un attribut de valeur semble plus difficile –

+0

@Frank: Si vous mettez des données malveillantes dans Javascript, vous devez l'encoder Javascript aussi – SLaks

Répondre

17

En outre, il est important de mentionner qu'autoriser les personnes à injecter du code HTML ou JavaScript dans votre page (et non votre source de données) ne comporte aucun risque de sécurité intrinsèque. Il existe déjà des extensions de navigateurs qui vous permettent de modifier le DOM et les scripts sur les pages web, mais comme ce n'est que du côté client, ils sont les seuls à le savoir. Où XSS devient un problème, c'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 des champs d'entrée (par exemple, changer les valeurs des étiquettes OPTION dans une ACL pour Accordez-leur des permissions qu'ils ne devraient pas avoir). La seule façon de prévenir ces attaques est de désinfecter et de valider les entrées côté serveur au lieu ou en plus de la validation côté client. Pour désinfecter le code HTML en entrée, htmlspecialchars est parfaitement approprié sauf si vous voulez autoriser certaines balises, auquel cas vous pouvez utiliser une bibliothèque comme HTMLPurifier. Si vous placez une entrée utilisateur dans HREF, ONCLICK ou tout autre attribut permettant de créer des scripts, vous demandez simplement des problèmes.

EDIT: En regardant votre code, il semble que vous ne citez pas vos attributs! C'est plutôt idiot. Si quelqu'un a mis son nom d'utilisateur comme:

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

Ensuite, votre script pourrait analyser comme:

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

TOUJOURS citations attributs autour. Même s'ils ne sont pas saisis par l'utilisateur, c'est une bonne habitude à prendre.

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

Bien que je suis d'accord que vous devriez citer, 'htmlspecialchars' remplace les guillemets simples et doubles. –

+0

bien sûr! Merci! – Setzer

+0

L'espace est correct, mais vous ne pouvez toujours pas utiliser de citations, c'est à ce moment que String.fromCharCode sera utile pour l'attaque ci-dessus – Setzer

1

value est un attribut HTML normal et n'a rien à voir avec Javascript.
Par conséquent, String.fromCharCode est interprété en tant que valeur littérale et n'est pas exécuté

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

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

Même si vous citez la valeur, elle peut toujours être vulnérable; voir this page.

+1

Vraiment? Comment pouvez-vous exécuter du code à l'intérieur d'une «valeur» entre guillemets lorsque vous ne pouvez pas fermer le devis? –

+1

Je chec ked cette page, mais je ne peux pas voir une attaque qui va contourner htmlspecialchars et l'attribut est cité – Setzer

10

Il y a un moyen.Vous n'êtes pas de passage htmlspecialchars() le troisième paramètre de codage ou de contrôle correctement l'encodage, 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>'; 

ne fonctionne que si vous pouvez a) définir la page de sortie UTF-7 ou b) duper la page en faisant (par exemple iframe sur une page sans jeu de caractères clair). La solution consiste à s'assurer que toutes les entrées ont le codage correct et que le codage attendu est correctement défini sur htmlspecialchars().

Comment ça marche? Dans UTF-7, <> "les chars ont des points de code différents de UTF-8/ISO/ASCII, donc ils ne sont pas échappés à moins que convertissent la sortie en UTF-8 pour l'assurance (voir iconv extension)

+0

Je dis que 'htmlentities()' devrait être utilisé à la place de 'htmlspecialchars()', avec 'ENT_QUOTES | ENT_HTML5' drapeaux. ;) –