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

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

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

Примечание. Эта функция УСТАРЕЛА, начиная с PHP 5.3.0, и УДАЛЕНА, начиная с PHP 5.4.0.

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

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

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

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

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

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

Проблема в том, что 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 в форму ввода. Как вы думаете, будет ли хорошей идеей иметь такие имена, как Боб «Баффало» Билл? я так не думаю