Когда фильтровать/санировать данные: перед вставкой базы данных или перед дисплеем?

Мне нравится иметь / хранить данные в исходном виде. Я экранирую / фильтрую данные только в зависимости от того, где я их использую.

• на веб-странице - кодировать весь html
• на sql - убивать кавычки
• на url - urlencoding
• на принтерах - кодировать escape-команды
• для чего угодно - закодируйте его для этого задания

Существует как минимум два типа фильтрации / очистки, о которых вам следует позаботиться:

• SQL
• HTML

Очевидно, о первом нужно позаботиться до / когда вставка данных в базу данных для предотвращения SQL-инъекций.
Но вы уже знаете это, как вы сказали, поэтому я не буду больше об этом говорить.

Второй вопрос, с другой стороны, более интересный:

• должны ли ваши пользователи иметь возможность для редактирования своих данных интересно вернуть их в том виде, в каком они вводили их вначале; это означает, что вам нужно сохранить версию, "не содержащую html-specialchars-escaped".
• если вы хотите, чтобы отображался некоторый HTML, вы можете использовать что-то вроде HTMLPurifier : очень мощный ... Но может потребоваться слишком много ресурсов, если вы запускаете его для всех данных, когда они должны отображаться ...

Итак:

• Если вы хотите отобразить некоторый HTML, используйте тяжелый инструмент для проверки / фильтрации , Я бы сказал, что вам нужно сохранить уже отфильтрованную / любую версию в базе данных, чтобы не разрушить сервер,
  • но вам также необходимо сохранить "исходную" версию (см. То, что я сказал ранее)
  • В этом случае я бы, вероятно, сохранил обе версии в базе данных, даже если она займет больше места ... Или, по крайней мере, используйте какой-нибудь хороший механизм кеширования, чтобы не воссоздавать чистую версию снова и снова.
• Если вы не хотите отображать какой-либо HTML, вы будете использовать htmlspecialchars или эквивалент, который вероятно, не так уж и много пожирает процессор ... Так что это, вероятно, не имеет большого значения
  • вам все еще нужно сохранить «исходную» версию
  • , но экранирование при выводе данных может быть нормальным.

Кстати, первое решение также хорошо, если пользователи используют что-то вроде bbcode / markdown / wiki при вводе данных, и вы визуализируете их в HTML ...
По крайней мере, если он отображается чаще, чем обновляется, особенно если вы не используете кеш для хранения чистой HTML-версии.

Очистите его для базы данных, прежде чем помещать в базу данных, если необходимо (т. е. если вы не используете уровень интерактивности базы данных, который сделает это за вас). Очистите его для отображения перед отображением.

Хранение вещей в ненужной в настоящее время цитируемой форме вызывает слишком много проблем.

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

Также стоит отметить, что строки с экранированием HTML могут быть намного длиннее, чем исходный ввод. Если я введу японское имя пользователя в регистрационную форму, исходная строка может состоять только из 4 символов Unicode, но экранирование HTML может преобразовать ее в длинную строку "& # 12345; & # 67890; & # 18504; & # 31337;" . Тогда мое 4-символьное имя пользователя слишком длинное для поля вашей базы данных и сохраняется как два японских символа плюс половина escape-кода, что также, вероятно, мешает мне войти в систему.

Помните, что браузеры, как правило, избегают некоторых вещей, таких как не- Английский текст в самих отправленных формах, и всегда будет тот умник, который везде использует японское имя пользователя. Так что вы можете захотеть отключить HTML перед сохранением.

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

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

С другой стороны, некоторые короткие семантические данные могут быть отфильтрованы немедленно. 1) Вам не нужны беспорядочные номера телефонов в базе данных, поэтому для таких вещей было бы неплохо продезинфицировать. 2) Вы не хотите, чтобы какой-то другой программист случайно выводил данные без экранирования, и вы работаете в многопрограммной среде. Однако,