Почему вращение magic_quotes_gpc считается плохой практикой?

Я не думаю, что могу объяснить это лучше, чем создатели самого PHP (с последующими комментариями на этой странице): Почему бы не использовать Magic Quotes

• Переносимость. Предполагая, что он включен или выключен, влияет на переносимость. Используйте get_magic_quotes_gpc() чтобы проверить это, и код соответственно.
• Производительность. Поскольку в каждую базу данных вставлена ​​не каждая часть экранированных данных, существует потеря производительности для экранирования всех этих данных. Простое использование функций экранирования (например, addslashes() ) во время выполнения является более эффективным. Хотя php.ini-development позволяет эти директивы по умолчанию, php.ini-production отключает его. Эта рекомендация в основном обусловлена ​​соображениями эффективности.
• Неудобство: потому что не все данные требуют экранирования, часто бывает неприятно видеть экранированные данные там, где их не должно быть. Например, электронная почта из формы и видя кучу «в письме». Чтобы исправить это, может потребоваться чрезмерное использование stripslashes() .

Примечание. Эта функция была DEPRECATED с PHP 5.3.0 и удалена с PHP 5.4.0.

Согласно статье What's Magic Quotes GPC (magic_quotes_gpc) в PHP и php.ini? , есть много недостатков:

• Случаи, когда формы отправки отправляются обратно в браузер, должны иметь косые черты, удаленные вручную вызовом stripslashes ().
• Если волшебные кавычки когда-либо отключены для этого сервера, или код перемещается на сервер, на котором магические кавычки не включены, ваши сценарии будут терпеть неудачу. Или, что еще хуже, не подведи сразу и проявите странное поведение.
• Любые строковые операции над представленными переменными, даже простые инструкции «if» должны учитывать возможность деформирования слэшей в контенте.
• Волшебные цитаты порождают небрежность разработчиков. Исключение переменных, вставленных в SQL-запрос (на мой взгляд), – это то, что разработчик должен знать и думать. Не просто предположить, что все денди.

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

Тот факт, что функция удаляется в будущих версиях PHP, несмотря на это.

Потому что отказ от него заставляет вас писать более безопасный код.

Если г-н О'Мэлли отправится зарегистрироваться на вашем сайте, то magic_quotes_gpc превратит его фамилию в O \ Malley, и когда вы вставьте его в базу данных, все будет хорошо.

Проблема в том, что magic_quotes исходит от addlashes – что не обязательно работает как экранирование для вашей системы баз данных. O'Malley может работать, но также возможно обойти это экранирование и выполнить SQL-инъекцию.

Если magic_quotes не включен, вы получите строку O'Malley, и она нарушит инструкцию SQL, например

 INSERT INTO users (...) VALUES (...,'O'Malley',...) 

Обратите внимание, что строка действительно завершается после O.

Кроме того, это красивее: если бы вы, например, отправили электронное письмо с его именем, вам пришлось бы делать стрип-ласты – без уважительной причины. Если вы этого не сделаете, вы получите электронное письмо от мистера О'Малли.

(Конечно, для ДЕЙСТВИТЕЛЬНОГО безопасного кода обработки базы данных вы хотите использовать параметризованные запросы, так как это лучший способ предотвратить SQL-инъекцию. И если вы параметризуете, вы не хотите, чтобы слэш в любом случае, и это пустая трата чтобы PHP добавлял их.)

«Волшебные кавычки» были попыткой PHP, которая мешала разработчикам стрелять в ногу с помощью SQL-инъекции, когда они не знали ничего лучшего. Он устарел в PHP 5.3 и будет удален в PHP 6.

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

http://us3.php.net/manual/en/security.magicquotes.php

Очень простой вопрос.
Представьте, что вы хотите отправить данные пользователя по электронной почте. Или вставьте имя пользователя из файла cookie в ввод формы. Считаете ли вы, что было бы неплохо иметь такие имена, как Боб? «Буффало»? Я так не думаю