Live data from Hacker News

How not to protect against SQL injection (view source)

cadw.wales.gov.uk

101–110 of 125 posts

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

#101
welcome our store,we have the best service and good price,you can find what you want in our online store. Sennheiser" rel="nofollow">http://www.monster-beatss.com/sennheiser-c-2.html>Sennhe... Bose" rel="nofollow">http://www.monster-beatss.com/bose-headpones-c-3.html>Bo... Headpones Lady" rel="nofollow">http://www.monster-beatss.com/lady-gaga-headphones-c-4.html&... Gaga Headphones MBT" rel="nofollow">http://www.mbt-scarpe.net/mbt-baridi-shoes-c-2.html>MBT Baridi ShoesMBT" rel="nofollow">http://www.mbt-scarpe.net/mbt-baridi-shoes-mbt-baridi-womens... Baridi Womens GHD" rel="nofollow">http://www.ghd-midnight-uk.com/ghd-midnight-deluxe-collectio... Midnight Deluxe Collection GHD" rel="nofollow">http://www.ghd-midnight-uk.com/ghd-midnight-collection-gift-... Midnight Collection Gift Set GHD" rel="nofollow">http://www.ghd-midnight-uk.com/ghd-nobler-diamonds-gift-sets... Nobler Diamonds Gift Sets GHD" rel="nofollow">http://www.ghd-midnight-uk.com/ghd-pink-limited-edition-c-3.... Pink Limited Edition GHD" rel="nofollow">http://www.ghd-midnight-uk.com/ghd-iv-styler-green-c-5.html&... IV Styler Green

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

#102
post #74
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…

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 threatened to sue. The company only relented when he agreed to keep quiet and his employers disciplined him. The employers didn't back him up. All this for solely reporting a flaw, absolutely zero use of said flaw.

I lost a lot of my faith in humanity that day.

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

#103
post #52
post #23

Earlier quoted context omitted.

it's just that every language makes it so difficult to use prepared statements Huh? Most web frameworks use ORMs and discourage you from touching SQL at all.

Which is great until you discover that your needs can't be fulfilled by the ORM and you need/have to use SQL.

A good ORM such as SQLAlchemy can do (nearly) everything that SQL can, it even knows quite some specific options for SQL dialects.

Yes, there might be cases that a very specifically optimized query needs SQL, but those should be the exception not the rule.

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

#104
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…

It's not like this is an obscure corner-case that the developer forgot. In that case I'd agree with you.

This is a principal issue. Doing client-side parameter validation for security is a stupid idea in every case. Client-side validation is for user convenience only. This has nothing to do with SQL. Security must be implemented server-side. There are no exceptions to this.

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

#105
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…

Web security is hard, but I don't think its unreasonable to expect that someone you hire understands the basics of how to make a form submission secure, if they don't perhaps they should be flipping burgers instead. There is just no excuse for something so sloppy.

As for SQL being a "bad API" that might be one of the more ridiculous comments I have heard.

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

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

This is the government we're talking about... Whoever wrote this won't get sacked for gross negligence, which is what this is, as much as say, operating machinery without a safety cover, and is probably paid waaaay more than anyone with comparable "skills" in the private sector.

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

#107
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…

[deleted]

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

#108
post #106
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.

This is the government we're talking about... Whoever wrote this won't get sacked for gross negligence, which is what this is, as much as say, operating machinery without a safety cover, and is probably paid waaaay more than anyone with comparable "skills" in the private sector.

Actually, speaking as a Brit working in IT who has supplied various public sector organisations in the past, I think it's rather more likely that this would have been written by an outside agency to contract. And I wouldn't expect they were paid waaaay more from that experience either.

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

#109
post #30

Since they're using SQL Server (hint is that they are checking for "xp_"), you can get a list of all of their databases with "SELECT name FROM sys.databases", then loop through and drop them. Hope the web login doesn't have drop permissions.

Are they actually vulnerable? How do you know? People have gotten in serious trouble in the UK for "innocuously" testing web apps for SQL problems. Know that in both the UK and the US, you are taking a significant risk by prodding websites like this.

"Testing" a web app when it is not your job to do so is self evidently a suspicious act, just like walking down a line of cars testing the door handles to see if any have been left unlocked would be a suspicious act.
Post reply on HN