Upvote here if you too have discovered sql injection vulnerabilities in your own web apps.
"Upvote here" doesn't work on HN.
Depends on your definition of 'work' doesn't it?
How not to protect against SQL injection (view source)
71–80 of 125 posts
Re: How not to protect against SQL injection (view source)
#72I 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.
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.
Re: How not to protect against SQL injection (view source)
#73Earlier 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)
This is the second time in a few days someone has made the point that web stacks make it hard to use prepared statements†. This is a one-liner in Rails. Does it not work in Python? How hard is it in PHP? † Which are not a cure-all for SQLI .
Very easy in PHP.
http://php.net/manual/en/pdo.prepared-statements.php
Re: How not to protect against SQL injection (view source)
#74I 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.
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 would recommend doing so ASAP.
Your site has been posted to hacker news (which is a friendly programming site for start-up people and nerds) as an example of bad security practices. The link is here: http://news.ycombinator.com/item?id=2383857
It has also been posted to Reddit, which might be more of a problem since that site has a lot of 14 year old bored teens hanging around that know just enough about programming to do a lot of damage... Link: http://www.reddit.com/r/programming/comments/gdviz/how_not_t...
It appears that your site is easy to compromise, which might lead to anything from defacement to someone stealing all your content, usernames, passwords, etc.
I have nothing to do with these postings, I just don't like to see innocent sites get in trouble, hence this mail. Feel free to contact me if you need anything or have questions.
Hope you get it fixed before someone breaks it.
Yours,
Max
Re: How not to protect against SQL injection (view source)
#75Earlier 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.
But does this mean, for example, that you should escape inputs yourself before passing them off to the framework, which is then ostensibly going to escape them again?
I think a better approach is to verify that the framework is correct. You can do this experimentally, by writing unit tests, or by reading and running the unit tests of the framework itself.
Re: How not to protect against SQL injection (view source)
#76Would have been better protected if their javascript was programmed in Welsh... :D
Re: How not to protect against SQL injection (view source)
#77Earlier 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've got $10 riding on "they see the word Hacker in 'Hacker News' and start freaking out". :D
Oh, I understand the word hacker in all its culturally and context relevant forms, and you understand the word hacker, but they do not understand the word hacker. :-(
Re: How not to protect against SQL injection (view source)
#78Earlier 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've got $10 riding on "they see the word Hacker in 'Hacker News' and start freaking out". :D Oh, I understand the word hacker in all its culturally and context relevant forms, and you understand the word hacker, but they do not understand the word hacker. :-(
That's why we have to tell them.
If we, as hackers of the sort that inhabit hacker news, have a post like this on the frontpage and noone cares to actually write them and tell them they have a security problem that may cause them serious damage we don't deserve better.
Re: How not to protect against SQL injection (view source)
#79Since 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…
If you take away write-access privileges, then malicious script still can steal your data.
Most of the time - that's really bad by itself even if you keep your copy of data intact.
Re: How not to protect against SQL injection (view source)
#80Earlier quoted context omitted.
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.
But does this mean, for example, that you should escape inputs yourself before passing them off to the framework, which is then ostensibly going to escape them again? I think a better approach is to verify that the framework is correct. You can do this experimentally, by writing unit tests, or by reading and running the unit tests of the framework itself.
If you assume the framework is correct, and then you update, migrate, whatnot, can you still be sure the framework is correct, or hasn't broken. If you can ensure your own code is good, then you are ahead of the game in such a situation.