Codeigniter xss_clean дилемма

Я знаю, что этот вопрос задавали снова и снова, но я до сих пор не нашел идеальный ответ на свой вкус, поэтому снова и снова ...

Я много и много читал о поляризационных комментариях о xss_filter. В основном большинство говорит, что это плохо. Может кто-нибудь уточнить, как это плохо, или, по крайней мере, привести 1 наиболее вероятный сценарий, где его можно использовать? Я посмотрел на класс безопасности в CI 2.1 и думаю, что он довольно хорош, поскольку не допускает вредоносных строк, таких как document.cookie, document.write и т. Д.

Если сайт в основном не представлен в формате html, безопасно ли использовать глобальный xss_filter (или, если он ДЕЙСТВИТЕЛЬНО влияет на производительность, использовать его для каждой формы после публикации) перед вставкой в базу данных? Я читал о плюсах и минусах о том, следует ли избегать при вводе / выводе, и большинство говорит, что мы должны избегать только при выводе Но опять же, зачем разрешать такие строки как<a href="javascript:stealCookie()">Click Me</a> чтобы вообще сохранить в базе данных?

Единственное, что мне не нравится, этоjavascript: и такие будут преобразованы в[removed]. Могу ли я расширить ядро безопасности CI$_never_allowed_str массивы, так что никогда не разрешенные строки возвращают пустые, а не[removed].

Лучший разумный пример правонарушений, которые я читал, - если у пользователя есть парольjavascript:123 он будет очищен в[removed]123 что означает строку как этаdocument.write123 также будет передаваться как пароль пользователя. Опять же, какова вероятность того, что это произойдет, и даже если это произойдет, я не могу думать о каком-либо реальном вреде, который может нанести сайту.

Благодарност

Ответы на вопрос(1)

но Codeigniter рассматривает ее как проблему ВХОДА.

Кто-нибудь может рассказать, как это плохо ...

Проблема в том, что xss_clean изменяет ваш ВХОД - это означает, что в некоторых сценариях (например, проблема с паролем, которую вы описали) ввод не соответствует ожидаемому.

... или хотя бы один наиболее вероятный сценарий, где его можно использовать?

Он ищет только определенные ключевые слова, такие как «javascript». Существуют другие действия сценария, которые xss_clean не обнаруживает, плюс он не защитит вас от любых «новых» атак.

Единственное, что мне не нравится, это javascript, и он будет преобразован в [удален]. Могу ли я расширить массивы $ _never_allowed_str ядра безопасности CI, чтобы пустые строки возвращались пустыми, а не [удаленными]

Ты мог бы сделать это, но ты просто наложил бандаж на плохое решение.

Я читал о плюсах и минусах о том, следует ли избегать при вводе / выводе, большинство говорит, что мы должны избегать при вывод

Это правильный ответ - избегайте ВСЕХ ваших выходных данных, и вы получите настоящую защиту XSS, не изменяя входные данные.

OWASP объясняет больше о XSS здесь

См. Хорошую ветку на Codeigniter на XSS

Лично мой подход к защите XSS в Codeigniter заключается в том, что я не делаю НИКАКОЙ очистки XSS на входах. Я запускаю ловушку на _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-защиту на всем моем сайте - всего за пару строк кода и без снижения производительности.

 Henson07 июн. 2012 г., 08:48
Более того, вы используете htmlspecialchars, чтобы скрыть все теги HTML, верно? Так что, если вам нужно отобразить данные с тегами HTML? Вы переключаете чистый вывод на false, затем непослушные пользователи, которые замечают, что некоторым участкам сайта разрешены теги, затем вводят ссылки или сильные теги с событием javascript. Так не безопаснее ли сначала дезинфицировать входы?
 Henson07 июн. 2012 г., 08:28
escaping все выходные данные не позволят пользователю использовать даже сильный тег или даже br, не так ли? Как я уже сказал, я планирую использовать xss_clean для каждого поста, а не глобальный фильтр.
 sourcejedi12 авг. 2012 г., 17:37
«Я запускаю ловушку на _output - которая очищает все мои« view_data »(это переменная, которую я использую для отправки данных в представления).» - это работает, только если вы никогда не выводите эти данные в разных контекстах: CSS или javascript, например теги сценария, файлы сценариев, атрибуты обработчика событий. Возможно, некоторые проекты работают с таким строгим разделением, но код, который я рассматривал, не работает, поэтому я не думаю, что это хорошая идея в качестве общего совета. Когда люди говорят, чтобы избежать вашего выхода - это буквально то, что они имеют в виду, бежать в точке выхода.
 Laurence07 июн. 2012 г., 09:28
Это зависит от вас - вы не можете сделать это обоими способами - то есть, если вы разрешите выводить HTML-код вашими пользователями, тогда это огромная дыра в безопасности, и кто-то будет использовать ее в какой-то момент с чем-то «плохим». Вы можете изменить мой код на переменную, а не на весь вывод, если хотите.
 sourcejedi12 авг. 2012 г., 17:25
Если вы хотите выводить HTML, не передавая контроль над вашим сайтом пользователям (и любым «кодам для встраивания», которые они находят в случайных местах в сети), вам крайне необходимо что-то вроде Htmlpurifier.org

Ваш ответ на вопрос