Должен ли весь вывод очищаться в PHP?

Я создаю довольно небольшое веб-приложение на PHP, где (доверенный) администратор может, среди прочего, хранить сотни объектов в базе данных. Пользователь может ввести ряд сведений об этих объектах в виде текстовых полей (элемент ввода с атрибутом type, установленным на «текст»).

Объекты с их деталями отображаются в виде таблицы, экранированной функцией htmlspecialchars. Однако эта функция не защищает от злонамеренного использования тегов html, например, тега <script>.

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


php input security htmlpurifier
person Paul    schedule 04.07.2015    source источник
comment
Вероятно, в наши дни проще просто использовать политику безопасности контента, чтобы предотвратить выполнение встроенного скрипта в целом. Это надо сделать в любом случае.   -  person arkascha    schedule 04.07.2015
comment
Почему htmlspecialchars недостаточно для вывода текстовых полей этой таблицы? Или речь идет о том, что контент, добавленный администратором, обрабатывается иначе, чем упомянутые текстовые поля, предоставленные пользователем?   -  person mario    schedule 04.07.2015

Ответы (2)


arrow_upward
1
arrow_downward

Объекты с их деталями отображаются в виде таблицы, экранированной функцией htmlspecialchars. Однако эта функция не защищает от злонамеренного использования тегов html, например, тега <script>.

Да, это так. Они безвредно и корректно выводятся как &lt;script&gt;.

Вопрос в том, должны ли все введенные пользователем данные (каждая ячейка в таблице) очищаться чем-то вроде HTMLPurifier.

Неа. Вы должны использовать HTMLPurifier только в тех полях, где вы намеренно разрешаете пользователю вводить разметку для прямого рендеринга на странице, например, в системе комментариев, где пользователь может ввести <i> для курсива.

Для другого ввода, который вы обрабатываете как обычный текст, htmlspecialchars остается правильным при выводе в HTML.

person bobince    schedule 04.07.2015
comment
Я снова проверил свой код, и мне стыдно признаться, что в одном сценарии отсутствовал htmlspecialchars, что и вызвало ошибку. Большое спасибо за информацию о HTMLPurifier, я не был уверен, правильно ли я его использовал, но теперь я уверен! - person Paul; 04.07.2015
comment
Да, действительно легко пропустить один. Жаль, что PHP по-прежнему не имеет возможности выхода по умолчанию. - person bobince; 04.07.2015

arrow_upward
1
arrow_downward

Все должно быть проверено и очищено перед сохранением в базе данных. Принцип заключается в том, что вы НЕ ДОВЕРЯЕТЕ ничему, что исходит от пользователя.

ВСЕГДА бежать от всего.

Или просто используйте инструменты, которые сделают это за вас, например фреймворки.

person codelame    schedule 04.07.2015
comment
Это немного мягкий совет. Вопрос также не касался экранирования базы данных (что в настоящее время практически не является проблемой, если только вы не жили под скалой). - person mario; 04.07.2015
comment
Я предположил, что если вы правильно экранируете данные перед помещением в базу данных, после этого просто не нужно экранировать их... - person codelame; 04.07.2015
comment
Иногда имеет смысл предварительно сбежать от вещей. Если ваше устаревшее приложение недостаточно заботится о нем, то может подойти подход «лучше безопасно, чем сожалеть» (экранирование HTML перед хранением в БД). Однако обычно вы не хотите запутывать данные только для одного выходного контекста. - person mario; 04.07.2015