Steve Lipner here. When the Internet Explorer team posted the announcement about the XSS Filter feature in IE8 I asked some other members of the SDL blog team “why aren’t we talking about the new XSS Filter feature on the SDL blog?” Bryan and Jeremy said something like “that’s a mitigation that only applies to specific clients and a subset of attacks”. So we didn’t cross-reference IE’s XSS Filter post on the SDL blog at the time. Instead, I agreed to write a subsequent post about the relationship of XSS Filter to the SDL and to the ways that our SDL and security science teams think about improving product security.
For those of you who aren’t familiar with XSS Filter, a brief summary is that it is a client-side defense against reflected cross-site scripting (XSS) attacks. It works by recognizing that reflected XSS attacks inject script into the string that the browser sends to the targeted web server. If the server doesn’t neuter or strip out the injected script, it gets sent back to the browser and executed in the context of the target web page. Bad things then happen. At a high level, XSS Filter remembers the string that the browser sent to the server, and looks at the server’s response to see if any of the script was actually in that string. If it was, then XSS Filter decides that it got there because it was injected by an XSS attack and blocks the script from executing. The rest of the web page renders as usual. This is a vastly oversimplified sketch of XSS Filter – for details, see the post by David Ross, inventor of XSS Filter on the Security Vulnerability Research and Defense blog.
So what does XSS Filter have to do with the SDL? Well, for almost nine years, since XSS was first discovered at Microsoft, we’ve been trying to figure out effective ways to reduce vulnerability to XSS attacks. Our focus has been on improving the ways that web page developers code their pages, and we’ve developed a lot of tools and techniques for making web content safer from XSS attacks and for detecting XSS vulnerabilities in live pages. The SDL requires the use of many of these tools and techniques, and we’re sure we’ve prevented a lot of XSS vulnerabilities from being introduced into Microsoft web pages as a result.
But while we identify (and the SDL requires) measures that allow developers to avoid classes of vulnerabilities, we also look to identify more sweeping solutions that can either 1) eliminate classes of vulnerabilities, 2) reduce their severity, or 3) reduce the likelihood of attacks being successful. The process usually starts from deep understanding of a class of vulnerabilities and attacks, and then we broaden defenses from there. In the case of XSS Filter, David’s years of work researching XSS led him to come up with an approach that blocks many of the most common vulnerabilities to reflected attacks found on the web today. The solution is compatible with existing web pages (doesn’t “break the web”) and thus we were able to enable it by default for users of Internet Explorer 8. Because it’s a client-side mitigation, it will help protect users from attacks even though the sites they visit may be vulnerable to XSS.
Our work on buffer overrun defenses follows a somewhat similar pattern – we started by prescribing coding techniques, banning the use of some APIs, and building tools that detect coding constructs that look like buffer overruns. As we gained a deeper understanding of how buffer overruns can be exploited, we enhanced the /GS compiler flag and added ASLR in a quest to cause classes of exploits to fail even if a buffer overrun remains. We’re not yet close to eliminating the SDL requirements for use of tools and coding techniques, but the SDL also requires the use of the mitigations to reduce the severity of vulnerabilities that slip past. Will we ever get to the point where the mitigating technologies are so strong that we can relax the coding requirements? Maybe not, but we will continue to introduce technologies that reduce the chances of a successful attack.
Similarly, in the case of XSS, even after IE8 ships, the SDL will continue to require the use of safe web site coding practices and tools such as the Anti-XSS library both to protect users of browsers other than IE8 and to provide protection in recognition of the fact that XSS Filter is a mitigation or defense in depth rather than a complete solution. But we’ll also be keeping our eyes open (and doing active research) in the quest for an even more effective defense – whether client or server side – that eliminates XSS for good.
This post is a little far afield from the normal content of the SDL blog, but I thought it was important to provide a picture of the role of security science and security research in defining SDL requirements and in making major improvements in software security. You can read more about our work in security science in the Security Vulnerability Research and Defense blog.
I’ve been catching up on various security-related articles that I’ve been meaning to read, and the following article was on the list http://www.itnews.com.au/News/73635,google-shares-its-security-secrets.aspx about Google’s “security secrets.” Quoting from the article:
“In order to keep its products safe, Google has adopted a philosophy of 'security as a cultural value'. The programme includes mandatory security training for developers, a set of in-house security libraries, and code reviews both by Google developers and outside security researchers."
I think it is great that Google has a security program they are willing to talk about and I could not agree more with the ‘security as a cultural value’ philosophy. But isn’t there something really fundamental missing here? Design? There is a lot more to software engineering other than coding and testing. The SDL has a very large set of implementation-related requirements, but there are many design-related requirements also.
Computer security experts have known since the early 1970s that you have to get the design right; and our experiences with the SDL over the last 5 years have taught us that you need to consider security and privacy (but remember, you have to ship too!) very early in the design phase and have a consistent end-to-end process if you truly hope to reduce vulnerabilities and create more secure software. This is how the SDL is helping to create ‘security as a cultural value’ at Microsoft.
We’ve seen a general trend downward in security vulnerabilities in Microsoft products, and the IBM X-Force 2008 mid-year report backs the assertion that we’re making progress; according to the report Microsoft’s share of total vulnerabilities decreased from 3.7% in 2007 (1st place) to 2.5% (that’s 2.5% for all Microsoft products; a more appropriate comparison might be Windows vs Linux vs Mac OSX, or SQL Server vs Oracle vs DB2) in the first 6 months of 2008 (3rd place.) This is an encouraging signal that the SDL is working on a large scale… of course, it might also show that vulnerability researchers are moving to easier targets, which, to me shows the SDL is working too. What do you think?