CodeIgniter - pourquoi utiliser xss_clean

si je suis désinfection ma DB insère, et aussi échapper à l'HTML, j'ai écris avec htmlentities($text, ENT_COMPAT, 'UTF-8') - il y a tout point de également le filtrage des entrées avec xss_clean? Quels sont les autres avantages donne-t-il?

  • htmlentities($text, ENT_COMPAT, 'UTF-8') n'est pas un bon moyen d'arrêter les attaques de type xss, il n'est pas l'utilisation de ce.
  • htmlentities est absolument étanche à l'HTML-injection, bien que ENT_QUOTES est nécessaire, au lieu de ENT_COMPAT si jamais vous utilisez l'apostrophe attribut délimiteurs. htmlspecialchars est généralement préférable à la htmlentities, bien que, comme il a moins de chance de gâcher le jeu de caractères. CodeIgniter est xss_clean est une valeur de la cargaison-culte de la programmation de la zone de la catastrophe plein de faire fausse route malentendus de ce qui constitue la chaîne de manutention.
InformationsquelleAutor Dan Searle | 2011-03-17
  1. 46

    xss_clean() est vaste, et aussi stupide. 90% de cette fonction ne fait rien pour empêcher les attaques de type xss. Comme à la recherche pour le mot alert mais pas document.cookie. Aucun pirate ne va utiliser alert dans leur exploit, ils vont détourner le cookie avec xss ou lire un jeton CSRF pour faire un XHR.

    Cependant l'exécution de htmlentities() ou htmlspecialchars() avec il est redondant. Un cas où xss_clean() résout le problème et htmlentities($text, ENT_COMPAT, 'UTF-8') échoue est la suivante:

    <?php
