Я знаю, что этот вопрос задавали снова и снова, но я до сих пор не нашел идеального ответа по своему вкусу, так что вот он снова …
Я читал много и много поляризующих комментариев о Css xss_filter. В основном большинство говорит, что это плохо. Может кто-то уточнить, насколько это плохо или, по крайней мере, дать 1 наиболее вероятный сценарий, где его можно использовать? Я посмотрел на класс безопасности в CI 2.1, и я думаю, что это очень хорошо, так как не допускает вредоносных строк, таких как document.cookie, document.write и т. Д.
Если сайт имеет в основном не-html-презентацию, безопасно ли использовать глобальный xss_filter (или если это ДЕЙСТВИТЕЛЬНО влияет на производительность так сильно, используйте его на основе каждой формы) перед вставкой в базу данных? Я читал о плюсах и минусах о том, следует ли избегать ввода / вывода с большинством голосов, что нам следует избегать только на выходе. Но с другой стороны, почему строки, подобные <a href="javascript:stealCookie()">Click Me</a> будут сохранены в базе данных?
Единственное, что мне не нравится, это javascript: и это будет преобразовано в [removed] . Могу ли я расширить массивы ядра безопасности $_never_allowed_str CI, чтобы никогда не разрешенные строки возвращались пустым, а не [removed] .
Лучший разумный пример неправильного использования этого, который я прочитал, – это если у пользователя есть пароль javascript:123 он будет очищен до [removed]123 что означает, что строка, подобная этому document.write123 , также будет проходить как пароль пользователя. Опять же, какова вероятность того, что это произойдет, и даже если это произойдет, я не могу придумать никакого реального вреда, который может причинить сайту.
благодаря
В основном XSS – проблема OUTPUT, но Codeigniter рассматривает ее как проблему INPUT.
Может кто-то уточнить, как это плохо …
Проблема заключается в том, что xss_clean изменяет ваш INPUT – что означает в некоторых сценариях (например, проблема с паролем, которую вы описали), вход не является ожидаемым.
… или, по крайней мере, дать 1 наиболее вероятный сценарий, где он может быть использован?
Он ищет только определенные ключевые слова, такие как «javascript». Существуют и другие действия скрипта, которые xss_clean не обнаруживает, плюс он не защитит вас от любых «новых» атак.
Единственное, что мне не нравится, это javascript: и это будет преобразовано в [удален]. Могу ли я расширить массивы ядра безопасности $ _never_allowed_str CI, чтобы никогда не разрешенные строки возвращались пустым, а не [удалены]
Вы могли бы это сделать, но вы просто положили бандад на плохое решение.
Я читал о плюсах и минусах о том, следует ли избегать ввода / вывода с большинством голосов, что нам следует избегать только на выходе.
Это правильный ответ – избегайте ВСЕ вашего вывода, и у вас есть настоящая защита XSS, без изменения ввода.
OWASP объясняет больше о XSS здесь
См. Хороший поток форума Codeigniter на XSS
Лично мой подход к защите XSS в Codeigniter – я не делаю никакой очистки XSS на входах. Я запускаю hook на _output – который очищает все мои «view_data» (это переменная, которую я использую для отправки данных в представления).
Я могу переключиться, если я не хочу, чтобы XSS Clean запускался, вставив в мой контроллер «$ view_data ['clean_output] = false», который проверяет хук:
if (( ! isset($this->CI->view_data['clean_output'])) || ($this->CI->view_data['clean_output'])) { // Apply to all in the list $this->CI->view_data = array_map("htmlspecialchars", $this->CI->view_data); }
Это дает мне автоматическую и полную защиту XSS на моем сайте – всего пару паролей кода и отсутствие производительности.