Magic Quotes are gone?!

[redcrusher]

So, I think you have all heard the news. THEY ARE GONE!

 

Unfortunately, I do have some old code that I do not feel like going line by line and updating. I was wounding if you guys could help me out.

 

I was hoping that there would be a way to set a define of some sort then when I grab something out of an SQL table it will automatically takeout the "\" (Slashes) and when I insert something into the database it will add the slashes...

 

YES I know and have read the statement written by the php group [http://www.php.net/manual/en/securit...uotes.why.php] But i do not particularly want to go through my code and change everything by hand.

 

If you have any idea, or would like me to explain it another way, please post.

 

Any help will be greatly appreciated.

 

--redcrusher

[Pikachu2000]

There shouldn't be any slashes in the data in the database table anyhow. If there are, then the data is being double escaped, and that's another problem you should fix.

[scootstah]

Well, you could add quotes automatically to $_POST, $_GET, and $_COOKIE. Those aren't necessarily your entire input, though, so I wouldn't feel comfortable doing that.

 

You'll need to change stuff to remove them again though.

 

I think you're going to have to bite the bullet on this one.

 

While you're at it, swap to PDO so you don't have to worry about escaping.

[xyph]

Doing this by hand is the right way to do it. Trying to automate it or hack something together will probably open holes in your script.

 

When you re-do it, do it the right way

 

If you're a procedural-style programmer, create a function to sanitize your data. Save it to a file, include that file in each of your PHP scripts, and use it when you need to sanitize data. If you ever need to change this later, you open the one file, change the function, and the rest of your code automatically implements these changes. Repeat this process for any sort of repetitive code that you may have to change at a later time, and won't want to update every instance.

 

If you're an OO programmer, well, this probably wouldn't have been an issue

 

While you're at it, swap to PDO so you don't have to worry about escaping.

 

What about preventing injection on output? PDO won't prevent that. Regardless, it's prepared statements that avoid the need to escape data. You can execute a raw query in PDO just as easily as MySQL(i). Even in prepared statements, if you want to have a variable LIMIT clause, or anything that isn't 'query data' you have to manually sanitize any ways.

 

[edit] The easy, easy way out of this is to simply turn magic quotes on in your php.ini[/edit]

[redcrusher]

hum... The problem is that i will be running this on a 3.4 server and a 5.0 server ... so i can not use PDO... although that looks amazing!

 

as for "There shouldn't be any slashes in the data in the database table anyhow."

am i wrong (i very well could be), but is this not how it works?

 

$str = "you \\ me are \'cool\'";

$str = mysql_real_escape_string($str)

//Insert into table

THEN

//Get from table

the string would come back as "you \\ me are \'cool\'" or would it come back as "you \ me are 'cool'"?

[xyph]

It would come back as you \\ me are \'cool\'

 

When you use mysql_real_escape_string, the string saved to the database will look exactly how it did before you called it.

[redcrusher]

So let me get this right:

 

IF

$str  = "he \ she is 'cool' ! ";

//insert mysql_real_escape_string($srt);

 

when  i get it back it will be  "he \ she is 'cool' ! "

 

If so i think i just asked a question that is not that hard to fix and i apologize for wasting your time 

[scootstah]

What about preventing injection on output?

 

Huh?

 

Regardless, it's prepared statements that avoid the need to escape data. You can execute a raw query in PDO just as easily as MySQL(i).

 

I was implying the use of prepared statements. I figured if he was still using magic quotes there was a good chance he's also using the mysql extension, which of course does not support prepared statements. He could switch to MySQLi and use prepared statements too if he wanted, either way.

 

Even in prepared statements, if you want to have a variable LIMIT clause, or anything that isn't 'query data' you have to manually sanitize any ways.

 

I'm pretty sure you can use placeholders for LIMIT and such as well.

[xyph]

You're correct. For some reason I was developing with PDO and using the LIMIT clause with a placeholder was throwing errors. Removing it fixed that up. It must've been a mis-type in the query somewhere, cause my sample query executed flawlessly.

 

Thanks for clearing that up

 

As far as output injection, I'm referring to rouge mark-up, or XSS, but calling it HTML/JavaScript injection is accurate as well, I believe.

[scootstah]

As far as output injection, I'm referring to rouge mark-up, or XSS, but calling it HTML/JavaScript injection is accurate as well, I believe.

 

Ah. Well that's not really related to the database at all.

[xyph]

I can see your argument, but in my opinion, it's related in the fact that data stored in the database will *generally* be output to the browser at some point. 'Escaping' is such a generic term, saying you don't have to worry about it can lead to bad assumptions.

 

I'm just picking out broad statements, and clarifying them. I'm not trying to say you're wrong, though I targeted my initial response at you... I didn't mean it that way, and really should have read my response over when I edited it (or perhaps when I wrote it initially). Sorry, it kind of seems like I was correcting you, when I meant to only elaborate.

[scootstah]

'Escaping' is such a generic term, saying you don't have to worry about it can lead to bad assumptions.

 

Ah, I see what you're getting at.

 

My bad then, I should have been more specific.

[DavidAM]

It would come back as you \\ me are \'cool\'

 

When you use mysql_real_escape_string, the string saved to the database will look exactly how it did before you called it.

 

Just for the record: There are were two magic-quotes settings. The one everybody always talks about --- magic_quotes_gpc --- and the other one magic_quotes_runtime.

 

From the manual on Core Directives: magic_quotes_runtime

If magic_quotes_runtime is enabled, most functions that return data from any sort of external source including databases and text files will have quotes escaped with a backslash.

(emphasis added)

 

I have never come across a system where this was on, but if it is, then data from the database might need stripslashes.

[redcrusher]

Thank you very much! that cleared a LOT up for me

[xyph]

I have never come across a system where this was on, but if it is, then data from the database might need stripslashes.

 

I'd say that setting might need to be turned off! What a stupid, intrusive, annoying option. Thanks for letting me know it exists, I could see something like that being a bitch to debug if you didn't know that setting existed