Bryan Sullivan here, making a guest appearance here away from my usual home on the SDL blog.
It’s great to see BlueHat showing some love to the Web app sec community. I’m thrilled that BH is expanding on its tradition of inviting some of the best and brightest Web app sec minds by dedicating the entire morning to layer 7 issues. This is a great demonstration of how important this space really is to us.
“Bah,” you say, “inviting speakers to BlueHat means nothing! What do you do for your own Web apps? Actions speak louder than words!” I couldn’t agree more. Security policy for our MSN/Live sites is covered by the SDL, so let’s take a look at some of the ingredients in the SDL recipe.
I don’t think I’m giving away any big internal Microsoft secrets by telling you that the top security issue for our online properties is cross-site scripting (XSS). By a substantial margin, XSS is our most commonly reported vulnerability. This only makes sense: it’s incredibly easy for Web developers to accidentally write XSS vulnerabilities into their code, and the application behavior responsible for XSS (reflecting user input back to that user, or storing and displaying that input to other users) is incredibly common too. So, what does the SDL have to say about XSS?
In the latest internal version of the SDL (4.0), there are no fewer than five separate requirements dealing with XSS issues. The SDL covers appropriate implementation practices (such as validating user input and encoding output) and also specifies tools that can be used during the verification process to find XSS vulns that sneak through the cracks. At last count, there were at least nine of these tools developed by different teams throughout the company. Most of these are internal-only, but some, like the excellent Anti-XSS output encoding library developed by the ACE team, are available to everyone.
So with five SDL process requirements, nine tools and countless books and Web sites that document the problem, why do we still have XSS? Why haven’t we eradicated it like smallpox, contained only on one machine somewhere in building 99, kept around as kind of an intellectual curiosity or a reminder of a less-enlightened past? The reason is that neither the requirements, nor the tools, nor the books or Web sites are perfect. None of the tools, internal or public, are particularly good at detecting certain rare types of XSS such as type-0 or DOM-based XSS. And despite everyone’s best intentions, sometimes the processes are not followed 100% correctly. But a better question to ask than “Are Microsoft Web sites perfectly secure?” is “Are Microsoft Web sites getting more secure?” and the answer is yes, they are.
There is a direct analogy between XSS in Web sites and buffer overflows in Windows. We still haven’t completely eliminated buffer overflows from Windows, and there are way more SDL requirements and tools for detecting and removing buffer overflows than there are for XSS. But Windows is much, much more secure now than it was before the SDL, and our Web apps are too.
I would love to talk about some other Web app sec issues besides XSS, issues like cross-site request forgery and JSON hijacking. Even more I would love to talk about what kinds of tools and processes we’re developing in the SDL to address these issues. But Katie won’t let me have any more space on the BlueHat blog - I’ll have to continue on the SDL blog. Keep watching over there.
-Bryan