Вопрос по encoding, php, xss, html-entities – Лучшая практика Сохранять ли теги html в БД или сохранять значение сущности html?

4

Мне было интересно, каким образом я должен сделать следующее. Я использую крошечный редактор MCE wysiwyg, который форматирует данные пользователей с правильными HTML-тегами. Теперь мне нужно сохранить эти данные, введенные в редакторе, в таблицу базы данных.

Должен ли я кодировать теги html в соответствующие им объекты при вставке в БД, а затем, когда я получу данные из таблицы, не будет кодировать их для целей XSS, но мне все равно придется использовать eval для форматирования тегов html текст.

ИЛИ ЖЕ

Сохраняю ли я html-теги в базу данных, затем, когда я получаю данные из базы данных, кодирую html-теги в их сущности, но тогда, когда теги появятся у пользователя, мне придется использовать функцию eval, чтобы фактически отформатируйте данные, как они были введены.

Мои мысли о первом варианте, я просто удивился тому, что вы, ребята, подумали.

Ваш Ответ

5   ответов
3

поэтому, когда вы извлекаете его, он готов для рендеринга. Вы не должны конвертировать туда и обратно. То, что вы вставляете, должно быть тем, что вы отображаете. То, что вы хотите сделать, это отфильтровать входные данные, прежде чем поместить его в базу данных. Как tinyMCE, так и ck / fckEditor имеют средства для ограничения тегов, которые можно использовать в редакторе, и он лишит вас этих тегов. Затем вам необходимо выполнить любую другую необходимую проверку или форматирование.

@matt: на пути вы хотите удалить запрещенные теги, исправить недопустимую разметку и т. д., а затем, при его выходе, вы можете применить фильтр для выполнения преобразований, дополнительной фильтрации xss и т. д. до его отображения. но вы хотите, чтобы то, что в базе данных было базовой разметкой, как Адам N, brian_d и Эрлз предлагают в своих ответах. prodigitalson
Я хочу сделать свое приложение максимально безопасным и подумал, что преобразование тегов в их html-объекты с помощью функции htmlentities станет шагом к тому, чтобы сделать его более безопасным. phpNutt
когда вы говорите «фильтровать ввод», вы можете просто уточнить, что вы имеете в виду? phpNutt
2

я решил преобразовать BBCode в HTML (и выполнить проверку работоспособности), а затем поместить его в базу данных. Ну, месяц проходит и оказывается, что у меня была проблема с макетом. Теперь, когда мой старый HTML-код «исправлен» в базе данных, я вскоре узнал, что вы всегда должны сохранять исходный текст, который пользователь использует в базе данных, а затем преобразовывать его позже в запросе.

Это позволяет исправлять ошибки с помощью HTML и XSS, и это имеет обратную силу.

0

и то и другое продезинфицированная версия и оригинальная версия. Я использую это с HTMLPurifier, чтобы избежать проблем с производительностью, которые создаются в режиме реального времени, и в то же время позволяет пользователям редактировать свой контент в его первоначальном виде.

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

4

тественной» форме. Как правило, уровень вашей базы данных не должен интересовать, содержит ли поле HTML, двоичный текст в кодировке Base64 или просто текст. Это касается вашего слоя представления, когда он решает, как визуализировать контент.

Таким образом, хотя вы, возможно, захотите выполнить предварительную проверку на наличие атак XSS, прежде чем вставлять в базу данных, вы всегда должны проверять наличие XSS, прежде чем отправлять «ненадежную» информацию в браузер.

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

Кроме того, подумайте, нужно ли вам отправлять текстовые электронные письма или просматривать данные другими способами. Если ваша база данных нормализована к вашему представлению HTML, то другие преобразования могут быть неудобными, и вам всегда будет интересно, в какой кодировке она находится. Ваше представление всегда может выполнять кэширование, если производительность вызывает сомнения. Matthew
1

оставлял html как есть, в «сыром» виде.

Я знаю, что это делает drupal и применяет фильтры (например, все теги html (без фильтра), только определенные теги, фильтр xss, формат кода php, токены и т. Д.) На лету. Преимущество этого подхода заключается в том, что вы не будете деструктивно изменять свои входные данные, если хотите изменить фильтр, используемый позже.

Похожие вопросы