Here’s an article about a mass attack that recently hit about a million pages, including a couple on apple.com.
It’s the latest in a wave of automated SQL injection attacks that compromise Web site databases and inject a hidden iframe into Web pages – the iframe loads malware from a third party domain, compromising the sites’ users.
Secure development experts cluck at attacks like this – SQL injection takes advantage of insufficient input validation in application code, a well understood developer error. It can be stamped out over time, but it’s still a big problem today. These attackers likely found a SQL injection vulnerability in a commonly used piece of server software, tailored a single-request attack for it, and sucker-punched millions of sites at once to see which ones would fall. It’s hard to defend against that.
It’s also interesting that input filtering at the gateway couldn’t really block this. The SQL was heavily encoded. Signature-based firewalls can’t reliably block this kind of malicious request without blocking many valid requests as well.
So what can be done? Lots. First, a gateway can be a lot more sophisticated about how it checks application input. A broad signature match may not be enough evidence to block a request, but it is a clear indicator that the request is suspicious. Delaying the request and performing additional analysis probably makes sense. It may slow down a small set of valid (but unusual) requests, but it will do a much better job of identifying an injection attack reliably.
Second, SQL injection isn’t really the end, just the means. If you can’t always prevent a SQL injection attack, you can detect that one has taken place and respond to it quickly. The sudden existence of an iframe linking to an unknown domain in your pages is something you want to know about right away. You also probably want to strip it out until you can learn more. A gateway that looks at HTTP responses in the right context can provide that visibility.
