When I was working in the financial sector, I came across an email thread involving a certain software vendor who had been notified of a SQL injection vulnerability. To fix it, they created an IF statement that did a string comparison to check for the exact SQL attack that had been used.
How not to protect against SQL injection (view source)
61–70 of 125 posts
Re: How not to protect against SQL injection (view source)
#62I have a feeling that this site won't be up much longer after making front page of HN, and it will have nothing to do with server load.
It was on reddit yesterday I believe which means tons of kiddies saw that. People were guessing that it included sanity checking on both sides because it wasnt down yet.
Re: How not to protect against SQL injection (view source)
#63My take on this is that the scriptwriter's goal was not to stop SQL injection attacks but rather prevent regular users from inadvertently screwing with the database. Looking at it that way makes it a much more understandable (and all-too-common, unfortunately) oversight.
Erm... if the server-side was already escaping properly then there would be no way for users to mess with the database. Only if it is not escaping properly is this code vaguely useful.
It's not like you can't store semi-colons in an SQL database :)
Re: How not to protect against SQL injection (view source)
#64Earlier quoted context omitted.
I wrote an iPhone app with a sqlite backend that was vulnerable to SQLi. Don't think you aren't vulnerable even if your application doesn't touch the internet.
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.
Re: How not to protect against SQL injection (view source)
#65Poor old Bobby Drop Tables will be out of luck again.
Re: How not to protect against SQL injection (view source)
#66There are more websites than competent admins so this kind of thing is inevitable. If you were a nice guy you would have reported it to the admin and left it at that.
Re: How not to protect against SQL injection (view source)
#67Well at least form & function are equals.
Re: How not to protect against SQL injection (view source)
#68Re: How not to protect against SQL injection (view source)
#69http://news.ycombinator.com/item?id=2370022 (CEO Friday: Why we don’t hire .NET programmers)
Would an open source programmer do something like this?
Re: How not to protect against SQL injection (view source)
#70Since 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 injection into the stored proc which is nigh impossible unless they are using exec_sql in the store proc.