Michael Howard on SQL Injection and my concerns on the most recent attacks

Michael Howard on SQL Injection and my concerns on the most recent attacks

Summary: So, in catching up with blogs after vacation, I went and had a peak at Michael Howard's web log, and was glad to see another post from him.  His posts are very insightful (I just wish he would post more).

SHARE:

Michael HowardSo, in catching up with blogs after vacation, I went and had a peak at Michael Howard's web log, and was glad to see another post from him.  His posts are very insightful (I just wish he would post more).  So, way back on May 16th (old news now, but still interesting) Michael commented on the recent rash of SQL Injections, and he made some excellent points, especially about how to prevent these types of issues.  Michael mentioned: 

You may have read recently about a large number of Web serversthat were compromised through a SQL injection attack. The malicious SQL payload is very well designed, somewhat database schema agnostic and generic  so it could compromise as many database servers as possible. While the attack was a SQL injection attack that attacked and compromised back-end databases courtesy of vulnerable Web pages, from a user's perspective the real attack was compromised Web pages that serve up malware to attack user's through their browsers. In essence, there were two sets of victims: the Web site operators and the users who visited the affected Web sites. In this post, I want to focus on what the first set of users, the Web site operators, can do to protect themselves.

The fact that the malicious payload was so generic shows that the science of SQL injection has not taken a back seat to research in other vulnerability types, such as buffer overflows or cross-site scripting issues.

I think the first lesson from this attack is this:

If you have a Web server (doesn't matter what type), and it's hooked up to a database (doesn't matter what type) you need to go in and review your code that performs the database work.

This is a great point which may have been missed.  While this attack was targeted at IIS and Microsoft SQL server databases, SQL injections are an issue on all platforms.  Michael has some great steps on how to shore this up:

So now that you've determined the database access code, now what? The SDL is very specific about what do here, there are three requirements - they are requirements not recommendations, which means you must do the following coding requirements and defenses

  • Use SQL Parameterized Queries
  • Use Stored Procedures
  • Use SQL Execute-only Permission

I'll link to his blog for the detailed breakdown of all of those defenses, it's a nice reference.

What concerns me most about this attack is that everyone is talking about the proliferation of malware through this attack, through the use of UPDATE commands, but I haven't seen much discussion about exfiltration of the data on these database servers, which almost certainly would've been possible for these attackers.  Further, they could've selectively been stealing this data and using the malware as a smoke screen for that activity.  If you were hacked by this attack, I think you need to assume your data was exfiltrated unless you have logs supporting that it was not (even then I'd be cautious).

-Nate

[poll id=5]

[poll id=6]

Topics: Security, Browser, Data Centers, Data Management, Enterprise Software, Software, Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

6 comments
Log in or register to join the discussion
  • votes are off

    8 votes right now: No for 1st is 100% & Yes is 13%, same for 2nd, exception Yes & No percentages are switched. Poll bug?
    php_developer
    • now they're good

      At 9 votes, they show up correctly
      php_developer
      • Weird

        Strange... wonder what happened.

        -Nate
        nmcfeters
  • RE: Michael Howard on SQL Injection and my concerns on the most recent atta

    I think the real issue here is amateur software engineerings/web developers. SQL Injection is one of the oldest and most obvious tricks in the book and is relatively easy to guard against, if you're developing websites and you don't know about SQL Injection then you shouldn't be developing websites. Also a developer who doesn't know about SQL Injection probably know's nothing about XSS, Session hijacking or Networking sniffing either. Let someone like that loose on your application's code base and you're asking for trouble.

    Another thing, 'Use SQL Parameterized Queries', 'Use Stored Procedures' and 'Use SQL Execute-only Permission' are all good advice. Another one you could add is to 'Use an Object Relational Mapper (ORM)' like Hibernate/NHibernate, Ling 2 SQL etc. as these generally parameterise all input data for you automatically.
    Sunday Ironfoot
    • Good comments, but...

      It's sad to say that a majority of the fortune 500s out there are still struggling with SQL Injection. You mentioned ORM, which I'm a huge fan of for programming capabilities:

      "Another one you could add is to 'Use an Object Relational Mapper (ORM)' like Hibernate/NHibernate, Ling 2 SQL etc. as these generally parameterise all input data for you automatically. "

      However, I will mention that even ORM and parameterized queries can be jacked up leading to SQL injection if you construct the original string with a direct variable include.

      -Nate
      nmcfeters
  • RE: Michael Howard on SQL Injection and my concerns on the most recent attacks

    <a href="http://www.casininio.com">casininio</a> |SQL attacks sucks
    viviposter