Zend \ escap data перед вставкой в базу данных
Я добавляю некоторую защиту xss на сайт, над которым работаю, платформа zendFrameWork 2, и поэтому я использую Zend \ escaper. Из документации Zend я знал, что:
Zend \ Escaper предназначен для использования только для экранирования данных, которые должны быть
вывод, и как таковой не должен использоваться неправильно для фильтрации входных данных.
Для таких задач используется компонент Zend \ Filter HTMLPurifier.
но каковы риски, если я избежал данных до того, как вставить их в базу данных, я так неправ? пожалуйста, объясните мне, как я как-то новичок в этой теме.
Спасибо
Решение
При кодировании данных перед их сохранением вам придется декодировать их, прежде чем вы сможете что-то сделать с ними, прежде чем выводить их. Вот почему я не буду этого делать.
Допустим, у вас есть международное приложение, и вы хотите сохранить экранированное значение поля формы, которое может содержать любые символы NON-ASCII, которые могут быть экранированы в HTML-сущности. Так что, если вам нужно определить количество содержимого этого поля? Как считать персонажей? Вы всегда должны покинуть содержимое, прежде чем считать его. и тогда тебе придется снова сбежать. Много работы сделано, но ничего не получено.
То же самое относится и к поисковым операциям в вашей базе данных. Вам нужно будет избегать поисковой фразы таким же образом, как ваш ввод для базы данных, чтобы понять, что вы ищете.
Я бы использовал один набор символов во всем приложении и базе данных (я предпочитаю UTF-8, остерегайтесь MySQL-Connection ….) и только экранировал содержимое на выходе. Таким образом, я могу делать с данными все, что захочу, и в безопасности на выходе. И экранирование выполняется в моем слое представления автоматически, поэтому мне даже не нужно думать об этом каждый раз, когда я обрабатываю данные, так как они работают автоматически. Таким образом, вы не можете забыть это.
Это не мешает мне фильтровать и очищать входные данные. И это не мешает мне избежать содержимого базы данных, используя соответствующие механизмы удаления базы данных, такие как mysqli_real_escape_string или аналогичные или с использованием подготовленных заявлений!
Но это только мое мнение, другие могут думать иначе!
Другие решения
«Вывод» здесь относится к веб-странице. Поле формы (HTML-тег) — это ВХОД (с веб-страницы), любой текст — это ВЫХОД (на веб-страницу). Необходимо убедиться, что любой вывод (на веб-страницу) не содержит опасных символов, которые можно использовать для подделки векторов атаки XSS.
Это сказало, если у вас есть DANGEROUS_INPUT_X, данный пользователем, а затем
$NOT_DANGEROUS_ANYMORE = ZED.HtmlPurifier(DANGEROUS_INPUT_X)
DBSave($NOT_DANGEROUS_ANYMORE)
и где-то еще
$OUTPUT = DBLoad($NOT_DANGEROUS_ANYMORE)
echo $OUTPUT
у вас должно быть все в порядке, если вы не применяете никакого дополнительного кодирования / декодирования к этому выводу. Он будет отображаться так, как он был сохранен, это было безопасно.
Я бы посоветовал взглянуть на выходную кодировку не только на валидацию: HtmlPurifier очищает HTML, в то время как вы можете принимать любые плохие символы, если вы уверены, что ваш вывод закодирован на странице.
Вот https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet некоторые общие правила, вот пример PHP
echo htmlspecialchars($DANGEROUS_INPUT_X_NOW_OUTPUT, ENT_QUOTES, "UTF-8");
Не забудьте установить набор символов и соответствовать ему на всех ваших страницах / скриптах / двоичных файлах, а также в базе данных.