Зачем нужна такая большая очистка ввода HTML? - PullRequest
2 голосов
/ 03 октября 2010

Я реализовал поисковую систему на C для моего сайта HTML.Вся моя сеть запрограммирована на C.

Я понимаю, что санация ввода html необходима, потому что злоумышленник может ввести эти 2 фрагмента html на мою страницу поиска, чтобы заставить мою страницу поиска загружать и отображать сторонние изображения / скрипты (XSS):

<img src="path-to-attack-site"/>
<script>...xss-code-here...</script>

Разве эти атаки не будут предотвращены простым поиском «<» и «>» и удалением их из поискового запроса?Разве это не сделает оба сценария бесполезными, поскольку они не будут считаться HTML?Я видел html-фильтрацию, которая выходит за рамки этого, где они фильтруют абсолютно все команды JavaScript и html-разметку!

Ответы [ 2 ]

16 голосов
/ 03 октября 2010

Входная дезинфекция не является «необходимой».

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

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

HTML-экранирование - это проблема вывода, которая должна быть решена на этапе вывода: то есть обычно в тот момент, когда вы шаблонизируете строки на выходной HTML-странице. Escape < в &lt;, & в &amp;, и в значениях атрибута экранируйте кавычку, которую вы используете в качестве разделителя атрибута, и все. HTML-инъекция невозможна.

Если вы попытаетесь экранировать HTML или отфильтровать на этапе ввода формы, у вас будут трудности при выводе данных, поступивших из другого источника, и вы будете манипулировать пользовательским вводом, который происходит с включает <, & и " символов.

И есть другие формы побега. Если вы пытаетесь создать SQL-запрос с пользовательским значением, вам нужно выполнить экранирование строкового литерала SQL в этой точке, что совершенно отличается от экранирования HTML. Если вы хотите поместить переданное значение в строковый литерал JavaScript, вам нужно будет выполнить экранирование в стиле JSON, что опять-таки совершенно другое. Если вы хотите поместить значение в строковый параметр запроса URL, вам нужно экранировать URL, а не экранировать HTML. Единственный разумный способ справиться с этим - сохранить ваши строки в виде простого текста и экранировать их только в том случае, если вы выводите их в другой контекст, такой как HTML.

Разве эти атаки не будут предотвращены простым поиском '<' и '>' и удалением их из поискового запроса?

Ну да, если вы также удалили амперсанды и кавычки. Но тогда пользователи не смогут использовать эти символы в своем контенте. Представьте, что мы пытаемся вести этот разговор на SO, не имея возможности использовать <, & или "! И если вы хотите удалить каждый символ, который может быть особенным, при использовании в некотором контексте (HTML, JavaScript, CSS ...), вам нужно запретить почти все знаки препинания!

< является допустимым символом, который должен быть разрешен пользователю для ввода и который должен появляться на странице в виде буквального знака «меньше».

Вся моя сеть запрограммирована на C.

Мне очень жаль.

0 голосов
/ 03 октября 2010

Кодирование в скобках действительно достаточно в большинстве случаев для предотвращения XSS, так как все, что находится между тегами, будет отображаться в виде простого текста.

...