Дезинфекция PHP XSS

Вопросов:

Каковы наилучшие функции safe1 (), safe2 (), safe3 () и safe4 (), чтобы избежать XSS для кодированных страниц UTF8? Это также безопасно во всех браузерах (в частности, 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> 

,

Многие говорят, что самое лучшее, что можно сделать:

 // 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? 

,

Есть много сообщений о PHP и XSS. Большинство просто говорят «использовать HTMLPurifier» или «использовать htmlspecialchars» или ошибаются. Другие говорят, что используют OWASP – но это ЧРЕЗВЫЧАЙНО медленно. Некоторые из хороших сообщений, с которыми я столкнулся, перечислены ниже:

Должны ли htmlspecialchars и mysql_real_escape_string сохранить код PHP безопасным от инъекции?

XSS Me Warnings – реальные проблемы XSS?

CodeIgniter – зачем использовать xss_clean

safe2() явно htmlspecialchars()

Вместо safe1() вы действительно должны использовать HTMLPurifier для дезинфекции полных капель HTML. Он удаляет нежелательные атрибуты, теги и, в частности, что-то javascriptish. Да, он медленный, но он охватывает все мелкие края (даже для более старых версий IE), которые позволяют безопасное повторное использование фрагмента HTML-файла. Но ознакомьтесь с http://htmlpurifier.org/comparison для альтернатив. – Если вы действительно хотите отображать необработанный текст пользователя (не фильтрованный html), то htmlspecialchars(strip_tags($src)) действительно будет работать нормально.

safe3() кричит регулярное выражение. Здесь вы можете реально применить только белый список к тому, что вы действительно хотите:

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

Вы можете, конечно, использовать json_encode здесь, чтобы получить совершенно корректный синтаксис JS и переменную. Но тогда вы просто задерживаете эксплойтируемость этой строки в своем JS-коде, где вы должны присматривать за ней.


Это также безопасно во всех браузерах (в частности, IE6)?

Если вы явно укажете кодировку, IE не будет делать свою ужасную магию обнаружения контента, поэтому эксплойты UTF7 можно игнорировать.

http://php.net/htmlentities отмечают раздел о необязательном третьем параметре, который принимает кодировку символов. Вы должны использовать это вместо mv_convert_encoding. До тех пор, пока сам файл php будет сохранен с помощью кодировки utf8, которая должна работать.

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

Что касается инъекции переменной непосредственно в javascript, вы можете подумать о том, чтобы разместить содержимое в скрытый элемент html где-то еще на странице и вытащить содержимое из dom, когда вам это нужно.

Очистители, которые вы упоминаете, используются, когда вы хотите фактически отображать html, который пользователь отправил (как и в случае, чтобы браузер действительно отображал). Использование htmlentities будет кодировать все, чтобы символы отображались в ui, но ни один из фактического кода не будет интерпретироваться браузером. На что вы нацелены?