Désinfection PHP XSS

Des questions:

Quelles sont les meilleures fonctions safe1 (), safe2 (), safe3 () et safe4 () pour éviter XSS pour les pages codées UTF8? Est-il également sécurisé dans tous les navigateurs (en particulier IE6)?

<body><?php echo safe1($xss)?></body> <body id="<?php echo safe2($xss)?>"></body> <script type="text/javascript"> var a = "<?php echo safe3($xss)?>"; </script> <style type="text/css"> .myclass {width:<?php echo safe4($xss)?>} </style> 

.

Beaucoup de gens disent que le meilleur absolu possible:

 // safe1 & safe2 $s = htmlentities($s, ENT_QUOTES, "UTF-8"); // But how would you compare the above to: // https://github.com/shadowhand/purifier // OR http://kohanaframework.org/3.0/guide/api/Security#xss_clean // OR is there an even better if not perfect solution? 

.

 // safe3 $s = mb_convert_encoding($s, "UTF-8", "UTF-8"); $s = htmlentities($s, ENT_QUOTES, "UTF-8"); // How would you compare this to using using mysql_real_escape_string($s)? // (Yes, I know this is a DB function) // Some other people also recommend calling json_encode() before passing to htmlentities // What's the best solution? 

.

Il y a beaucoup de publications sur PHP et XSS. La plupart disent simplement "utiliser HTMLPurifier" ou "utiliser htmlspecialchars", ou sont faux. D'autres disent utiliser OWASP – mais il est EXTREMEMENT lent. Certains des bons messages que j'ai rencontrés sont énumérés ci-dessous:

Est-ce que htmlspecialchars et mysql_real_escape_string conservent mon code PHP à l'abri de l'injection?

XSS Me Warnings – problèmes XSS réels

CodeIgniter – pourquoi utiliser xss_clean

safe2() est clairement htmlspecialchars()

Au lieu de safe1() vous devriez vraiment utiliser HTMLPurifier pour désinfecter les blobs complets de HTML. Il distingue les attributs indésirables, les balises et en particulier tout ce qui est javascriptish. Oui, c'est lent, mais il couvre tous les cas de petit bord (même pour les versions IE plus anciennes) qui permettent une réutilisation sécurisée de l'extrait d'utilisateur HTML. Mais consultez http://htmlpurifier.org/comparison pour des solutions de rechange. – Si vous voulez vraiment afficher le texte brut de l'utilisateur (sans html filtré), alors htmlspecialchars(strip_tags($src)) fonctionnerait bien.

safe3() crie une expression régulière. Ici, vous ne pouvez vraiment appliquer qu'une liste blanche à ce que vous voulez réellement:

 var a = "<?php echo preg_replace('/[^-\w\d .,]/', "", $xss)?>"; 

Vous pouvez bien sûr utiliser json_encode ici pour obtenir une syntaxe et une variable JS parfaitement valides. Mais alors, vous venez de retarder l'exploitabilité de cette chaîne dans votre code JS, où vous devez alors la garder.


Est-il également sécurisé dans tous les navigateurs (en particulier IE6)?

Si vous spécifiez explicitement le jeu de caractères, IE ne fera pas sa terrible magie de détection de contenu, donc les exploits UTF7 peuvent être ignorés.

http://php.net/htmlentities notez la section sur le troisième paramètre optionnel qui prend un codage de caractères. Vous devriez utiliser ceci au lieu de mv_convert_encoding. Tant que le fichier php lui-même est enregistré avec un codage utf8 qui devrait fonctionner.

 htmlentities($s, ENT_COMPAT, 'UTF-8'); 

En ce qui concerne l'injection de la variable directement dans javascript, vous pourriez envisager de mettre le contenu dans un élément html caché ailleurs dans la page et de retirer le contenu hors du dom lorsque vous en avez besoin.

Les purificateurs que vous mentionnez sont utilisés lorsque vous souhaitez afficher en réalité html qu'un utilisateur a soumis (comme dans, permettre au navigateur de rendre effectivement). L'utilisation de htmlentities encodera tout ce qui signifie que les caractères seront affichés dans l'ui, mais aucun navigateur ne sera interprété par le navigateur. Que vis-à-vis de faire?