Можно ли «многократно» чистить данные xss в CodeIgniter?

Question

Ниже приведены способы очистки данных XSS в Codeigniter:

• установите global_xss_filtering в конфигурации на TRUE
• используйте xss_clean()
• используйте xss_clean в качестве правила проверки
• установите второй параметр на TRUE в $this->input->post('something', TRUE)

Можно ли использовать все или более чем один из нихна одном фрагменте данных?

Например, было бы хорошо, если бы я все еще использовал $this->input->post('something', TRUE), даже если данные уже были очищены с помощью правил проверки global_xss_filtering и xss_clean?

Answer 1

Это не повредит вам, но это определенно бессмысленно.

Есть очень хороший шанс, что в конечном итоге вы достигнете точки, когда глобальный XSS-фильтр будет громоздким. Поскольку его невозможно отключить для каждого контроллера без экстенсивных взломов, а доступ к необработанным $_REQUEST данным будет невозможен, вам необходимо отключить его глобально. Это произойдет в тот момент, когда вы захотите обработать один фрагмент доверенных данных или данные, которые не являются выходными данными HTML и должны оставаться нетронутыми.

Использование его в качестве правила проверки формы также бессмысленно и потенциально разрушительно. Представьте, на что был бы похож этот сайт, если бы каждый раз, когда вы набирали <script>, его заменяли на [removed], и в будущем его нельзя было бы вернуть. Для другого примера, что если пользователь использует в своем пароле некоторый контент «XSS»? Ваше приложение в конечном итоге изменит входные данные без уведомления.

Просто используйте XSS-фильтр там, где он вам нужен: в выводе HTML, места, где может выполняться javascript.

Answer 2

Да.Предположим, вы вводите 'A'.Затем, допустим, вы запустили xss_clean для получения XSS-безопасного контента:

B = xss_clean(A)

Теперь, допустим, я делаю это снова, чтобы получить C:

C = css_clean(B)

Теперь, если B и C отличаются, тогда это должно означать, что B имел некоторый xss-небезопасный контент.Что явно означает, что xss_clean сломан, поскольку он не очистил A должным образом.Так что, если вы предполагаете, что функция возвращает содержимое, безопасное для xss, вы можете продолжать.

Один аргумент, который можно сделать, - это что, если функция изменяет даже содержимое, безопасное для xss?Что ж, это было бы отстой, и это все равно означало бы, что функция не работает, но это не так (скажу просто из моего опыта, поскольку я никогда не видел, чтобы она так себя вела).

Единственный недостаток, который я вижу, это дополнительные накладные расходы на обработку, но делать это дважды хорошо (один раз с глобальной фильтрацией и один раз делать это явно, на случай, если глобальная фильтрация когда-нибудь отключена кем-то), и это довольно хорошие накладные расходы дляобеспечение безопасности.

Кроме того, если я могу добавить, codeigniters xss clean на самом деле не анализирует HTML и не удаляет теги и прочее.Он просто конвертирует < и > в < и >.Поэтому, учитывая это, я не вижу ничего, что могло бы пойти не так.

Answer 3

Использование xss_clean хотя бы один раз плохо для меня.Эта процедура пытается очистить ваши данные путем удаления или замены деталей.С потерями и не гарантированно возвращать один и тот же контент при многократном запуске.Это также трудно предсказать и не всегда будет действовать надлежащим образом.Учитывая количество вещей, которые он делает, чтобы попытаться очистить строку, существует огромный удар по производительности для использования этого на входе.Даже самый малый бит ввода, такой как a = b, вызовет волну активности для xss_clean.

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

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

Реально, однако, единственный реальный достойный способ - это правильно закодировать все в представлении в тот момент, когда оно должно отображаться настр.Проблема с преимущественным кодированием заключается в том, что вы храните данные, которые могут быть неправильно закодированы, и вы можете дважды кодировать данные, если они вводятся, затем выводятся в форму, а затем вводятся снова.Если вы думаете о чем-то вроде поля ввода, у вас могут возникнуть серьезные проблемы с ростом данных.Не вся санитария удаляет контент.Например, если вы добавите косую черту, это добавит контент.Если у вас есть косая черта в вашем контенте, каждый раз, когда вы запускаете addlashes, добавляется новая косая черта, заставляющая его расти.Хотя есть большая вероятность, что ваши данные в конечном итоге будут встроены в HTML, вы также не всегда можете точно знать, где эти данные окажутся.Внезапно вы получаете новое требование, которое применяется к предыдущим данным, и все, вы облажались, потому что вы применили фильтр с потерями к входящим данным до их хранения.В данном случае под потерями это может означать вашу работу после повреждения всех пользовательских данных в вашей базе данных.Ваши данные, как правило, наиболее ценная вещь для веб-приложения.Это большая проблема с упреждающим кодированием.С ним легче работать, если вы всегда знаете, что ваши данные чисты и можете избежать их в зависимости от ситуации, но если ваши данные могут быть в любом состоянии в будущем, это может быть очень проблематично.Фильтрация также может вызывать некоторые случайные логические сбои.Так как очистка может удалить содержимое, например, две строки, которые не совпадают, могут быть сопоставлены.

Многие проблемы с xss_clean при вводе аналогичны или аналогичны тем, которые возникают для magic_quotes: http://en.wikipedia.org/wiki/Magic_quotes

Сводка: Вы не должны использовать его, а вместо этого блокировать неверные данные при вводе пользователем и корректно экранировать при выводе.Если вы хотите очистить пользовательские данные, это должно произойти на клиенте (браузер, проверка формы), чтобы пользователь мог их увидеть.Вы никогда не должны иметь невидимое изменение данных.Если вы должны запустить xss_clean.Вы должны запустить его только один раз, на выходе.Если вы собираетесь использовать его для проверки правильности введенных данных, укажите $ posts_data! == xss_clean ($ posts_data), а затем отклоните.