Htmlentities vs addlashes vs mysqli_real_escape_string

Question

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

Однако есть одна вещь, которая смущает меня. Кажется, я помню, что addslashes лучше, чем htmlentities, когда передает введенные пользователем данные обратно пользователям, чтобы защитить их данные, но кажется, что addslashes - та, у которой есть уязвимость. Это правда или я не правильно помню?

Answer 1

Это разные инструменты для разных целей.

mysqli_real_escape_string обеспечивает безопасность данных для вставки в MySQL (но параметризованные запросы лучше).

Htmlentities делает данные безопасными для вывода в HTML-документ

addlashes делает данные безопасными для нескольких других ситуаций, но недостаточно для MySQL

Answer 2

Существуют разные контексты для ваших данных. Контекст вставки данных в базу данных должен быть экранирован иначе, чем контекст рендеринга html / xml или даже сообщения электронной почты.

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

Экранирующие данные, поступающие в браузер, необходимо экранировать несколькими различными способами в зависимости от цели. Иногда достаточно htmlspecialchars, иногда вам нужно использовать htmlentities. Иногда вам нужны числовые объекты. Это тема, над которой вам следует провести исследование, чтобы узнать все нюансы.

Общее правило, по которому я живу, это проверять (не фильтровать, отклонять, если неверно) ввод и выход (в зависимости от контекста).

Answer 3

Вы не можете иметь одну функцию «escape» и ожидать, что она будет работать постоянно. Существуют различные атаки, которые требуют определенных процедур санитарии. Единственный способ понять эту концепцию - написать некоторый уязвимый код и затем использовать его. Написание кода эксплойта жизненно важно для понимания любой системы безопасности.

Например, этот запрос уязвим для внедрения Sql:

$host=htmlspecialchars($_GET[host],ENT_QUOTES);
$name=htmlspecialchars($_GET[name],ENT_QUOTES);
mysql_query("select * from user where Host='$host' and Name='$name' ");

Exploit: http://localhost/sqli_test.php?host=\&name=%20sleep(20)--%201

Лучшей escape-функцией для mysql является mysqli_real_escape_string (), но это может завершиться ошибкой:

mysql_query("select * from user where id=".mysqli_real_escape_string($_GET[id]));

эксплуатируют: http://localhost/sqli_test.php?id=1%20or%20sleep(20)

На самом деле лучший способ позаботиться о внедрении sql - это не вызов функции escape, а использование параметризованных запросов ADODB для внедрения sql. Используйте htmlspecialcahrs ($ var, ENT_QUTOES) для XSS. Прочитайте OWASP top 10 , потому что с безопасностью веб-приложений гораздо больше, чем можно ошибиться.

Answer 4

Другое интересное решение для PHP 5.2 и выше - использовать расширение фильтра: http://www.php.net/manual/en/book.filter.php

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

Я лично начал использовать их в своих проектах для проверки форм и вывода введенных пользователем данных, и я очень рад, что сделал это. Хотя, когда я вставляю значения в базу данных MySQL, я использую подготовленные запросы для дополнительной безопасности. Вместе эти решения могут помочь избежать большинства SQL-инъекций и атак типа XSS.

Answer 5

Примечание. Следует избегать использования htmlentities () в документе в кодировке UTF-8. Смотри:

• Взаимодействие с системами, использующими другие кодировки
• Общие проблемные области с UTF-8

Обратите внимание (цитируется phpwact.org ):

С современными веб-браузерами и широким спектром поддержка UTF-8, вам не нужно htmlentities, потому что все эти символы могут быть представлены непосредственно в UTF-8. Что еще более важно, в в общем, только браузеры поддерживают HTML специальные символы - обычный текст редактор, например, не знает HTML-сущности. В зависимости от того, что вы делаете, используя htmlentities может уменьшить способность других систем «Потреблять» ваш контент.

Также (не подтверждено, но звучит разумно - от одного комментария здесь), персонажи (например, »или -) не работают, когда документ подается как application / xml + xhtml (если вы определить их). Вы все еще можете уйти хотя с числовой формой.

Answer 6

да, используйте mysqli_real_escape_string или библиотеку, такую ​​как PDO, для всего пользовательского ввода. При возврате я использую htmlentities с ENT_QUOTES в качестве второго параметра, поскольку он экранирует все применимые символы к их HTML-сущностям, включая кавычки.

Answer 7

Вы также можете использовать PDO libs , который выполняет большую часть экранирования для вас, в случае, если вы можете использовать PHP5 на серверах.

При возвращении я лично предпочел бы htmlspecialchars, но можно меня поправить