Stripslashes doesn't work for my magic-quotes in PHP

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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