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

How not to protect against SQL injection (view source)

cadw.wales.gov.uk

Post reply on HN
Print view View original

81–90 of 125 posts

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

#81

Post by elliottcarlson »

elliottcarlson wrote: post #64
upgrayedd wrote: post #51

Earlier quoted context omitted.

Sorry, I just don't do any apps that touch the internet...just some programming for fun on the side. The only thing that I've written that could be applied to this is our POS system at the restaurant I work at as a dishwasher and cleaner for. It's in Django though, and the Django project takes care of most issues with that...not that they're really priority #1 security-wise...

You should never assume that your framework of choice does everything for you. This is by all means no shot at Django, but just in general, always assume what you are working with is insecure and full of bugs - and then account for that - if your framework/programming language of choice accounts for additional things - great.

I don't complain about down votes - but it actually shocks me to think someone felt that my statement was counterintuitive to this thread and didn't offer anything possibly insightful. I think that it is irresponsible to assume third party code is safe - or will remain safe. If you feel that that is overly cautious so be it - but I rather be safe than sorry. But I guess that is just my opinion.

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

#83

Post by TallGuyShort »

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…

You're right, getting sued for pointing this out would be absurd. But where you're wrong, is that just might've happened. There are more ridiculous lawsuits out there. There was a story on here a couple of years ago where a US Government real estate web site was using JavaScript for their authentication, with the password stored in plain text. When it was pointed out to them via email, they responded with allegations of computer fraud and threatened to file charges. Obviously they weren't 100% serious and I'm sure nothing official came of it - but yes, people this stupid are that ridiculous.

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

#85

Post by recoiledsnake »

vain wrote: post #69

http://news.ycombinator.com/item?id=2370022 (CEO Friday: Why we don’t hire .NET programmers) Would an open source programmer do something like this?

>Would an open source programmer do something like this? Why not? http://www.eweek.com/c/a/Security/Oracles-Suncom-Hit-Along-w...

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

#86

Post by Groxx »

graywh wrote: post #52
moe wrote: 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.

ie, in every non-trivial or legacy-supporting use. Such as everything in existence for a non-brand-new company.

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

#88

Post by jpadvo »

fleitz wrote: post #70
MatthewPhillips wrote: post #9

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.

Heh. One of the best protections against SQL injection is not to grant those privileges to the db account from the webserver. So many sites could protect themselves at the least from data loss by using the built in tools. Also, I've worked on projects where the only way to change a table is via a stored proc, no select access on the tables, no SQL injection. Or at least you'll have to figure out a way to to the injec…

Why the downvotes? It is common sense to not run software with more permissions than it needs. Your production app shouldn't connect to your database through the root account, for example, unless it needs full, complete permissions to function. Not likely.

Of course, this does not eliminate the need for solid code-based prevention of injections...

Post reply on HN