PHP & mySQL: когда именно использовать htmlentities?

ПЛАТФОРМА: PHP и mySQL

В моих экспериментальных целях я пробовал несколько инъекций XSS самостоятельно на своем собственном веб-сайте. Подумайте об этой ситуации, когда у меня есть вход в форму textarea. Поскольку это текстовое поле, я могу вводить текст и всевозможные (английские) символы. Вот мои наблюдения:

А). Если я применяю только strip_tags и mysql_real_escape_string и не использую htmlentities на моем входе непосредственно перед вставкой данных в базу данных, запрос ломается, и я попал с ошибкой, которая показывает мою структуру таблицы, из-за аномальное завершение.

В). Если я применяю strip_tags, mysql_real_escape_string и htmlentities на моем входе непосредственно перед вставкой данных в базу данных, запрос НЕ разбивается на, и я могу успешно вставлять данные из текстового поля в мою базу данных.

Итак, я понимаю, что htmentities должны использоваться любой ценой, но не уверены, когда именно он должен использоваться. С учетом вышеизложенного я хотел бы знать:

Когда нужно использовать только htmlentities? Должен ли он использоваться непосредственно перед вставкой данных в БД или каким-то образом получить данные в БД, а затем применить htmlentities, когда я пытаюсь показать данные из БД?
Если я следую методу, описанному в пункте B) выше (который, по моему мнению, является наиболее очевидным и эффективным решением в моем случае), мне все еще нужно применять htmlentities, когда я пытаюсь показать данные из DB? Если да, то почему? Если нет, почему бы и нет? Я спрашиваю об этом, потому что это действительно сбивает меня с толку после того, как я прошел через пост: http://shiflett.org/blog/2005/dec/google-xss-example
Затем появляется еще одна функция PHP: html_entity_decode. Могу ли я использовать это для отображения моих данных из БД (после выполнения моей процедуры, как указано в пункте B), поскольку htmlentities применялись на моем входе? Какой из них я должен использовать: html_entity_decode и htmlentities и когда?

ПРЕДВАРИТЕЛЬНАЯ СТРАНИЦА:

Я подумал, что это может помочь добавить некоторые более конкретные детали конкретной ситуации здесь. Учтите, что есть страница "Предварительный просмотр". Теперь, когда я отправляю входные данные из текстового поля, страница предварительного просмотра получает вход и показывает его html, и в то же время скрытый ввод собирает этот вход. Когда нажата кнопка отправки на кнопке предварительного просмотра, данные со скрытого ввода отправляются на новую страницу и эта страница вставляет данные, содержащиеся в скрытом вводе, в БД. Если я не применяю htmlentities, когда форма изначально отправлена (но применимо только strip_tags и mysql_real_escape_string), и там есть вредоносный ввод в текстовом поле, скрытый ввод прерывается, а последние несколько символов скрытого ввода видимо воспринимаются как " /> on страницу, что нежелательно. Поэтому, помня об этом, мне нужно что-то сделать, чтобы сохранить целостность скрытого ввода на странице предварительного просмотра и все же собрать данные на скрытом входе, чтобы он не сломал его. Как мне это сделать? Извините за задержку в публикации этой информации.

Спасибо заранее.

Ответ 1

Здесь общее правило.

Переместите переменные в последний возможный момент.

Вы хотите, чтобы ваши переменные были чистыми представлениями данных. То есть, если вы пытаетесь сохранить фамилию кого-то по имени "O'Brien", то вы определенно не хотите этого:

O&#39;Brien
O\'Brien

.. потому что, ну, это не его имя: там нет амперсандов или косых черт. Когда вы берете эту переменную и выводите ее в определенном контексте (например: вставляете в SQL-запрос или печатаете на HTML-страницу), то есть когда вы его изменяете.

$name = "O'Brien";

$sql = "SELECT * FROM people "
     . "WHERE lastname = '" . mysql_real_escape_string($name) . "'";

$html = "<div>Last Name: " . htmlentities($name, ENT_QUOTES) . "</div>";

Вы никогда не хотите, чтобы в вашей базе данных хранились строки htmlentities -encoded. Что происходит, когда вы хотите создать CSV или PDF или что-либо, что не является HTML?

Храните данные в чистоте и выходите только для определенного контекста момента.

Ответ 2

В сущности, вы должны использовать mysql_real_escape_string до вставки базы данных (чтобы предотвратить SQL-инъекцию), а затем htmlentities и т.д. в точке вывода.

Вы также захотите применить проверку работоспособности ко всем пользовательским вводам, чтобы гарантировать (например), что числовые значения действительно являются числовыми и т.д. Функции, такие как is_int, is_float и т.д. полезны на данном этапе. (См. функции обработки переменных в руководстве PHP для получения дополнительной информации об этих функциях и других подобных.)

Ответ 3

Только до того, как вы напечатаете значение (независимо от БД или из $_GET/$_ POST) в HTML. htmlentities не имеют ничего общего с базой данных.
B - избыток. Перед вставкой в базу данных необходимо указать mysql_real_escape_string и htmlentities перед печатью в HTML. Вам не нужно снимать теги, после того, как теги htmlentities будут отображаться на экране как < b r/" > e.t.c

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

3. See above

Ответ 4

Я прошел через это раньше и узнал две важные вещи:

Если вы получаете значения из $_POST/$_ GET/$_ REQUEST и планируете добавить в БД, используйте функцию mysql_real_escape_string для дезинфекции значений. Не кодируйте их с помощью htmlentities.

Почему бы просто не закодировать их с помощью htmlentities и не поместить их в базу данных? Ну, вот что: цель состоит в том, чтобы сделать данные максимально содержательными и чистыми, и когда вы кодируете данные с помощью htmlentities, таких как Jeff Dog, становится Jeff & s Dog..., что приведет к тому, что контекст данных потеряет свое значение, И если вы решите внедрить сервисы REST и вы получите эту строку из БД и поместите ее в JSON - она будет выглядеть как Jeff " s Dog, которая не очень хороша. Вам придется добавить еще одну функцию для декодирования.

Предположим, вы хотите найти "Jeff Dog", используя SQL "select * from table where field = 'Jeff\Dog", вы не найдете его, поскольку "Jeff Dog" не соответствует "Jeff " s Собака." Плохо, а?

Чтобы выводить буквенно-цифровые строки (от типа CHAR) на веб-страницу, используйте htmlentities - ВСЕГДА!