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