print "<img src='$var'>";
?>

    Un simple poc est:

    http://localhost/xss.php?var=http://domain/some_image.gif'%20onload=alert(/xss/)

    Cela va ajouter de la onload= gestionnaire d'événement pour la balise d'image. Un moyen d'arrêter cette forme de xss est htmlspecialchars($var,ENT_QUOTES); ou dans ce cas xss_clean() permettra également d'éviter cela.

    Toutefois, en citant le xss_clean() documentation:

    Rien n'est jamais 100% infaillible, de
    bien sûr, mais je n'ai pas été en mesure d'obtenir
    rien passé le filtre.

    Cela étant dit, XSS est une output problem pas un input problem. Par exemple, cette fonction ne peut pas prendre en compte le fait que la variable est déjà à l'intérieur d'un <script> balise ou un gestionnaire d'événement. Il également ne pas arrêter DOM Basé XSS. Vous avez besoin de prendre en considération la façon dont vous utilisez les données afin d'utiliser la meilleure fonction. Le filtrage de toutes les données d'entrée est un mauvaise pratique. Non seulement est-il incertain mais il corrompt également des données qui peuvent rendre difficiles les comparaisons.

    • Merci. Je suppose que le point important est vraiment "que faites-vous avec les données". Le travail que je travaillais quand j'était modifiable bloc de texte, où je ne voulais pas active des balises HTML à tous, donc ma solution fonctionne dans ce cas. La sortie est déchargé dans un DIV, et avec toutes les balises HTML encodé je ne vois pas comment quelque chose de malveillant pourrait être insérés. Bien sûr, si je voulais permettre à certains de HTML dans les commentaires que compliquer les choses. Pourtant, je ne suis pas trop heureux à l'idée de codage tout en entrée, je préfère traiter en tant que de besoin sur la production (tout en protégeant la base de données de cours).
    • Searle si vous voulez un coffre-fort sous-ensemble de html, alors vous devriez caisse htmlpurifier.org
    • XSS est une sortie de problème et de ne pas en être un problème, c'est pourquoi quelque chose comme xss_clean() pouvez jamais être une approche fiable pour résoudre les problèmes XSS (et xss_clean() lui-même est un laughably terrible de la mise en œuvre même par le bas, du bas niveau de l'anti-XSS outils). Je suis très surpris que vous semblez être une adoption comme une alternative préférable à la sortie au niveau échapper dans votre première phrase.
    • votre totalement correcte. En fait, 90% des contrôles effectués dans xss_clean() ne rien faire pour la sécurité. Telles que la recherche de alert() mais pas document.cookie. Mais plus tard, dans mon post j'ai dit que xss est une sortie de problème, et qu'il n'y a qu'une seule façon que je sais d'où xss est possible. Mais je vais mettre à jour ce post.
    • Merci, c'est mieux! En fait la version actuelle de xss_clean ne semblent chercher document.cookie... même si évidemment, ce n'est encore complètement inutile que ça ne marcherait pas document . cookie, document['cookie'] ou l'une des milliers d'autres façons de se référer à elle.
    • ah ouais c'est une tentative futile de sécurité.
    • Pour être plus précis, la classe de Sécurité (codeigniter\2.1.4\core\Security.php) recherche ces mots: $mots = array('javascript', 'expression', 'vbscript', 'script', 'base64', 'applet', 'alert', 'document', 'écrire', 'cookie', 'fenêtre'); Il aurait rien contre une véritable attaque XSS.

    InformationsquelleAutor rook
  2. 6

    Dans votre cas, "plus strictes méthodes sont beaux, et les plus légers". CodeIgniter les développeurs ont l'intention xss_clean() pour les différents cas d'utilisation, "un système de commentaires ou le forum qui permet de" sûr "balises HTML". Ce n'est pas clair à partir de la documentation, où xss_clean est montré appliqué à un champ nom d'utilisateur.

    Il y a une autre raison de ne jamais utiliser xss_clean(), qui n'a pas été mis en évidence sur stackoverflow jusqu'à présent. xss_clean() a été interrompue pendant Deux mille onze et Deux mille douze, et il est impossible de résoudre complètement. Au moins sans une refonte complète, ce qui n'est pas arrivé. Pour le moment, c'est toujours vulnérable à des chaînes de caractères comme ceci:

    <a href="j&#x26;#x41;vascript:alert%252831337%2529">Hello</a>

    La mise en œuvre actuelle de xss_clean() commence par appliquer efficacement les urldecode() et html_entity_decode() pour l'ensemble de la chaîne. Ceci est nécessaire afin de pouvoir utiliser l'un naïf vérifier pour des choses comme le "javascript:". À la fin, il retourne la chaîne décodée.

    Un attaquant peut simplement encoder leur exploit à deux reprises. Il sera décodé une fois par xss_clean(), et passer aussi propre. Vous disposez ensuite d'un seul codé exploiter, prêtes pour l'exécution dans le navigateur.

    J'appelle ces contrôles "naïve" et irrécupérable parce qu'ils sont largement tributaire des expressions régulières. HTML n'est pas un langage régulier. Vous avez besoin d'un plus puissant analyseur pour correspondre à celui dans le navigateur; xss_clean() n'a pas quelque chose comme ça. C'est peut-être possible de la liste blanche d'un sous-ensemble du langage HTML, qui lexes proprement avec des expressions régulières. Cependant, le courant xss_clean() est très bien une liste noire.

    InformationsquelleAutor sourcejedi
  3. 3

    Je vous conseille d'utiliser http://htmlpurifier.org/ pour faire XSS purification. Je suis en train de travailler sur l'extension de mon CodeIgniter d'Entrée de la classe de tirer parti de cela.

    • Vous avez été en mesure de l'extension de CI pour htmlpurifier?
    • Désolé, j'ai depuis longtemps passé à Laravel. 🙂
    InformationsquelleAutor Anthony
  4. 2

    Oui, vous devriez toujours être en l'utilisant, en général, je faire une règle pour l'utiliser au moins sur face au public, entrée, sens de l'entrée que tout le monde peut accéder et de se soumettre.

    Généralement désinfection à l'entrée pour les requêtes DB semble comme un effet secondaire que le vrai but de la fonction est d'empêcher Le Cross-site Scripting Attaques.

    Je ne vais pas entrer dans les détails concrets de chaque étape xss_clean prend, mais je vais vous dire, il fait plus que les quelques étapes que vous avez mentionné, j'ai pastied la source de la xss_clean fonction de sorte que vous pouvez regarder vous-même, il est entièrement commenté.

    InformationsquelleAutor jondavidjohn
  5. 0

    Si vous voulez que le filtre à exécuter automatiquement à chaque fois qu'il rencontre la POSTE ou données COOKIES, vous pouvez l'activer par l'ouverture de votre application/config/config.php fichier et le réglage de ce paramètre:
    $config['global_xss_filtering'] = TRUE;

    Vous pouvez activer la protection csrf par l'ouverture de votre application/config/config.php fichier et le réglage de ce paramètre:
    $config['csrf_protection'] = TRUE;

    pour plus de détails, veuillez consulter le lien suivant.

    https://ellislab.com/codeigniter/user-guide/libraries/security.html

    • Ils ne recommandent pas de global_xss_filtering maintenant. Voir: codeigniter.com/user_guide/libraries/input.html "Le" global_xss_filtering’ paramètre est OBSOLÈTE et conservée uniquement pour compatibilité ascendante fins. XSS échappement doivent être effectuées sur la sortie, pas d'entrée!"
    InformationsquelleAutor shankar kumar