Подтвердить что ты не робот

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

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

4b9b3361

Ответ 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():

Конечно, ничто не может быть абсолютно надежным, но я не смог ничего пройти через фильтр.

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

Ответ 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() - очень черный список.

Ответ 3

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

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

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

Ответ 4

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

Ответ 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