StickyMinds.com has just posted an article of mine on the dangers of XSS. (Although they still have my old bio from when I worked at HP, I'll have to get that changed!)

In light of the recent wake of SQL injection attacks on ASP sites, I'd like to highlight some relevant resources for learning about and responding to the threat.

Bala Neerumalla has written a detailed document for preventing SQL injection in ASP (that is, classic ASP, not ASP.NET).

The Security Vulnerability Research & Defense blog has posted an analysis of the attack, along with guidance recommendations for IT/database admins, web developers, and end users.

Finally, Michael Howard recently wrote a post on the SDL blog on SQL injection defenses required by the SDL.

There's been a lot of renewed interest in web application firewalls lately. In the past, I haven't been a huge fan of WAFs - they always seemed to me to be just a band-aid stuck on the sucking chest wound of insecure code. But I bumped into Jeremiah Grossman at BlueHat, and he raised some good points in defense of WAFs, the most compelling of which was the use of WAFs as emergency first-response tools. Consider the recent mass SQL injection attacks. Fixing these vulnerabilities is going to cost a lot of time and a lot of money. What if, instead of taking the vulnerable sites down while they're getting fixed (or worse, just leaving the sites up and vulnerable while they're getting fixed), the admins put WAFs in front of the sites to keep them up and running while the security holes get patched?

Now, I like this idea a lot. In theory. But in practice, what I'm afraid will happen is that the WAF will get put up as an emergency response, and then the actual code fixes will never get written because they'll take a long time and they'll cost a lot of money and why should we bother because we're already protected from the threat anyway?

Maybe I'm being overly cynical about this. Right here, right now, I'm going to publicly change my stance on WAFs. WAFs can be an excellent defense-in-depth measure and a good emergency first-response tool, but they will never be a replacement for secure code or a secure software development lifecycle. Instead of a band-aid, think of a WAF as an all-star shortstop (or guard, or linebacker, depending on your sport of choice). He'll save you some runs, but you can't put him out on the field all by himself.

Ok, maybe “destroy the internet” is a little harsh. But let’s take a look the impact that implementation of the current W3C working draft for cross domain access would have on browser security. Some people might argue that there’s no more risk from cross-domain XHR than there is from cross-domain Flash or Silverlight, but they would be wrong, for two reasons.

First is a simple matter of increased attack surface. Flash and Silverlight support only the HTTP methods GET and POST. But attacks can be made with methods other than these, and XHR supports any arbitrary method. Attackers could send TRACE requests to probe for cross-site tracing vulnerabilities that defeat HttpOnly cookie protections. Or they could send PUT or DELETE requests to attack WebDAV sites or RESTful web services.

In the second place, cross-domain XHR would increase the potential damage of a successful XSS. Arguably the worst, most damaging types of XSS attacks are the self-propagating XSS web worms. At Microsoft, any “wormable” vulnerability automatically gets our highest security bulletin rating. But for the most part, XSS web worms are confined to a single domain because of the constraints of the same origin policy. Now single-domain worms are bad enough – just ask MySpace – but cross-domain XHR would allow worms to spread across multiple domains, potentially infecting any site with both a stored XSS vulnerability and a permissive cross-domain policy.

Billy Hoffman and John Terrill presented some excellent material on cross-domain web worms at Black Hat last year, but their approach relied on using blind GETs and POSTs to propagate across domains. An attack based on cross-domain XHR would not be limited in this way; the worm could read responses from the targets and vary its attacks accordingly. It could even include logic to defeat multiple-step submission processes like CAPTCHA checks.

I know the cross-domain genie is out of the bottle now with pretty much every browser and RIA framework providing its own cross-domain request mechanism, but let’s try to kill this proposal and nip a future security nightmare in the bud.

As an alternative to the W3C XHR proposal, I like IE8’s XDomainRequest (XDR). XDR only allows GET and POST requests, which is a good reduction in attack surface, but even better is the fact that XDR won’t ever send cookies. This is going to make exploitation of XSRF vulnerabilities via XDR impossible in most cases. Theoretically the web worm issue is still possible, but an attacker would have to find sites that:

a.       Have persistent XSS vulnerabilities,

b.      Have permissive cross-domain policies, and

c.       Don’t use any kind of authentication or session cookies.