Хорошо ли использовать htmlspecialchars() перед вставкой в ​​MySQL?

Я немного смущен этим. Я читал о htmlspecialchars() и планирую использовать это для текстовых полей POST, чтобы предотвратить XSS-атаку. Я понимаю, что обычно htmlspecialchars() используются для создания вывода HTML, который отправляется в браузер. Но вот в чем я не уверен:

1) Безопасно ли использовать htmlspecialchars() для входных данных пользователя, прежде чем я вставлю их в MySQL? Я уже использую подготовленный оператор PDO с параметризованными значениями для предотвращения SQL-инъекций.

2) Или мне действительно не нужно беспокоиться об использовании htmlspecialchars() для вставленных значений (при условии, что они параметризованы) и использовать только htmlspecialchars(), когда я получаю результаты из MySQL и отображаю их пользователям?


mysql php sql pdo htmlspecialchars
person Neel    schedule 06.01.2014    source источник
comment
№2 это правильный ответ   -  person jszobody    schedule 07.01.2014
comment
Экранирование HTML (1) не имеет отношения к вашей базе данных. Обычно (2) предпочтительнее, так как преждевременное экранирование может позже помешать выходным каналам, отличным от веб-страницы. Новичкам все еще может быть рекомендовано раннее экранирование HTML; лучше слишком рано, чем потом забыть.   -  person mario    schedule 07.01.2014
comment
Предположим, вы хотите создать несколько текстовых журналов. Тогда вам придется отменить свой побег. Вместо этого убегайте в последний момент, чтобы знать, что это уместно.   -  person Waleed Khan    schedule 07.01.2014
comment
Применяйте бизнес-правила перед вставкой данных (они могут включать ограничение допустимых символов), но применяйте экранирование на месте использования (поскольку это всего лишь деталь реализации использования данных в заданном контексте).   -  person user2864740    schedule 07.01.2014
comment
Спасибо всем за ваш вклад. Теперь это имеет смысл для меня. @mario - Если я приму ваш совет новичка и сделаю раннее экранирование перед вставкой, и если я забуду, что сделал это, а затем снова экранирую при выводе, будет ли выходной текст иметь специальный символ, поскольку он экранируется дважды? Скажем, например, это текст: <a href='test'>Test</a>. Когда это экранируется во время вставки и снова экранируется во время вывода, будет ли он отображаться как &lt;a href=&#039;test&#039;&gt;Test&lt;/a&gt; вместо отображения его как <a href='test'>Test</a> в браузере?   -  person Neel    schedule 07.01.2014
comment
@blackops_programmer Если ваш сохраненный текст <a href='test'>Test</a> предназначен для преобразования его в реальную рабочую ссылку, вам придется декодировать его перед выводом. Если вы хотите, чтобы он отображался буквально как разметка HTML, одна кодировка будет отображаться в браузере как <a href='test'>Test</a>, а двойная кодировка будет отображаться как &lt;a href=&#039;test&#039;&gt;Test&lt;/a&gt;, и ни одна из них не даст вам рабочей ссылки.   -  person Michael Berkowski    schedule 07.01.2014
comment
Спасибо, Майкл Беркноуши, за то, что прояснил это для меня. Затем я буду использовать htmlspecialchars() в конце и убедиться, что у меня есть привычка кодировать его каждый раз, когда я показываю любые полученные результаты конечному пользователю. Эта практика, возможно, сделает ее хорошей привычкой. Я был смущен этим, так как в большинстве статей, которые я читал о XSS, говорилось, что мне нужно проверять и дезинфицировать все пользовательские входы. Поэтому я не был уверен, что делать с текстовой областью, когда у меня нет ничего, что можно было бы проверить, например, ожидая набора чисел или значений и т. д. перед вставкой. Так что все ваши ответы дали мне более четкое понимание. :)   -  person Neel    schedule 07.01.2014

Ответы (1)


arrow_upward
16
arrow_downward

Как указывали другие, № 2 - правильный ответ. Оставьте его «сырым», пока он вам не понадобится, а затем сбегите соответствующим образом.

Чтобы уточнить, почему (и я повторю/обобщу другие посты), давайте доведем сценарий 1 до его логической крайности.

Что происходит, когда кто-то вводит "' OR 1=1 <other SQL injection> --". Теперь, возможно, вы решите, что, поскольку вы используете SQL, вы должны кодировать для SQL (возможно, потому, что вы не использовали параметризованные операторы). Итак, теперь вам нужно смешать (или выбрать) кодировку SQL и HTML.

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

Следующий CSV - о нет! Что делать, если в тексте есть кавычки и запятые? Больше побегов!

Эй, как насчет приятного интерактивного интерфейса AJAX? Теперь вы, вероятно, хотите начать отправлять JSON обратно в браузер, поэтому теперь {, [ и т. д. все это необходимо принять во внимание. ПОМОЩЬ!!

Так что ясно, храните данные как есть (конечно, с учетом ограничений домена) и кодируйте в соответствии с вашим выходом в то время, когда вам это нужно. Ваши выходные данные не совпадают с вашими данными.

Я надеюсь, что этот ответ не слишком покровительственный. Кредит другим респондентам.

person LoztInSpace    schedule 07.01.2014
comment
Большое спасибо за то, что подытожили это для меня и объяснили, почему № 2 будет лучшей практикой. :) - person Neel; 07.01.2014