Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQL Injection Galore

github.com

Post reply on HN
Print view View original

51–60 of 88 posts

Re: SQL Injection Galore

#51

Post by freehunter »

grey-area wrote: post #6

I find it incredible that there are 86,453 results for this, and 58,123 results for execution of a parameter as a command! Github should set up a little warning for people when they log in to their account if their repos match any of a set of obvious security anti-patterns, because this would be fertile ground for exploits. They could expand it later to some kind of code-review bot which does automatic code reviews l…

That would be great, but I would hope it could be turned off. I have plenty of code on GitHub that's clearly marked as just something I put up in a few hours for personal use only, where I don't care if there's vulnerabilities or exploits. The code was written in the true spirit of hacking, fast and dirty in order to solve an immediate need.

Re: SQL Injection Galore

#52

Post by diminoten »

user24 wrote: post #10
yuvadam wrote: post #7

Bear with me on this one - All the code is already public on Github, so everyone can see these gaping security holes, right? What if some honest, global actor could mass-commit a fix for all these repos in one fell swoop? For example, replace all references to: $_GET with: some_safe_sanitizer($_GET) All affected repos win a free fix, and the world becomes a better place due to having less security bugs. Essentially,…

To do it properly you'd want to use prepared statements[1] which requires a non-trivial, though not particularly complicated, syntax change. So your global actor would have to parse the PHP in a rather more intelligent way that just a string replace. You could just use mysql_real_escape_string [2] but that's less secure than prepared statements, and may break some things (eg if the code is relying on certain things n…

The pull request could be done "stupidly", which may fix most problems (your 80% value), and for cases where it wouldn't "just work" the author could just reject the pull request but still be made aware of the problem.

Re: SQL Injection Galore

#53

Post by ygra »

freehunter wrote: post #51
grey-area wrote: post #6

I find it incredible that there are 86,453 results for this, and 58,123 results for execution of a parameter as a command! Github should set up a little warning for people when they log in to their account if their repos match any of a set of obvious security anti-patterns, because this would be fertile ground for exploits. They could expand it later to some kind of code-review bot which does automatic code reviews l…

That would be great, but I would hope it could be turned off. I have plenty of code on GitHub that's clearly marked as just something I put up in a few hours for personal use only, where I don't care if there's vulnerabilities or exploits. The code was written in the true spirit of hacking, fast and dirty in order to solve an immediate need.

Maybe dirty, hackish code for personal use only shouldn't make it out into the public ;-)

Re: SQL Injection Galore

#54

Post by diminoten »

cruise02 wrote: post #34

Next time someone asks you "How do I find open source projects to contribute to?" this is a good place to start.

This is brilliant, and doesn't necessarily have to be exploits. You could just search for any anti-pattern and fix it.

I'm a little sad I hadn't thought to do this already...

Re: SQL Injection Galore

#55

Post by tomjen3 »

harrytuttle wrote: post #24

I 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.

I am not sure that is enough, I mean if you look at the supposed results many of them can't actually be actacked (like the on that tests that Id is a number before it is used) but a semi stupid script wouldn't catch those.

Re: SQL Injection Galore

#56

Post by spoiler »

ygra wrote: post #53
freehunter wrote: post #51

Earlier quoted context omitted.

That would be great, but I would hope it could be turned off. I have plenty of code on GitHub that's clearly marked as just something I put up in a few hours for personal use only, where I don't care if there's vulnerabilities or exploits. The code was written in the true spirit of hacking, fast and dirty in order to solve an immediate need.

Maybe dirty, hackish code for personal use only shouldn't make it out into the public ;-)

What if op doesn't want to pay for private repositories to store his hackywhackys or wants to share them with others?

Re: SQL Injection Galore

#57

Post by freehunter »

ygra wrote: post #53
freehunter wrote: post #51

Earlier quoted context omitted.

That would be great, but I would hope it could be turned off. I have plenty of code on GitHub that's clearly marked as just something I put up in a few hours for personal use only, where I don't care if there's vulnerabilities or exploits. The code was written in the true spirit of hacking, fast and dirty in order to solve an immediate need.

Maybe dirty, hackish code for personal use only shouldn't make it out into the public ;-)

I would expect any code marked "quick hack to solve [obscure problem], not for production!" to be pretty clear.

If someone is encountering the same problem, the code is there for them to use. If they happen to use it in production, that's hardly my fault.

Re: SQL Injection Galore

#59

Post by krapp »

spoiler wrote: post #56
ygra wrote: post #53

Earlier quoted context omitted.

Maybe dirty, hackish code for personal use only shouldn't make it out into the public ;-)

What if op doesn't want to pay for private repositories to store his hackywhackys or wants to share them with others?

Bitbucket lets you have free private repositories.

That's where i'm storing my dirty laundry at least...

Re: SQL Injection Galore

#60

Post by user24 »

diminoten wrote: post #52
user24 wrote: post #10

Earlier quoted context omitted.

To do it properly you'd want to use prepared statements[1] which requires a non-trivial, though not particularly complicated, syntax change. So your global actor would have to parse the PHP in a rather more intelligent way that just a string replace. You could just use mysql_real_escape_string [2] but that's less secure than prepared statements, and may break some things (eg if the code is relying on certain things n…

The pull request could be done "stupidly", which may fix most problems (your 80% value), and for cases where it wouldn't "just work" the author could just reject the pull request but still be made aware of the problem.

I think what I'd do is write a bot that issues pull requests along with a commit message explaining what was fixed, why it needed fixing, how the automatic fix isn't perfect and that they should really consider rewriting it to use prepared statements.

Include a check to make sure multiple bugs in a single repo are handled by just one pull request too.

Post reply on HN