How not to protect against SQL injection (view source) • Hacker News Board

Re: How not to protect against SQL injection (view source)

#111

Post by somedev » Wed, Mar 30, 2011, 11:45 AM UTC

It was me that actually built this site. Around 2000-2001. To give you a bit of background or "excuses":

It was my first website at an agency, I'd just taught myself ASP and SQL in just a few months previous (with no help or guidance). If my memory serves me correct, that dodgy JavaScript was put in there by a more senior developer. I had no idea what SQL Injection was and it wasn't until at least a few years later that SQL Injection was even something any developers I knew were aware of - The Wikipedia page for SQL Injection (http://en.wikipedia.org/wiki/SQL_injection) under "Known real-world examples" has the earliest dated at 2005 (but obviously, this vulnerability has been around forever).

And yes, I'm still a Web Developer (front-end nowadays - that also knows much better than this) and no, I no longer work for that agency and haven't for a long time.

In response to some of the comments: * I've seen many many developers write SQL Injection prone code at least 6 years after this was written. * Any developer that was around during 2000-2001 would know that this was before the time of CMS's (free or otherwise), libraries, frameworks, SQL abstraction layers etc. * I'm pretty sure there is some server-side sanitising done too (before we'd heard of the term SQL Injection). * I don't think it was using an SQL login with drop permissions.

Re: How not to protect against SQL injection (view source)

#112

Post by eustatius » Wed, Mar 30, 2011, 11:47 AM UTC

mixmax wrote: post #74

derleth wrote: post #72

Earlier quoted context omitted.

If you're lucky, you aren't in the UK so they won't be able to arrest you instantly on the hacking charges. If you're very lucky, the place you are in won't honor their demands for extradition on the hacking charges.

No offense, but I think you're a tad paranoid. If I was a mechanic and I saw someone at a gasstation driving a car that was obviously dangerous because of some kind of bad fixup I would tell him. This is no different, and I don't expect anyone to sue me for that. Here's the mail I sent: Hi there, It appears that you have some pretty severe security problems on your site. This is a heads up so you can get it fixed. I…

Getting penalized - sometimes heavily - for pointing out someone else's security problems can and does happen:

http://thedailywtf.com/Comments/Hack-School.aspx

Re: How not to protect against SQL injection (view source)

#113

Post by somedev » Wed, Mar 30, 2011, 11:51 AM UTC

Joeri wrote: post #13

The saddest part is that tons of people will be reading this thinking that they're way smarter than that guy, while in fact their sites are wide open to exploitation as well. That last statement probably applies to me too. Doing web security well is hard, too hard. Everyone gets caught with a security bug sooner or later, even google. It's easy to laugh with silly coding like this, but I blame the technology for allo…

See my comment above :)

Re: How not to protect against SQL injection (view source)

#114

Post by somedev » Wed, Mar 30, 2011, 11:53 AM UTC

pbhjpbhj wrote: post #53

julianc wrote: post #10

Earlier quoted context omitted.

Maybe the javascript is intentional, like a honeypot for hackers :)

Yeah, maybe the 100+ validation errors in the markup are like a honeypot for web designers too ... I've not seen 1x1 gifs for a few years now. And leaking the MS SQL server errors and IIS errors are just adverts for MS (I only did genuine searches, "hotel" got me to an error page). I'm sure the silly long names are part of the ruse too. There is much that could be done with this site. Perhaps I could drop them a CV.

See my reply above. Yep, 1x1 gifs and table layouts were cutting edge back then ;)

Re: How not to protect against SQL injection (view source)

#115

Post by csomar » Wed, Mar 30, 2011, 12:41 PM UTC

mixmax wrote: post #60

I just fired off an e-mail to point out that they have a potentially serious security problem and they should get it fixed ASAP. I see this as a civic duty, and think that this is the kind of action you're required to perform if you see a serious problem. Writing an e-mail takes ten seconds, but the potential damage could well cost serious money.

I once hacked into a Twitter Mass following tool. It was written with the .net stack and not obfuscated, so I was able to get the whole project source code.

I sent an email to the stuff out there. I typed "I just hacked your software. It's insecure and not obfuscated. Tell the devs".

The guy replied accusing me of hacking the software and told me that he is going to sue me. I just replied "F*ck you and your team. I was just playing around with no intent to make any damage for your company; but now I'll release a cracked version and distribute it".

I hadn't released a cracked version, though.

