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

61–70 of 88 posts

Re: SQL Injection Galore

#61

Post by Killswitch »

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 ;-)

Just because it's dirty doesn't mean someone else can't use it and make it clean.

Re: SQL Injection Galore

#63

Post by nucleardog »

hahainternet wrote: post #20
fooyc wrote: post #19

Earlier quoted context omitted.

Nothing specific to the language here. Mentioned functions do exactly what their names imply. Just like ruby or python, PHP has great templating languages, support for prepared statements, etc.

This is often said, but these problems are practically endemic in the PHP 'community'. I can't help but think that the lack of proper documentation or basic explanations is responsible.

There really is no 'community'. The official documentation is fine (the included comments actually make it pretty good).

The problem is mostly the widespread support and low barrier to entry. PHP is supported on every crappy $2/m hosting plan.

It's also the language of a lot of the net's more popular CMSs. (WordPress?).

People have a site and want to make it do stuff. The site is already either using PHP or that's all the host supports.

PHP gets most of the users who aren't trying to get into programming (and may have no interest in it whatsoever) - they just wanna get something done. Some of those people develop an interest and stick around and learn the language, but aren't really forced to learn any software development methodologies.

PHP acts as a filter, collecting all of the non-programmers and people who have stumbled into programming accidentally or unintentionally. People who write Ruby or Python are generally people who set out to be a programmer.

The language itself has its warts, but I see the above, not the warts, as the primary driver of all the crappy code out there.

Re: SQL Injection Galore

#64

Post by mesozoic »

freehunter wrote: post #57
ygra wrote: post #53

Earlier quoted context omitted.

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.

Technically if the code doesn't have an open source license attached then it is still their copyright and isn't up for you to use even if on Github.

Re: SQL Injection Galore

#66

Post by brokentone »

To be clear, this list is not all exploitable. It only shows php files that use both GET variables and the mysql_query function. Not all of these variable are being fed unescaped into a query, nor are they necessarily used in a query at all.

Re: SQL Injection Galore

#68

Post by crazygringo »

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,…

Because there are plenty of times when that would break things. Consider:

    $table_name = $_GET['from'];
    if (!in_array($table_name, $VALID_TABLES)) {
      die('Invalid table name');
    }
    $set_to = (int)$_GET['set_to'];
    mysql_query("INSERT INTO $table_name (value) " .
      "VALUES ($set_to);
Quoting/escaping the table name in this case would break the code. (Backticks will work, but that's another story.) The variable has already been sanitized immediately before, so there's no injection possibility.

The case with $set_to is still pretty bad form, but it has been sanitized above by casting to an int.

Not saying this is great code, just pointing out the fact that there's no possible way to do a mass-commit fix.

Re: SQL Injection Galore

#69

Post by bpatrianakos »

brokentone wrote: post #66

To be clear, this list is not all exploitable. It only shows php files that use both GET variables and the mysql_query function. Not all of these variable are being fed unescaped into a query, nor are they necessarily used in a query at all.

Agreed. I find posts like these disingenuous. What do learn from this list? I think we all know that SQL injection is a serious problem and a very common mistake already. What this list seems to do is just serve as a high horse we can all get on and proceed to shame and look down our nose at people who:

- Use raw $_GET variables in their code - Use $_GET in MySQL queries - Use mysql_real_escape_string instead of prepared statements or otherwise properly sanitizing input - Use PHP in general

We already know we should all be using prepared statements or combining data sanitizing methods with an ORM and to not trust raw user input and that its cool to hate on PHP. So I ask again, what are we learning here? That there's a ton of programmers who are doing sloppy incompetent work? Not news.

Furthermore, I think context is important. I'm not ashamed at all to say out loud that I've done these sorts of things knowingly and purposefully despite knowing it's not safe or correct. Why? Maybe I was creating simple examples to teach others the basics of getting user input and working with it in a database. Of course you'd warn people not to do things like that in a production environment but you show it that way anyway to get across some basic ideas without throwing too much at people. Or what if I were writing a simple series or scripts or small app that would only be used by myself or a select group of people? What if that application needed to be done in a hurry and was only for internal use and not accessible to the outside world? Lots of things can always go wrong but at a certain point you have to be able to trust someone and its not always better to be right than happy. I'm sure if anyone wants to be pedantic they can poke holes in my examples but the point is that these sorts of sins aren't always so awful depending on the context. I don't see any purpose in this other than to either look for open source applications to exploit in the wild or to just pick on a really easy target to make us all feel superior.

Re: SQL Injection Galore

#70

Post by grey-area »

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.

Sure, it could be on by default but easy to turn off if you wanted to.

Thinking about it again probably it'd be best as a per-repro flag that made a little button appear somewhere saying 'security', 'code police' or something similar, leading to more info. Obviously it'd take a bit of work and generate some false-positives, but I could see a system like this being really handy if they accepted open contributions for filters, even if it was opt-in it would probably still help a lot of people.

Re dirty hacks, I guess I wouldn't publish things like that to github, I'd keep them in a local or private repo, as they're not for sharing. If they are for sharing in spite of vulnerabilities, turning off a warning shouldn't be too much hardship for you, and it could actually help others looking at the code quickly tell it wasn't to be used in production as it would mark it as unsafe.

Post reply on HN