Это плохая идея, чтобы избежать HTML перед вставкой в ​​базу данных вместо вывода?

Question

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

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

Answer 1

Да, потому что на каком-то этапе вам понадобится доступ к введенному исходному вводу. Это потому что ...

• Вы никогда не знаете, как вы хотите отобразить это - в JSON, в HTML, в виде SMS?
• Вы можете показать его пользователю как .

Я понимаю, что вы никогда не хотели вводить HTML. Что вы используете для удаления тегов HTML? Если это регулярное выражение, обратите внимание на запутанных пользователей, которые могут напечатать что-то вроде этого ...

3<4 :->

Они получат 3, только если это регулярное выражение.

Answer 2

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

если вы сохранили экранированный html в вашей базе данных, вам сначала нужно «удалить» значение, хранящееся в базе данных, просто чтобы снова экранировать его в другом формате.

также смотрите эту прекрасную статью о предотвращении xss

Answer 3

1. Еще одна неуловимая проблема: предположим, вы вводите запись со строкой R&B в заголовке.Он будет сохранен как R&B.И предположим, что у нас есть функция поиска, которая использует SQL:

   $query = $database->prepare('SELECT * FROM table WHERE title LIKE ?');
   $query->execute(array($searchString.'%'));    
   

   Теперь, если кто-то ищет R&B, он не будет соответствовать этой строке, так как он хранится как R&B.Ситуация одинакова для равенства, сортировки и т. Д.

   Конечно, здесь у нас возникает проблема не искать теги HTML, так как <span> будут совпадать, когда кто-то ищет span.Эту проблему можно решить, делегировав функции поиска какому-либо внешнему сервису, например, Solr, или сохранив версию во втором поле, очищенном от тегов HTML, специальных символов и тому подобного (для полнотекстового поиска), аналогично тому, что предлагал @limscoder.

2. Однажды вы можете раскрывать свои данные через API или что-то еще, и ваши пользователи API могут считать, что они не экранированы.

3. НесколькоЧерез несколько месяцев новый член команды присоединяется.Как хорошо обученный разработчик, он всегда использует html-экранирование, теперь только для того, чтобы увидеть, что все экранировано дважды (например, появляются заголовки, например He said "nuff" вместо He said "nuff").

4. Стиль цитаты из htmlspecialchars() (например, ENT_QUOTES, ENT_COMPAT и т. Д.) Будет кусать вас, если вы используете что-то отличное от стандартного и забыли использовать один и тот же стиль цитирования при сохранении / выводе.

   Аналогичная проблема возникает, когда вы используете htmlentities() для хранения и htmlspecialchars() для вывода или наоборот (с соответствующими функциями счетчика).Ваш HTML будет загрязнен Ü с, Ç с и т. Д.

   Они более подвержены злоупотреблению, если над одной базой кода работают несколько разработчиков.

Answer 4

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