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

Question

, если я очищаю вставки в БД, а также экранирую HTML, который пишу с помощью htmlentities($text, ENT_COMPAT, 'UTF-8') - есть ли смысл фильтровать входные данные с помощью xss_clean? Какие еще преимущества это дает?

Answer 1

xss_clean () обширный, а также глупый. 90% этой функции не делает ничего, чтобы предотвратить xss. Например, ищет слово alert, но не document.cookie. Ни один хакер не собирается использовать alert в своем эксплойте, они собираются перехватить cookie с помощью xss или прочитать токен CSRF для создания XHR.

Однако выполнение htmlentities() или htmlspecialchars() с ним является избыточным. Случай, когда xss_clean() устраняет проблему, а htmlentities($text, ENT_COMPAT, 'UTF-8') дает сбой, является следующим:

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

Простой документ:

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

Это добавит обработчик события onload= к тегу изображения. Метод остановки этой формы xss - htmlspecialchars($var,ENT_QUOTES); или в этом случае xss_clean() также предотвратит это.

Однако, цитата из документации xss_clean ():

Ничто не может быть надежным на 100% конечно, но я не смог получить что-нибудь прошло фильтр.

При этом XSS - это output problem , а не и input problem. Например, эта функция не может учитывать, что переменная уже находится в теге <script> или обработчике события. Это также не останавливает XSS на основе DOM. Вам нужно учитывать , как вы используете данные , чтобы использовать наилучшую функцию. Фильтрация всех данных на входе - это плохая практика . Он не только небезопасен, но и искажает данные, что затрудняет сравнение.

Answer 2

В вашем случае, "более строгие методы хороши и легче" .Разработчики CodeIgniter предполагают использование xss_clean () для другого варианта использования, «системы комментирования или форума, который позволяет« безопасные »теги HTML».Это не ясно из документации, где показано, что xss_clean применяется к полю имени пользователя.

Есть еще одна причина никогда не использовать xss_clean (), которая до сих пор не была выделена в stackoverflow.xss_clean () был сломан во время 2011 и 2012 , и исправить это невозможно.По крайней мере, без полного редизайна, чего не произошло. В настоящее время он по-прежнему уязвим для таких строк:

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

Текущая реализация xss_clean () начинается с эффективного применения urldecode () и html_entity_decode () ко всей строке.Это необходимо, чтобы он мог использовать наивную проверку для таких вещей, как «javascript:».В конце возвращает декодированную строку .

Злоумышленник может просто дважды зашифровать свой эксплойт.Он будет декодирован один раз с помощью xss_clean () и передан как чистый.Затем у вас есть эксплойт с одиночным кодированием, готовый к выполнению в браузере.

Я называю эти проверки «наивными» и нефиксируемыми, поскольку они в значительной степени зависят от регулярных выражений.HTML не является обычным языком. Вам нужен более мощный парсер, чтобы он соответствовал парсеру в браузере ;xss_clean () не имеет ничего подобного.Может быть, можно внести в белый список подмножество HTML, которое аккуратно связывается с регулярными выражениями.Однако текущий xss_clean () очень похож на черный список.

Answer 3

Я бы рекомендовал использовать http://htmlpurifier.org/ для очистки XSS. Я работаю над расширением своего класса CodeIgniter Input, чтобы начать его использовать.

Answer 4

Да, вы все равно должны его использовать, я обычно устанавливаю правило использовать его, по крайней мере, на общедоступном входе , означающем любой вход, к которому каждый может получить доступ и отправить.

Как правило, очистка входных данных для запросов к БД выглядит побочным эффектом, так как истинная цель этой функции - предотвратить межсайтовых скриптовых атак .

Я не буду вдаваться вподробности каждого шага xss_clean, но я скажу вам, что он делает больше, чем несколько упомянутых вами шагов, я вставил источник функции xss_clean , так что вы можете посмотреть сами, это полностью прокомментировано.

Answer 5

Если вы хотите, чтобы фильтр запускался автоматически каждый раз, когда он встречает данные POST или COOKIE, вы можете включить его, открыв файл application / config / config.php и установив его: $ config ['global_xss_filtering'] = TRUE;

Вы можете включить защиту csrf, открыв файл application / config / config.php и установив его: $ config ['csrf_protection'] = TRUE;

для получения более подробной информации, см. Следующую ссылку.

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