HTML должен быть закодирован прежде чем быть сохраненным?
HTML должен быть закодирован прежде чем быть сохраненным в, говорят, база данных? Или это - нормальная практика для кодирования продвигающийся к браузеру?
Все мои основанные на тексте длины поля должны быть увеличены в четыре раза в базе данных для обеспечения дополнительного устройства хранения данных?
Поиск лучшей практики, а не тела да или нет :-)
4 ответа
Действительно ли данные в вашей базе данных HTML или это данные приложения, такие как имя или комментарий, которые, как вы случайно знаете, окажутся частью HTML-страница?
Если это данные приложения, я считаю, что лучше всего:
- представить его в форме, естественной для среды (например, не закодированной в базе данных), и
- убедиться, что он правильно переводится как , поскольку он пересекает границы представления (кодируется при создании HTML-страницы).
Если вы поклонник MVC, это также помогает отделить представление / контроллер от модели (и от постоянного формата хранения).
Представление
Например, предположим, что кто-то оставил комментарий «Я люблю M & Ms». Вероятно, проще всего представить это в коде как текстовую строку «Я люблю M & Ms» , а не как закодированную в HTML строку «Я люблю M & Ms» . Технически данные в том виде, в каком они существуют в коде, еще не являются HTML, и жизнь будет проще, если данные будут представлены как можно проще. Эти данные позже могут быть использованы в другом представлении, например настольное приложение.Эти данные могут храниться в базе данных, в плоском файле или в XML-файле, а затем, возможно, использоваться совместно с другой программой. Для другой программы проще всего предположить, что строка находится в «родном» представлении для формата: «Я люблю M & Ms» в базе данных и плоском файле и «Я люблю M & Ms» в XML-файл. Я бы съежился, увидев закодированное в HTML значение, закодированное в XML-файле ( «Я люблю & Ms» ).
Перевод
Позже, , когда данные вот-вот пересекут границу представления (например, отображаются в HTML, хранятся в базе данных, текстовом файле или XML-файле), тогда важно убедитесь, что он правильно переведен, чтобы он был точно представлен в формате, присущем этой следующей среде. Короче говоря, когда вы собираетесь отобразить его на странице HTML, убедитесь, что он переведен в правильно закодированный HTML (вручную или с помощью инструмента), чтобы значение точно отображалось на странице. Когда вы собираетесь сохранить его в базе данных или использовать в запросе, используйте экранирование и / или подготовленные операторы и связанную переменную, чтобы обеспечить точное представление того же концептуального значения в базе данных. Когда вы собираетесь сохранить его в XML-файле, вы гарантируете, что он закодирован в XML.
Неспособность правильно преобразовать при пересечении границ представления является источником атак с использованием инъекций, таких как атаки с использованием SQL-инъекций. Помните об этом, когда работаете с несколькими представлениями / языками (например, Java, SQL, HTML, Javascript, XML и т. Д.).
-
С другой стороны, если вы действительно пытаетесь сохранить фрагменты HTML-страницы в базе данных, мне непонятно, что вы имеете в виду под «закодированными перед сохранением». Если это строго допустимый HTML, все необходимые значения должны быть уже закодированы (например, & , < и т. Д.).
По соображениям безопасности, да, вам следует сначала преобразовать html в их сущности, а затем вставить в базу данных. Такие атаки, как XSS , инициируются, когда вы разрешаете пользователям (или, скорее, плохим парням) использовать теги HTML, а затем обрабатываете / вставляете их в базу данных. XSS - одна из основных причин большинства дыр в безопасности. Так что вам обязательно нужно закодировать свой html перед его сохранением.
На практике кодирование HTML выполняется до отображения отображения .
Если вы последовательны в кодировании перед отображением, вы сделали хорошую часть предотвращения XSS .
Вы должны сохранить исходную форму в своей базе данных. Это сохранило оригинал, и вы можете захотеть выполнить другую обработку для , что , а не для закодированной версии.
Экранирование поставщика базы данных на входе, html-экранирование на выходных данных.