SQL Injection – again?

This week I had – again – a longer mail thread on SQL Injection attacks. Probably it caught me at the wrong moment, as it was a very long week preparing for the IE Out of Band making sure everybody knows what they have to do. And then…

I was actually pinged by our office in Ireland as a blogger who is working heavily with our technology and seems to be a pretty experienced developer – this to set the stage.

So, the title of the post was (freely summarized): I was attacked by a SQL Injection, what is Microsoft doing against that? I then commented on his blog but unfortunately he decided not to publish my comment but get in touch with me directly. The interesting thing was (and this is the reason why I decided to blog myself about it) that I was asking him, what he was expecting from us as we published quite a bunch of guidance on how to protect against SQL Injection back in May and there is not much more we can do as SQL Injection is not a DB but an application problem as the app does not properly verify the input. I have seen some cases recently (and form the mail exchange we had over the weekend I guess that he is one of them) where a cookie was used to do the SQL Injection. So the application is saving some data in a cookie and loads the content from there directly generating the SQL Query. So if an attacker changes the content of the cookie he/she could run a different way of SQL Injections and inject a script into the DB. This blogger was actually hit pretty hard by a script called jpdog.3322. If you search for it in a search engine (you would never use Google, would you?) you find a hell lot of sites being infected. Scary!

Now, back to our blogger. I asked several times (and this goes to you as well): What else can we do to help to protect the ecosystem besides publishing the advise we already gave? I summarized the different sites back in May in posts called The latest SQL Injection Attacks and New Guidance on the SQL Injection Attacks.

Additionally we made a new version of the Security Development Lifecycle available to help you to write more secure code. See my post about that: Videos about the Security Development Lifecycle

So, his ask finally was: a patch. He is expecting us to issue a patch to solve this problem. To me, this is on the same level as you would ask us to issue a patch for the buffer overflows. Let me be clear once again: SQL Injection is about the app, not the DB!

I think at the end, he felt stupid (he got some pretty direct comments on his blog as well), which would be bad. We have been defaced based on a SQL Injection as well and I am convinced that it could happen to anybody. The key is, to make sure that you look for a solution at the root of the problem, which is the app.


Comments (1)

  1. Paschal says:

    Hi Roger, now one thing to add. I said also that I wish Microsft realease a future version of SQL Server where all the dnagerous bits are locked by DEFAULT. A bit like Windows Server 2008 where it’s up to the user to choose what he wants to open.

    Things like EXECUTE or SELECT on the Master table should be locked!

    Remember I am the only person availabel in my organization, and I am surely n ot the only one working like that. so my job consists of DBA, Programmer, IT, Firewall guru, etc…

    So it has been a a pretty tough ride recently with things that should not be there from the beginning.

    Another thing I didn’t know about is the ‘httponly’ attribut in we configuration files to lock the cookies in read only mode.

    Web config files have a huge number of methods, parameters and attributes and it’s very hard to know all of them. I am proud to say I learn every day, but the same than SQL if cookies can execute their code, they shouldn’t be allowed to do that by DEFAULT.



Skip to main content