Нужны ли мне htmlentities () или htmlspecialchars () в подготовленных выражениях?

Question

В статье http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html, говорится следующее:

Использование готовых операторов в ваших приложениях дает множество преимуществ как для безопасности , так и для повышения производительности.

Подготовленные операторы могут помочь повысить безопасность, отделив логику SQL от предоставляемых данных. Такое разделение логики и данных может помочь предотвратить очень распространенный тип уязвимости, называемый атакой SQL-инъекции.

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

Это не нужно при работе с подготовленными заявлениями . Разделение данных позволяет MySQL автоматически учитывать эти символы, и их не нужно экранировать с помощью какой-либо специальной функции.

Значит ли это, что мне не нужны htmlentities() или htmlspecialchars()? Но я предполагаю, что мне нужно добавить strip_tags() к пользовательским вводимым данным? Я прав?

Answer 1

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>

Какой из них вы хотите? Что - важный вопрос ; -)

Answer 2

Ничего не меняется для htmlspecialchars(), потому что это для HTML, а не для SQL. Вам по-прежнему необходимо корректно экранировать HTML, и лучше всего это делать, когда вы действительно генерируете HTML, а не привязывать его к базе данных каким-либо образом.

Если вы используете подготовленные операторы, то вам больше не нужно mysql_[real_]escape_string() (при условии, что вы придерживаетесь заполненных операторов подготовленных операторов и сопротивляетесь искушению обойти его с помощью манипулирования строками).

Если вы хотите избавиться от htmlspecialchars(), то существуют механизмы шаблонов HTML, которые работают аналогично подготовленным операторам в SQL и освобождают вас от необходимости экранировать все вручную, например PHPTAL .

Answer 3

Вам не нужны htmlentities () или htmlspecialchars () при вставке содержимого в базу данных, ничего плохого не произойдет, вы не будете уязвимы для внедрения SQL, если используете подготовленные операторы. Хорошо, что теперь вы будете хранить первичные пользовательские данные в вашей базе данных.

Вам НЕОБХОДИМО экранировать данные на выходе и отправлять их обратно клиенту, - когда вы извлекаете данные из базы данных, в противном случае вы будете уязвимы для атак с использованием межсайтовых сценариев и других плохих вещей. Вам нужно будет экранировать их для нужного вам формата вывода, такого как html, так что вам все равно понадобятся htmlentities и т. Д.

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

Answer 4

подготовка к 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 &lt;script&gt; document.location.href='https://www.google.com';&lt;/script&gt; (in view source)<br />

Если пользователь вводит комментарий «скрипт» в базу данных, то отображается браузер все комментарии из базы данных, автоматически "скрипт" будет выполнен и перенаправить на google.com

Итак,
1. используйте htmlspecial для деактивного неверного тега сценария
2. использовать подготовить для безопасной базы данных

htmlspecialchars
htmlspecialchars_decode
проверка php

Answer 5

Я все равно был бы склонен кодировать HTML. Если вы создаете какую-либо форму CMS или веб-приложения, проще сохранить ее как закодированный HTML, а затем перекодировать, как требуется.

Например, при переносе информации в TextArea, измененную TinyMCE, они рекомендуют кодировать HTML - поскольку спецификация HTML не допускает HTML внутри текстовой области.

Я бы также strip_tags() везде, где вы не хотите HTML-код.