Page 1 of 1
Generic REQUEST addslashes
Posted: Sat Nov 04, 2006 3:37 pm
by alex.barylski
When I say REQUEST I mean all GPC variables...regardless of how you access them...
I know it's not ideal but outside of the security hole that Chris Shiflett(sp?) hilited with using *just* addslashes() on mySql databases...what problems can arise from just using a generic addslashes on GPC arrays???
Strictly security not filtering - I don't care about illegal characters getting in there...

as long as they can't be used maliciously...
Cheers

Posted: Sat Nov 04, 2006 3:43 pm
by timvw
Why would you want to have addslashes applied to all the GPC data? I simply don't see how it would be useful (actually, the exact opposite was true because i found it highly inconvenient having to deal with data that was addslashed...)
Posted: Sat Nov 04, 2006 3:46 pm
by alex.barylski
I don't see it as useful. I would never personally use this approach, but I've been given a source tree and asked to work out some issues and seen this approach being used.
I would love to rewrite the entire source base, but thats not likely...however is generic checks like the above are *practically* insecure (ie: Chris's article although accurate is not a practical concern for my situation).
Posted: Sat Nov 04, 2006 4:35 pm
by dbevfat
Well, if you use a database like MSSQL, where backslash is not the escape character, then addslashes() is of no use -- you have a wide open sql injection security hole.
Also, you're not immune to any attacks that are not affected by escaped/unescaped quote characters, like quoteless sql injections, file including, XSS attacks and such.
Apart from that, I can't think of any issues.
Posted: Sat Nov 04, 2006 7:45 pm
by Ambush Commander
What you'll want to do is add a magic_quotes de-emulation layer that runs stripslashes on all incoming data so that you can treat as regular stuff.
Posted: Sat Nov 04, 2006 8:46 pm
by alex.barylski
dbevfat wrote:Well, if you use a database like MSSQL, where backslash is not the escape character, then addslashes() is of no use -- you have a wide open sql injection security hole.
Also, you're not immune to any attacks that are not affected by escaped/unescaped quote characters, like quoteless sql injections, file including, XSS attacks and such.
Apart from that, I can't think of any issues.
Hmmm...I'll have to keep that in mind...thanks

Posted: Mon Nov 06, 2006 5:36 am
by Maugrim_The_Reaper
Adding slashes to all GPC has the same effect as magic_quotes_gpc - it's nothing more than an annoyance and a misled security measure which has little to no benefits. What matters is if this is being depending on to add security? How is it impacted by having magic_quotes_gpc on and off? Are slashed values being passed directly to the Database without reversal and correct escaping?
All fairly basic security questions. If necessary you might look into setting up some functional tests for a few vulnerabilities, run them, and see what sort of results drop out. A functional test framework of this kind would help pinpoint issues.
I'd add something AC mentioned - a magic quotes removal layer. Use it as a buffer between the $_GET/$_POST variables and any code you use/change. You'll need to do a typical stripslashes() for any manual addslashes() usage, and an additional stripslashes() is magic_quotes is enabled (assuming that has an impact). Then you can pretty much batton down your new code, and any changes you make elsewhere without breaking the rest of the application.
You should be using typical security practice on the newer stuff you intend adding. The rest of the application is likely a lost cause since it's probably been spaghettied over time as security issues arose (presumably).