2015-07-04 3 views
0

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

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

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

+0

В настоящее время, вероятно, проще просто использовать «Полицию безопасности контента», чтобы предотвратить выполнение встроенного сценария в целом. Это должно быть сделано в любом случае. – arkascha

+0

Почему бы не «htmlspecialchars» быть достаточным для вывода полей текстового содержимого в этой таблице? Или это связано с тем, что контент, добавленный администратором, обрабатывается иначе, чем указанные текстовые поля, предоставленные пользователем? – mario

ответ

1

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

Да, так оно и есть. Они получают безобидный и корректный вывод как &lt;script&gt;.

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

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

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

+0

Я снова проверил свой код, и мне стыдно сказать, что в одном сценарии пропал «htmlspecialchars», что вызвало ошибку. Большое спасибо за вклад в HTMLPurifier, я не был уверен, правильно ли я использовал его, но теперь я это делаю! – Paul

+0

Да, это очень легко пропустить.Жаль, что PHP по-прежнему не имеет возможности скрываться по умолчанию. – bobince

0

Перед тем, как сохранить его в базе данных, необходимо проверить и очистить его. Принцип заключается в том, что вы НЕ ДОПУСКАете ничего, что приходит от пользователя.

ВСЕГДА избегайте всего.

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

+0

Это немного мягкий совет. Вопрос также был не в том, что происходит сбой базы данных (что в настоящее время не является проблемой, если вы не живете под скалой). – mario

+0

Я предположил, что если вы правильно удаляете данные, прежде чем вставлять их в базу данных, им просто не нужно их избегать после этого ... – codelame

+0

Иногда бывает целесообразно предварительно избавиться от вещей. Если ваше приложение legacy-ish недостаточно заботится, тогда может быть сделан более безопасный, чем извините подход (HTML-выход из хранилища DB). Как правило, вы не хотите обфускать данные только для одного выходного контекста. – mario

Смежные вопросы