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

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

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

Итак, основное правило: дезинфицировать перед использованием и специально для этого использования; не упреждающе.

(Пожалуйста, обратите внимание, что я не говорю об экранировании вывода для SQL, просто для отображения. Пожалуйста, по-прежнему выполняйте данные об исключении для строки SQL).

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

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

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

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

Вам необходимо по крайней мере два типа фильтрации / дезинфекции:

• SQL
• HTML

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

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

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

Так :

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

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

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

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

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

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

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

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