Next time someone asks you "How do I find open source projects to contribute to?" this is a good place to start.
At first I thought "this is so mean" when I saw the search query, but with your comment comes a silver lining...
SQL Injection Galore
41–50 of 88 posts
Re: SQL Injection Galore
#42I have commit hooks on our repository that look for things like this and prevent the user committing it! We've got 30 odd rules so far that have saved us from all sorts of pain from exception swallowing to adding test ignores as well.
Could you share some of these?
Not really at the moment. I've been slowly refactoring it into a publishable chunk of code but progress is slow. I will publish it on github when it is done.
Re: SQL Injection Galore
#43I always preferred the remote code execution search myself personally... https://github.com/search?q=extension%3Aphp+exec+%24_GET&typ...
Holy shit! Look at this! This is hilarious! https://github.com/bratliff/engconf/blob/0b8f003edc5f5d25fe1...
Re: SQL Injection Galore
#44What I find equally worrying and sad is the fact that mysql_* extension is so widely used although it has been deprecated 3 years ago.
Re: SQL Injection Galore
#45We actually clean the GET and POST arrays in an include when the page gets requested, if you need anything unescaped you specifically have to request it from a different array. The code looks something like this: $_GET = array_map ( 'strip_tags', $_GET ); $_GET = array_map ( 'mysql_real_escape_string', $_GET ); Although there is a bit more to it than just this.
I think this is bad practice. You should not check your input but your output. So clean up the var that goes into the database.
Re: SQL Injection Galore
#46I always preferred the remote code execution search myself personally... https://github.com/search?q=extension%3Aphp+exec+%24_GET&typ...
Django... https://github.com/search?q=extension%3Apy+os.system+%22requ...
The difference is that SQL injection will only happen when using raw queries.
System (as you mentioned) or EXEC injections, however, may get out of hand.
Re: SQL Injection Galore
#47I always preferred the remote code execution search myself personally... https://github.com/search?q=extension%3Aphp+exec+%24_GET&typ...
Holy shit! Look at this! This is hilarious! https://github.com/bratliff/engconf/blob/0b8f003edc5f5d25fe1...
Oh. And it's for wordpress. Isn't that just fucking wonderful. I would guess looking at the age of the account and the complete lack of documentation that it's a personal project he never really intended to get much scrutiny. I'm sure if someone looked at my github they could find some bad code too. Not that bad though.
Edit - made an issue.
Re: SQL Injection Galore
#48I always preferred the remote code execution search myself personally... https://github.com/search?q=extension%3Aphp+exec+%24_GET&typ...
Holy shit! Look at this! This is hilarious! https://github.com/bratliff/engconf/blob/0b8f003edc5f5d25fe1...
And it has been already exploited:
http://wordpress.org/support/topic/plugin-ezpz-one-click-bac...
Re: SQL Injection Galore
#49Wow. This has just turned into a great example for one of my classes. I don't think there's a better way (other than hands-on examples) to show the severity and widespread of such security holes.
Re: SQL Injection Galore
#50my 2 cents: 1) At the first place, yes, it does look like these are sureshot SQL injections. 2) However, we are looking through just a tiny window. There could be filter chains executed long before this code that would sanitize the request parameters before they are consumed anywhere else in the codebase.
It is a small window, however, wouldn't it be better to filter the values into an easily identifiable 'clean' variable? The code is still using $_GET, and while it may have been filtered above me, I have no indication of that - versus - $foo->cleaned('var') - where I can reasonably assume it is clean.