Strip_tags или mysql_real_escape_string или add_magic_quotes в php

Question

Я читаю о безопасности php в эти дни, и у меня головокружение, объясните, пожалуйста, ясно!

Я знаю, что я должен использовать strip_tags() или htmlentities() для атак XSS. но если мне нужны некоторые теги html, то же самое, что и сообщение в блоге, что мне делать !?

но где я должен использовать mysql_real_escape_string() и add_magic_quotes()? эти же?

Другой вопрос: должен ли я использовать mysql_real_escape_string() для каждого SQL-запроса? (INSERT, UPDATE, SELECT, DELETE, и т.п.)? может ли эта функция плохо повлиять на мои данные (например, в сообщении в блоге, где есть html-теги или ', "")?

Answer 1

Я знаю, что я должен использовать strip_tags() или htmlentities() для атак XSS. но если мне нужны некоторые теги html, то же самое, что и сообщение в блоге, что мне делать !?

Если вы не доверяете пользователям, проанализируйте HTML, run all the elements and attributes through a whitelister, а затем сериализуйте документ обратно в HTML.

но где я должен использовать mysql_real_escape_string() и add_magic_quotes()? эти же?

Это не то же самое, и вы должны, вообще говоря, избегать их. Use bound parameters instead.

Другой вопрос: должен ли я использовать mysql_real_escape_string() для каждого SQL-запроса?

Вы должны избегать ввода всех пользователей, прежде чем передавать их в dabtas.

Answer 2

Забудьте о magic_quotes. Это был ленивый способ автоматически избежать определенных контрольных символов, найденных в пользовательском вводе. Continue learning около newer and more efficient methods для фильтрации/дезинфекции ввода данных, и вы обнаружите, почему magic_quotes has been deprecated.

может эта функция имеет плохое влияние на мои данные (например, в блоге пост, который имеет HTML-теги или»,„“)?

У вас не должно быть никаких проблем, потому что данные не хранятся в базе данных с помощью дополнительной косой черты. Если это так, есть хорошая вероятность, что magic_quotes включен и должен быть отключен.

Должен ли я использовать mysql_real_escape_string() для каждого SQL-запроса?

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

Answer 3

Если вам нужно разрешить HTML-сообщение в блоге, вы должны присваивать белые метки и атрибуты, но вы не должны пытаться это самостоятельно. Вместо этого используйте HTMLPurifier.Используйте, если перед хранением в базе данных, поскольку он тяжелый и медленный, но очень безопасный.

http://htmlpurifier.org/

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

Answer 4

Идея общей функции санитарии является нарушенной концепцией.

Существует один правильный метод санитарии для всех целей. Запуск общего метода санитарии на строке часто нарушает его - экранирование фрагмента кода HTML для SQL-запроса приведет к его разрыву для использования на веб-странице и наоборот. Санитарии следует применять непосредственно перед использованием данных:

mysql_real_escape_string() for functional mysql_* calls (or parametrized queries) 

htmlspecialchars() for safe HTML output 

preg_quote() for use in a regular expression 

escapeshellarg()/escapeshellcmd() for use in an external command 

etc. etc. 

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

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