Я читал об обеспечении PHP-приложений, и мне кажется, что mysqli_real_escape_string – это правильная функция, используемая при вставке данных в таблицы MySQL, потому что addslashes может вызвать некоторые странные вещи для умного злоумышленника. Правильно?
Однако есть одна вещь, которая меня путает. Кажется, я помню, как было htmlentities лучше, чем htmlentities когда повторяет введенные пользователем данные обратно пользователям, чтобы защитить их данные, но похоже, что addslashes – это уязвимость. Это правда, или я неправильно помню?
Существуют разные контексты для ваших данных. Контекст вставки данных в базу данных должен быть экранирован иначе, чем контекст рендеринга html / xml или даже сообщения электронной почты.
Избегание данных, поступающих в db, должно устаревать во всех новых кодах в пользу подготовленных операторов. Любой, кто говорит вам об этом, делает вас большой плохой услугой.
Экранирование данных, поступающих в браузер, должно выполняться несколькими способами в зависимости от цели. Иногда достаточно htmlspecialchars, иногда вам нужно использовать htmlentities. Иногда вам нужны числовые объекты. Это тема, которую вы должны провести некоторое исследование, чтобы узнать все нюансы.
Общее правило, в котором я живу, – это проверка (не фильтровать, отклонять, если неверно) вывод ввода и выхода (на основе контекста).
Это разные инструменты для разных целей.
mysqli_real_escape_string делает данные безопасными для вставки в MySQL (но параметризованные запросы лучше).
Htmlentities делает данные безопасными для вывода в HTML-документ
addslashes делает данные безопасными для нескольких других ситуаций, но для MySQL недостаточно
Вы также можете использовать библиотеки PDO, которые выполняют большую часть экранирования для вас, если вы можете использовать PHP5 на серверах.
Отказываясь назад, я лично предпочитаю htmlspecialchars, но можно было бы исправить меня
да, используйте mysqli_real_escape_string или библиотеку, такую как PDO, во всех пользовательских вводах. При повторном возврате я использую htmlentities с ENT_QUOTES в качестве второго параметра, так как он пропускает все применимые символы к своим объектам html, включая кавычки.
Примечание. Следует избегать использования htmlentities () в кодированном документе UTF-8. Видеть:
Обратите внимание на (цитируется на phpwact.org ):
Благодаря современным веб-браузерам и широкоформатной поддержке UTF-8 вам не нужны htmlentities, потому что все эти символы могут быть представлены непосредственно в UTF-8. Что еще более важно, в общем, только браузеры поддерживают специальные символы HTML – обычный текстовый редактор, например, не знает об объектах HTML. В зависимости от того, что вы делаете, использование htmlentities может уменьшить способность других систем «потреблять» ваш контент.
Также (не подтверждено, но звучит разумно – из комментария анона здесь), объекты символов (такие как »или -) не работают, когда документ подается как application / xml + xhtml (если вы не определяете их). Тем не менее, вы все равно можете уйти с числовой формой.
Еще одно интересное решение для PHP 5.2 и выше – использовать расширение фильтра: http://www.php.net/manual/en/book.filter.php
Он позволяет проверять и деактивировать пользовательские входы. Существует множество встроенных фильтров, и их можно комбинировать с флагами, чтобы настроить их поведение. Кроме того, hese фильтры также могут использоваться для проверки / дезинфекции ints, floats, email, определенных регулярных выражений.
Я лично начал использовать их в своих проектах для проверки форм и вывода введенных пользователем данных, и я очень рад, что это сделал. Хотя, когда я вставляю значения в базу данных MySQL, я использую подготовленные запросы для дополнительной безопасности. Эти решения вместе помогают избежать большинства инъекций SQL и атак типа XSS.
У вас не может быть одна функция «побега» и ожидать, что она будет работать все время. Существуют различные атаки, требующие конкретных санитарных процедур. Единственный способ понять эту концепцию – написать уязвимый код, а затем использовать его. Написание кода эксплойта имеет жизненно важное значение для понимания любой системы безопасности.
Например, этот запрос уязвим для инъекции 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]));
exploit: http: //localhost/sqli_test.php? id = 1% 20or% 20sleep (20)
На самом деле лучший способ позаботиться о SQL-инъекции – это не вызов функции escape, ее использование параметризованных запросов ADODB для SQL-инъекции. Для XSS используйте htmlspecialcahrs ($ var, ENT_QUTOES). Прочитайте 10 лучших OWASP, потому что есть намного больше, чем может пойти не так с безопасностью веб-приложений.