если я дезинфицирую свои вставки в БД, а также избегаю HTML, который я пишу с помощью htmlentities($text, ENT_COMPAT, 'UTF-8')
- есть ли смысл фильтровать входы с помощью xss_clean? Какие еще преимущества он дает?
CodeIgniter - зачем использовать xss_clean
Ответ 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&#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