2007-08-09

`sql injection` free php; this blonde's easy answer.

*why is sql injection in php even a problem?*

i know a lot of old code still needs updated, and old versions with exploitable code is still all over the net. but why is new code ever having this problem. i know that the best practices answer is to use mysql_real_escape_string() to avoid these problems. but why? i dunno, cause i have an easier answer use htmlentities($input, ENT_QUOTES); on all user input, and i do mean all. i've implemented this on my current open source project. a second way of easily solving this issue is to use base64encoode(), the only problem i have with that solution is that it ends up making my database like impossible to read outside of my interface. but with htmlentities() everything is simply encode to where quotes simply are no longer an issue, because they're no longer there. using ENT_QUOTES is abs a must for this to fix remove sql injection vulnerability. the way i've implemented this is that during my projects core object instantiation i have it parse all get, post, &cookie vars through htmlentities($input, ENT_QUOTES). i do this with abs everything that receive from web browser that i may end up entering into any database. by this i mean certain http headers too, but that's only in special cases. using htmlentities($input, ENT_QUOTES); removes any possibility for sql injection, from user input that is. so no more escaping/un-escaping string or etc, and i can replace &update to my hearts content.

I have 'it', thousands do, and you've probably never heard of 'it'. 'it' twists our bodies, 'it' can ruin our lives; and occasionally 'it' will take them... what 'it' cannot twist, ruin, or take is our DREAMS! 'it' is Generalized Dystonia!
help test firefox3 while you rediscover the web!

No comments: