Addslashes, stripslashes and mysql_real_escape_string...

[Hitman]

Hey, well basically I'm sanatising my inputs by using addslashes and mysql_real_escape_string. This is adding a lot of slashes, like ////... addslashes does just the same job as mysql_real_escape_string, so why do I need mysql_real_escape_string?

I'm then using stripslashes to remove the //'s on output, so everything looks nice.

If I'm using addslashes and mysql_real_escape_string, and then stripslashes on output, there are still some slashes.

So can I only use addslashes on input to sanatise the inputs?

Tom.

EDIT: Just been reading up, addslashes isn't totally secure by itself, so how about just using mysql_real_escape_string?

[Source]

Its up to you, but one of the most handy functions for cleaning strings is to put it through htmlentities. That changes any special character into the HTML markup version of it, for example a '&' would be &.

Still do some filters such as mysql_real_escape and stripslashes/addslashes if you want, but remember to unescape the string when you echo it back out - stops you from getting "/'s".

[Hitman]

Thanks for the reply, Source. I'll use addslashes and mysql_real_escape_string on input and then stripslashes and unescape on output. Just a question, what do you use to unescape the strings?

The HTML one doesn't matter tbh, but will the ones I'm using be secure from most things?

Tom.

[Source]

Why doesn't the HTML one matter? Surely its better to be putting a html equivilent of a " or ' rather than the actual thing. Its means PHP won't see it for the pure character it is...

[Hitman]

Why doesn't the HTML one matter? Surely its better to be putting a html equivilent of a " or ' rather than the actual thing. Its means PHP won't see it for the pure character it is...

I thought they'd be no point in including it if stripslashes are used... I'll use it though, could foil an attack if there's a workaround stripslashes or something.

Also, how do you unescape strings...?

[Source]

You would do the opposite to when you put it into the database. htmlentities is one of the best ways to stop from XSS, and you shouldn't need to reverse that process. If you do addslashes on input to the database, once you have grabbed the array again you can do stripslashes, ofcourse, this method can be flawed.

[Hitman]

You would do the opposite to when you put it into the database. htmlentities is one of the best ways to stop from XSS, and you shouldn't need to reverse that process. If you do addslashes on input to the database, once you have grabbed the array again you can do stripslashes, ofcourse, this method can be flawed.

Yeah, that's what I've got.

addslashes, htmlentities and mysql_real_escape_string on the data input, then on output I've got stripslashes to remove the slashes from addslashes... but there are still slashes from mysql_real_escape_string... need to remove them.