Why is turning magic_quotes_gpc on considered a ba

问题:

Why is turning magic_quotes_gpc on in PHP is considered a bad practice?

回答1:

I don't think I can explain it any better than the makers of PHP itself (with followup comments on that page): Why not to use Magic Quotes

• Portability: Assuming it to be on, or off, affects portability. Use get_magic_quotes_gpc() to check for this, and code accordingly.
• Performance: Because not every piece of escaped data is inserted into a database, there is a performance loss for escaping all this data. Simply calling on the escaping functions (like addslashes()) at runtime is more efficient. Although php.ini-development enables these directives by default, php.ini-production disables it. This recommendation is mainly due to performance reasons.
• Inconvenience: Because not all data needs escaping, it's often annoying to see escaped data where it shouldn't be. For example, emailing from a form, and seeing a bunch of \' within the email. To fix, this may require excessive use of stripslashes().

Note - This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.

回答2:

According to the article What is Magic Quotes GPC (magic_quotes_gpc) in PHP and the php.ini?, there are many disadvantages:

• Cases where form submissions are sent back to the browser must have the slashes removed manually with a call to stripslashes().
• If magic quotes are ever turned off for this server, or the code is moved to a server where magic quotes isn't enabled your scripts will fail. Or worse, not fail immediately and only exhibit strange behaviour.
• Any string operations on submitted variables, even simple 'if' statements must take into account the possiblity of slashes warping in the content.
• Magic quotes breeds developer sloppyness. Escaping variables inserted into an SQL query (in my opinion) is something that a developer should know and think about. Not just assume everything is dandy.

回答3:

Because somebody can move your script to a server where that option is not enabled, instantly opening hundreds of security holes in your application. Also, too many think that enabling magic quotes makes your application secure. It does not. You still need to examine and verify every piece of input that comes into your application. Even if you don't have quote problems, you can still have cross site scripting issues, etc.

The fact that the feature is being removed in future versions of PHP notwithstanding.

回答4:

Because leaving it off forces you to write more secure code.

If Mr. O'Malley goes to register on your site, then magic_quotes_gpc will turn his last name into O\'Malley, and when you insert it into the database, everything will go fine.

The problem is, the magic_quotes come from addslashes - which doesn't necessarily work as escaping for your database system. O'Malley might work, but it may also be possible to circumvent this escaping and do SQL injection.

If magic_quotes aren't on, then you'll get the string O'Malley, and it will break an SQL statement like

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

Notice the string is really terminated after the O.

Additionally, it's nicer: if you were to, for example, send an e-mail with his name, you'd have to stripslashes - for no good reason. If you don't you'll get an e-mail from Mr. O\'Malley.

(Of course, for REALLY secure database handling code, you'd want to use parameterized queries, since that is the best way to prevent SQL injection. And if you parameterize, you don't want the slashes anyway, and it's a waste of time to have PHP add them.)

回答5:

"Magic Quotes" was PHP's attempt at hand holding, preventing developers from shooting themselves in the foot with SQL injection when they didn't know any better. It's deprecated in PHP 5.3, and will be removed in PHP 6.

I say it's better to be explicit and escape what needs to be escaped, rather than escape everything and have to unescape things that will never be placed in the database. Magic quotes creates as many (or more) problems than it solves, in an attempt to shield people who should know better.

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

回答6:

Very easy question.
Imagine you want to send user's data via email. Or insert user's name from cookie into the form input. Do you think it will be good idea to have such names like Bob \"Buffalo\" Bill? I don't think so