Действительно ли мне нужно использовать mysql_real_escape_string при сохранении данных в БД?

Question

Я использую mysql_real_escape_string для сохранения содержимого в моей базе данных MySQL. Содержимое, которое я сохраняю, - это HTML через форму. Я удаляю и повторно загружаю PHP-файл, который пишет в БД, когда мне это нужно.

Для корректного отображения моего ввода HTML я использую stripslashes()

В другом случае, когда я вставляю его без mysql_real_escape_string, я не использую stripslashes() на выходе.

Каково ваше мнение? stripslashes плохо влияет на производительность?

Answer 1

Do not use stripslashes().Это абсолютно бесполезно с точки зрения безопасности, и нет никакой дополнительной выгоды.Эта практика пришла из мрачных веков «магических кавычек», которые ушли в прошлое в следующей версии PHP.

Вместо этого, только фильтр ввода:

• string: mysql_real_escape_string($data)
• целые числа: (int)$data
• с плавающей запятой: (float)$data
• логическое значение: isset($data) && $data

Выводдругое дело.Если вы храните HTML, вам нужно отфильтровать HTML против javascript.

Редактировать: Если вам нужно сделать stripslashes(), чтобы вывод выглядел правильно, то, скорее всего, у вас есть магические кавычкивключенный.Некоторые CMS даже совершили серьезную ошибку, написав собственные магические цитаты (например, Wordpress).Всегда фильтруйте, как я советовал выше, отключайте магические кавычки, и все будет в порядке.

Answer 2

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

См. Билл Карвин Мифы и ошибки об инъекциях Sql talk и для получения дополнительной информации по этому вопросу.

См. Очиститель HTML и htmlspecialchars , чтобы узнать о нескольких подходах к фильтрации вашего HTML для вывода.

Answer 3

Не думайте о производительности, думайте о безопасности . Используйте mysql_real_escape_string каждый раз, когда вы вставляете данные в БД

Answer 4

Ознакомьтесь с библиотекой абстракции базы данных, которая делает все это и многое другое автоматически, например ADOdb на http://adodb.sourceforge.net/

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

Answer 5

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

В документации PHP даже говорится: «Если эта функция не используется для экранирования данных, запрос уязвим для Атаки с использованием SQL .»