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

81–88 of 88 posts

Re: SQL Injection Galore

#81

Post by seandougall »

krapp wrote: post #59
spoiler wrote: post #56

Earlier quoted context omitted.

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

Lots of generic hosting providers can be used for it too, if you have a hosting account somewhere. As long as the server has git and you have SSH access, you can do this on the server side:

$ mkdir project_name.git; cd project_name.git; git init --bare

Then locally, from the repo directory:

$ git remote add origin username@server.com:~/path/to/project_name.git

That's what I do (on Webfaction). Of course, then you don't get all the fancy issue tracking and all that from github, but it works if all you need is a few kb of storage for a remote. That also makes it easy to deploy PHP projects with a single post-receive hook, since it's all in the same box.

Re: SQL Injection Galore

#82

Post by seandougall »

bpatrianakos wrote: post #69
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 prep…

I totally get what you're saying, but this right here is kind of the problem:

> Maybe I was creating simple examples to teach others the basics of getting user input and working with it in a database.

I'm one of the countless people who learned PHP off of examples that do just that, for clarity, and it was years before I learned that it was not meant to be a real-world example. Sites that offer such examples (I'm looking at you, w3schools) are probably responsible for 90% of all the bad code that shows up on lists like this, because the exchange amounts to:

Student: "How do I do XYZ?"

Teacher: "It's easy! Just do 123."

Student: "Thanks!"

Teacher (to empty room): "Haha, just kidding. You should really forget that entirely and do 456 instead."

I don't think it's valuable to learn about mysql_query("delete from `tbl` where id = {$_GET['id']}") at all in the first place, if you just have to unlearn it and start doing it the right way later. It doesn't actually simplify anything.

Re: SQL Injection Galore

#83

Post by krapp »

bpatrianakos wrote: post #69
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 prep…

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.

We are not the problem, but we should consider trying harder to be the solution. Maybe new PHP programmers do need to be educated, and there's a lot of outdated source material out there giving them bad advice and spreading bad practices. Maybe people putting their stuff on Github don't entirely realize how networked and public it is... and they need a polite reminder that other people might end up paying for their haste or negligence. We can do more than just point and laugh. PHP might be bad but a lot of us know it doesn't have to be as bad as most of it still is.

Re: SQL Injection Galore

#84

Post by ris »

a904guy wrote: post #5
a904guy wrote: post #3

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

I only found one exploitable example browsing the first few pages, whereas the majority of the OP's results looked fairly exploitable.

Re: SQL Injection Galore

#85

Post by rhizome »

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.

Matt Wright, is that you?

Re: SQL Injection Galore

#86

Post by cgore »

seandougall wrote: post #81
krapp wrote: post #59

Earlier quoted context omitted.

Bitbucket lets you have free private repositories. That's where i'm storing my dirty laundry at least...

Lots of generic hosting providers can be used for it too, if you have a hosting account somewhere. As long as the server has git and you have SSH access, you can do this on the server side: $ mkdir project_name.git; cd project_name.git; git init --bare Then locally, from the repo directory: $ git remote add origin username@server.com:~/path/to/project_name.git That's what I do (on Webfaction). Of course, then you don…

Or type slightly less:

  $ git init --bare project_name.git
It will make the directory for you.

Re: SQL Injection Galore

#87

Post by qu4z-2 »

snorkel wrote: post #76

Instead of policing every line of code you can also mitigate SQL injection by restricting the access of the database handle the user-facing queries are using * All read-only queries use a read-only (SELECT only) database account. Injecting; DROP TABLES or INSERT, UPDATE, etc (DML commands) just error out. * User accounts and logins are stored in a different database, so only the code responsible for login and registr…

So instead of policing every line of code we should just use prepared statements everywhere?

Re: SQL Injection Galore

#88

Post by ygra »

martin_ wrote: post #67

What's more concerning is the amount of people choosing not to use parameterized queries with mysqli: https://github.com/search?q=extension%3Aphp+mysqli_query+%24...

This could be in part because the procedural interface of mysqli is deliberately designed to be vyer similar (if not identical) to the mysql one. So maybe they just continued writing their code that way but replaced mysql by mysqli because someone told them mysqli was better and supported (which it is, but probably for other reasons).

I wonder whether a similar search for the mysqli OO interface yields the same amount of unsanitised queries. (Assumption: People using the OO interface looked through the documentation more closely and maybe understand the ways in how mysqli is better than mysql. But that's just an unfounded assumption.)

Post reply on HN