Re: How not to protect against SQL injection (view source)

#116

Post by _b8r0 » Wed, Mar 30, 2011, 1:26 PM UTC

mixmax wrote: post #74

derleth wrote: post #72

Earlier quoted context omitted.

If you're lucky, you aren't in the UK so they won't be able to arrest you instantly on the hacking charges. If you're very lucky, the place you are in won't honor their demands for extradition on the hacking charges.

No offense, but I think you're a tad paranoid. If I was a mechanic and I saw someone at a gasstation driving a car that was obviously dangerous because of some kind of bad fixup I would tell him. This is no different, and I don't expect anyone to sue me for that. Here's the mail I sent: Hi there, It appears that you have some pretty severe security problems on your site. This is a heads up so you can get it fixed. I…

The Computer Misuse Act 1990 makes no provision for intent (this is partially provided through the Police and Justice Act 2005 amendments). Instead, the act talks about unauthorised access, which is an undefined term.

In fact, a security consultant was convicted[1] for using ../../ in a URL after he thought a site had been hacked.

[1] - http://www.out-law.com/page-6207

Re: How not to protect against SQL injection (view source)

#117

Post by jggube » Wed, Mar 30, 2011, 2:52 PM UTC

nowarninglabel wrote: post #102

mixmax wrote: post #74

Earlier quoted context omitted.

No offense, but I think you're a tad paranoid. If I was a mechanic and I saw someone at a gasstation driving a car that was obviously dangerous because of some kind of bad fixup I would tell him. This is no different, and I don't expect anyone to sue me for that. Here's the mail I sent: Hi there, It appears that you have some pretty severe security problems on your site. This is a heads up so you can get it fixed. I…

I wouldn't say they were paranoid. A few months back I showed a colleague what looked like the openings of a very serious data leak in a major company's site. He investigated further and then reported it up through the chain of command and then over to the company. At no point did he do anything other than what was done here, as in point out a publicly visible security flaw. He was nearly fired after the company thre…

Is that the typical response to bug reports, or an exception to the rule?

Re: How not to protect against SQL injection (view source)

#118

Post by amalcon » Wed, Mar 30, 2011, 3:03 PM UTC

steve-howard wrote: post #25

Skalman wrote: post #18

Earlier quoted context omitted.

I don't think SQL is a bad API - it's just that every language makes it so difficult to use prepared statements! It shouldn't be harder than: sql_query('SELECT * FROM mytable WHERE name = ?', name) (I'm aware that this defeats the purpose of prepared statements to be reusable - this is just an API that's better than the current methods)

The side benefit of prepared statements, perhaps even more importantly if security is not really your concern, is that you don't need a password page that looks like this (this is really the password requirements page for my school): A password must: be 6-8 characters in length. contain a non-alphanumeric character such as ( ! ] & * , + = A password cannot: ... include a dollar sign ( $ ), a single quote ( ‘ ), a dou…

You don't need one of those anyway, if you hash your passwords like you should.

Re: How not to protect against SQL injection (view source)

#119

Post by Lozzer » Wed, Mar 30, 2011, 3:11 PM UTC

The linked page seems very safe. It has a very bad form checking function, but no actual form...

Re: How not to protect against SQL injection (view source)

#120

Post by mncolinlee » Wed, Mar 30, 2011, 4:15 PM UTC

Joeri wrote: post #13

The saddest part is that tons of people will be reading this thinking that they're way smarter than that guy, while in fact their sites are wide open to exploitation as well. That last statement probably applies to me too. Doing web security well is hard, too hard. Everyone gets caught with a security bug sooner or later, even google. It's easy to laugh with silly coding like this, but I blame the technology for allo…

This is a great point. As engineers, it's a great lesson that we need to stop apologizing for our tools and instead contribute to an effort to make them better. The natural language basis of SQL is very handy, but it does not lend itself well to detainting of input. There should be strict segregation until a late phase between what the developer wrote and what the site user wrote.

There is no excuse why programming languages should require the programmer to work around the inherent deficiencies of SQL. Just like the x86-64 architecture introduced the no-execute bit to the mainstream computing world and made the rampant buffer overflow remote code execution exploits of the 1990s into an endangered species, we should look to a technological solution to solve SQL's deficiencies.

Why should we need to trust that thousands of CMS module developers all use, know, and understand detainting of input in their native language? If we want to allow reuse of code, we put our absolute trust into thousands of developers other than ourselves.