What are the technical reasons that Magic Quotes has been removed from PHP 5.4 ?
From PHP docs
Performance
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.
Is there any other reason why Magic Quotes has been removed from PHP?
this is very well explained why the deprecated in manual by chao
Quoting comment of chao
The very reason magic quotes are deprecated is that a one-size-fits-all approach to escaping/quoting is wrongheaded and downright dangerous. Different types of content have different special chars and different ways of escaping them, and what works in one tends to have side effects elsewhere. Any sample code, here or anywhere else, that pretends to work like magic quotes --or does a similar conversion for HTML, SQL, or anything else for that matter -- is similarly wrongheaded and similarly dangerous.
Magic quotes are not for security. They never have been. It's a convenience thing -- they exist so a PHP noob can fumble along and eventually write some mysql queries that kinda work, without having to learn about escaping/quoting data properly. They prevent a few accidental syntax errors, as is their job. But they won't stop a malicious and semi-knowledgeable attacker from trashing the PHP noob's database. And that poor noob may never even know how or why his database is now gone, because magic quotes (or his spiffy "i'm gonna escape everything" function) gave him a false sense of security. He never had to learn how to really handle untrusted input.
also good read Wikipedia : Magic quotes Criticism
Related
I am working on a portal and I have these few questions regarding saving data in MySQL tables :
Should I save varchar field escaped ?
i'm using now mysql_real_escape_string() for avoiding string-injection.
Why should I save them unescaped (this was proposed by a guy on this website) and how would that work for characters like single and double-quotes. Doesn't it wreck the SQL command ?
easy talking around this topic.
And one last thing....I was using addslashes and stripslashes before using mysql_real_escape_string and it worked for me (of course, with mysql-injection of malicious code chance, which I recently discovered and documented myself on it)...
thanks
The very basic thing any programmer must learn is the meaning of context.
What am I going about here? If you knew the meaning of context, you wouldn't have asked this question. Now that (I hope) you know, you won't ask how to show <test> as HTML, or how to pass a variable to javascript.
So what's it all about? It's really easy. Context is the simple fact that something in a system may mean something entirely different somewhere else.
For example, in your case, a PHP string may mean something entirely different to MySQL. You can't just pass the string and expect everything to run smoothly - it won't.
So, now that you know what context means, you need to know something else that is important. You always need to convert a value from the older context to the newer one. Always.
Again, in your case, it's mysql_real_escape_string(), but a word of warning; conversion functions are context specific, so, for example, you can't use mysql_real_escape_string() to pass a string from PHP to Javascript. Similarly, you can't just use addslashes() and expect it to work. In fact, I'd argue that addslashes() is a completely useless and misleading function. Do NOT use it unless you are very sure of what you are doing.
Should I save varchar field escaped ?
No. You should escape data so that characters (in the data) with special meaning in SQL won't cause you problems.
Once it passes through SQL and gets stored in the database, it won't be escaped any longer.
i'm using now mysql_real_escape_string() for avoiding string-injection.
Don't do that, instead use prepared statements and parameterized queries
I was using addslashes and stripslashes
addslashes is a basic form of escaping. It is pointless unless you know exactly what the target of the data is. You should use something more specific where such a thing exists (and you are – mysql_real_escape_string)
stripslashes does the opposite of addslashes. Using them together is utterly pointless.
I have started using magic quotes and I have encountered a small problem, an easy problem I guess which I can't figure out.
I wan't to use striplashes which it does not remove when I write something in my textarea
Code:
<?php
echo "Removed Slashes: ";
// Remove those slashes
if(get_magic_quotes_gpc())
echo stripslashes($_POST['question']);
else
echo $_POST['question'];
?>
<form method='post'>
Question: <input type='text' name='question'/><br />
<input type='submit'>
</form>
I also tried this one which actually works!:
<?php
$str = "Is your name O\'reilly?";
// Outputs: Is your name O'reilly?
echo stripslashes($str);
?>
But now I want to use my input for the website for secutiry reasons
I cant put it any better than this comment by cHao on the manual page
The very reason magic quotes are deprecated is that a one-size-fits-all approach to escaping/quoting is wrongheaded and downright dangerous. Different types of content have different special chars and different ways of escaping them, and what works in one tends to have side effects elsewhere. Any sample code, here or anywhere else, that pretends to work like magic quotes --or does a similar conversion for HTML, SQL, or anything else for that matter -- is similarly wrongheaded and similarly dangerous.
Magic quotes are not for security. They never have been. It's a convenience thing -- they exist so a PHP noob can fumble along and eventually write some mysql queries that kinda work, without having to learn about escaping/quoting data properly. They prevent a few accidental syntax errors, as is their job. But they won't stop a malicious and semi-knowledgeable attacker from trashing the PHP noob's database. And that poor noob may never even know how or why his database is now gone, because magic quotes (or his spiffy "i'm gonna escape everything" function) gave him a false sense of security. He never had to learn how to really handle untrusted input.
Data should be escaped where you need it escaped, and for the domain in which it will be used. (mysql_real_escape_string -- NOT addslashes! -- for MySQL (and that's only unless you have a clue and use prepared statements), htmlentities or htmlspecialchars for HTML, etc.) Anything else is doomed to failure.
Really, take the advice. Don't use them, you won't learn anything useful by trying them out, just forget they ever existed.
Take a look at this article http://www.sitepoint.com/magic-quotes-headaches and this one http://econsultancy.com/us/blog/2663-web-app-security-basics-filtering-input-and-escaping-output for more information.
Well it's easy to attack but seemingly more effort to help. So here's my attempt at being helpful.
So, you are posting data back to the server and you want to ensure that whatever the user posts back does not end up somewhere that it can act maliciously.
The naive strategy you have adopted it to say ok, I'll sanitise data generically by turning on the magic quoting, which should escape all of the nasties...
However, it doesn't. Your job is to ensure that you use a custom sanitisation strategy when dealing with untrusted data, depending completely on how you use it. A good resource for learning where you should allow untrusted data to enter a particular location, and how to escape untrusted data can be found at OWASP
You'll notice that not all locations are suitable for untrusted data, escaped or otherwise. This highlights the fact that to truly implement secure websites you have to consider both where untrusted data is going and how data is getting there.
This question is more directly focussing on the how, because we are considering (and attacking the use of) a generic escaping mechanism. You are implying that turning on magic quotes is a suitable method for escaping data destined to all locations your untrusted data can end up.
Best practice says that actually, you need to use an escaping mechanism that is suitable for the location(s) you intend to use it. As has already been pointed out, the use of mysql_real_escape_string is a popular function which is specific to escaping strings for use in a MySQL query. People do use this mechanism, but the need to manually escape your data with this mechanism is superceded by the correct use of PHP Data Objects (PDO). (Binding your untrusted data to a parameter rather than manually building up query strings).
Other obvious escaping mechanisms include encoding html characters using htmlspecialchars or htmlentities and, the more generic quote escaping mechanisms addslashes and addcslashes. There are even escaping methods for command line arguments escapeshellarg and escapeshellcmd
So you can see that escaping data properly is far less trivial than applying magic quotes to all of your incoming data, and there are often well established mechanisms for escaping data safely depending on the location you intend to use it.
Easy fix to your problem is to create a simple function that you push all your data through if it is going to be touching your DB. Can be modeled as such:
function sanitizeString($var)
{
$var = strip_tags($var);
$var = htmlentities($var);
$var = stripslashes($var);
return mysql_real_escape_string($var);
}//end sanitizeString
I'm working on a PHP comment system and came across the problem that the commentator's quotation marks are delimited when written to the comment file, so the output would end up like this for example:
"That is your father\'s! It\'s special to him!" (random sentence). How do I disable this?
The backslashes are added to the database query to prevent SQL injection. You can use the stripslashes() function to remove them when you retrieve the comments from the database.
You should also take a look at magic quotes.
It depends on version of PHP and it's configuration. Older versions (older than 5.3) had this enabled by default. It adds the quotes when you post your comment (so it will be stored in the database with the quotes). You can disable this behavior:
http://cz.php.net/manual/en/function.get-magic-quotes-gpc.php
http://cz.php.net/manual/en/function.set-magic-quotes-runtime.php
http://cz.php.net/manual/en/info.configuration.php#ini.magic-quotes-gpc
For existing comments, you'll have to run some cleanup script that will fetch all rows, performs stripslashes() on it and save it back.
Escaping your queries should be done by mysql_real_escape() anyway, relying on magic quotes is suicide, so if you think about it, it's safer to turn them off completely and escape the queries manually.
Turn gpc_magic_quote 's off in your php.ini .
Those backslashes are there to escape the quotation marks from the SQL engine.
That style of programming is quite common with the mysql_* series of functions which take a string directly from the program and execute it directly in the database engine. This is notoriously prone to SQL injection attacks and, as you've discovered, corrupting your data. (When applied consistently, you can always de-corrupt the data on the way back to the user, with the stripslashes() function, but that also must be done consistently.)
The far better approach in my humble opinion is to use prepared statements and let the database libraries insert data directly into the database without any escaping or un-escaping involved. This also completely removes the risk of SQL injection attacks. (Though you're still free to write insecure code.)
I've never programmed in an environment with magic quotes turned on before. Now I'm working on a project where it is. This is how I've been setting up user accepted data situations:
$first_name = $_POST['first_name']
if(!get_magic_quotes_gpc()) {
$first_name = mysql_real_escape_string($first_name);
}
With that filtering, am I still open for SQL injection attacks when magic quotes is enabled?
I'm really only concerned about any kind of SQL injection that will break my queries... Other whitelisting, htmlspecialchar() -ing etc. is in place for other areas.
Looking at some similar SO questions it seems that it's being advised to instead check for magic quotes, run 'stripslashes' on the data if it IS turned on, and then always run the escape function. I'm a little apprehensive to do it this way though because all of the existing code in the site assumes it's on.
Thanks!
Working with a legacy system can be a real PITA - especially with something like PHP which let some pretty egregious insecure code be written in the bad old days.
I think you've actually already answered part of your question:
Looking at some similar SO questions it seems that it's being advised to instead check for magic quotes, run 'stripslashes' on the data if it IS turned on, and then always run the escape function. I'm a little apprehensive to do it this way though because all of the existing code in the site assumes it's on.
I would also try and initiate a code review - find all places where use data is being written or used in database queries, and then replace with the more secure escaping. Eventually, you'll replace all of those squirrelly queries, and be able to turn magic quotes off for good.
If you use mysql_real_escape_string (correctly) there is no risk of SQL injection. That doesn't mean the input will be ok. If your magic quotes settings or any other stuff is set incorrectly, your variable may contain an incorrect value. It is still safe however.
magic_quotes_gpc
We all hate it and many servers still use this setting and knowingly enough some provides will argue it's safer but I must disagree.
The question I have is, what would a backslash be needed for?
I want to remove them completely which I can do but I am not sure if they are needed?
EDIT
Other then SQL injection.
magic_quotes_gpc() was provided based on the misguided notion that ALL data submitted to PHP from any external source would be immediately inserted into a database. If you wanted to send that data somewhere OTHER than a database, you had to remove the slashes that PHP just inserted, doubling the work required.
As well, not all databases use slashes for escaping metacharacters. \' is fine in MySQL, but in MS Access, escaping a single quote is actually '' - so not only was PHP doing unecessary work, in many situations, it was doing the work WRONG to begin with.
And then, on top of all that, addslashes (which is basically what magic_quotes_gpc() was calling internally) can't handle all forms of SQL injection attacks, particularly where Unicode is used. addslashes is a glorified form of str_replace("'", "\\'", $string), which works at the ASCII level - plenty of Unicode sequences can look like regular ascii, but get turned into SQL metacharacters after a simplistic addslashes() has wreaked its havoc.
They are for preventing SQL injection exploits, a very serious issue you should read up on if you're going to be coding for the web.
You should look into prepared queries, which is a much better way of avoiding SQL injection.
There is no good reason to have this feature in PHP.
That's why it's officially deprecated and will not exist in future versions.
If there were good reasons to keep it, the developer community would have done so.
They are designed to make us do extra work to remove them. For example, some code in Dokuwiki.
Don't forget about magic_quotes_runtime too.