В статье http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html говорится следующее:
Существует множество преимуществ использования подготовленных заявлений в ваших приложениях как по соображениям безопасности, так и по производительности.
Подготовленные утверждения могут помочь повысить безопасность, отделив логику SQL от поставляемых данных. Такое разделение логики и данных может помочь предотвратить очень распространенный тип уязвимости, называемый атакой SQL-инъекции.
Обычно, когда вы имеете дело с специальным запросом, вы должны быть очень осторожны при обработке данных, полученных от пользователя. Это подразумевает использование функций, которые устраняют все необходимые символы ошибки, такие как одинарная кавычка, двойная кавычка и символы обратной косой черты.
Это необязательно при работе с подготовленными заявлениями . Разделение данных позволяет MySQL автоматически принимать во внимание эти символы, и их не нужно избегать с помощью какой-либо специальной функции.
Означает ли это, что мне не нужны htmlentities() или htmlspecialchars() ? Но я предполагаю, что мне нужно добавить strip_tags() к пользовательским входным данным? Я прав?
htmlentities и htmlspecialchars используются для генерации вывода HTML, который отправляется в браузер.
Подготовленные операторы используются для генерации / отправки запросов в механизм базы данных .
Оба позволяют избежать данных; но они не убегают при одинаковом использовании.
Таким образом, никакие подготовленные операторы (для SQL-запросов) не мешают вам правильно использовать htmlspecialchars / htmlentities (для генерации HTML)
О strip_tags : он удалит теги из строки, где htmlspecialchars преобразует их в объекты HTML.
Эти две функции не делают то же самое; вы должны выбрать, какой из них использовать в зависимости от ваших потребностей / того, что вы хотите получить.
Например, с помощью этого фрагмента кода:
$str = 'this is a <strong>test</strong>'; var_dump(strip_tags($str)); var_dump(htmlspecialchars($str));
Вы получите такой вывод:
string 'this is a test' (length=14) string 'this is a <strong>test</strong>' (length=43)
В первом случае нет метки; во втором, правильно экранированном.
И с выходом HTML:
$str = 'this is a <strong>test</strong>'; echo strip_tags($str); echo '<br />'; echo htmlspecialchars($str);
Ты получишь:
this is a test this is a <strong>test</strong>
Какой из них вы хотите? Это важный вопрос 😉
Для htmlspecialchars() ничего не меняется, потому что это для HTML, а не для SQL. Вам все равно нужно избегать HTML правильно, и лучше всего это делать, когда вы на самом деле генерируете HTML, а не привязываете его к базе данных.
Если вы используете подготовленные инструкции, вам больше не понадобится mysql_[real_]escape_string() (при условии, что вы придерживаетесь заполнителей подготовленных операторов и избегаете соблазна обходить его с помощью манипуляции с строкой).
Если вы хотите избавиться от htmlspecialchars() , то есть механизмы HTML-шаблонов, которые htmlspecialchars() работают с подготовленными операторами SQL и освобождают вас от выполнения всего вручную, например PHPTAL .
Вам не нужны htmlentities () или htmlspecialchars () при вводе материала в базу данных, ничего плохого не произойдет, вы не будете уязвимы для SQL-инъекций, если используете готовые заявления. Хорошо, что теперь вы сохраните первоначальный пользовательский ввод в своей базе данных.
Вам нужно скрывать данные на выходе и отправлять их клиенту, – когда вы вытаскиваете материал из базы данных, вы будете уязвимы для межсайтовых скриптовых атак и других плохих вещей. Вам нужно будет избежать их для нужного формата вывода, например html, поэтому вам понадобятся htmlentities и т. Д.
По этой причине вы можете просто уйти от вещей, поскольку вы помещаете их в базу данных, а не когда вы ее выводите, – однако вы потеряете исходное форматирование пользователя, и вы избежите данных для использования html, которые могут не окупиться, если вы используете данные в разных форматах вывода.
подготовиться к SQL-инъекции
htmlspecialchar для XSS (перенаправление на другую ссылку)
<?php $str = "this is <script> document.location.href='https://www.google.com';</script>"; echo $str;
вывод : это … и перенаправление на google.com
Использование htmlspecialchars :
$str = "this is <script> document.location.href='https://www.google.com';</script>"; echo htmlspecialchars($str); <i>output1</i>: this is <script> document.location.href='https://www.google.com';</script> (in output browser)<br /> <i>output2</i>: this is <script> document.location.href='https://www.google.com';</script> (in view source)<br />
Если пользователь вводит комментарий «скрипт» в базу данных, тогда браузер отображает все комментарии из базы данных, автоматически «сценарий» будет выполнен и перенаправлен на google.com
Так,
1. используйте htmlspecial для деактивации неправильного тега скрипта
2. использовать подготовку к безопасной базе данных
htmlspecialchars
htmlspecialchars_decode
проверка подлинности php
Я все равно был бы склонен кодировать HTML. Если вы создаете какую-либо форму CMS или веб-приложения, ее легче хранить в виде закодированного HTML, а затем перекодировать по мере необходимости.
Например, при вводе информации в TextArea, измененной TinyMCE, они рекомендуют, чтобы HTML был закодирован – поскольку спецификация HTML не позволяет HTML внутри текстовой области.
Я бы также strip_tags() из любого места, где вам не нужен HTML-код.