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

11–20 of 125 posts

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

#11

Post by MatthewPhillips »

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.

If destruction isn't your fetish, you could also get all of the table names from the databases, and use sp_send_dbmail to send the SELECTs for all of them to your email address. There might be an easier way to get the data out though.

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

#12

Post by chc »

ZeroComplete wrote: post #8
donniefitz2 wrote: post #4

Earlier quoted context omitted.

I was thinking the same thing. Let's hope that's true.

It would seem kind of stupid if they were smart enough to implement validation but not smart enough to limit user access to it. Of course there's no accounting for the depths of stupidity.

That would actually not surprise me at all. There are a lot of Web devs who can make a site that renders in the browser and mostly works, but can't wrap their minds around the difference between server-side code and client-side. Browse through the JavaScript tag on Stack Overflow and you'll come across more than you can shake a stick at. Many people (either due to willful ignorance or a sad gap in their education) write functions like:

    function getTime() {
      
    }
It's not at all improbable that somebody told them their site was vulnerable to SQL injection, so they took a brief glance at the Wikipedia page and said, "I know, I'll just stop people from writing this stuff." So they open up the page where people might be entering the malicious text and write some code that will stop them. They run it in their browser and it works — none of their SQL strings make it through. They have now fixed the problem, as far as they are concerned, and the site owner doesn't know enough to tell them how utterly braindead their approach is.

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

#13

Post by Joeri »

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 allowing SQL injection in the first place. SQL is simply a bad API to be using in a web app.

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

#18

Post by Skalman »

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…

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)

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

#20

Post by stevemoy »

My 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.

Post reply on HN