SDL and the XSS Filter, Revisited

SDL and the XSS Filter, Revisited

  • Comments 3

Bryan here. Since Steve called me out in his post on the XSS Filter last week, I feel obligated to clarify my position. I believe that the SDL blog is mainly for development teams; after all, development is the D in SDL. Now, development teams are made up of more than just developers. Development teams include everyone involved in the development process from management on down. But development teams don’t include end users. While XSS Filter is a great, innovative XSS defense technology, there’s really nothing that development teams can do to take advantage of it. Users alone make the decision as to whether they’re going to take advantage of XSS Filter: they either use IE8 and get it, or they use another browser and don’t get it.

 

That being said, there are some interesting implications that XSS Filter and other user-specified defenses have for the SDL. Given that XSS Filter is effective in stopping many types of reflected XSS attacks, should we relax the SDL coding and testing requirements around server-side XSS defense? Of course not. For one reason, the SDL requirements are effective in preventing forms of XSS that XSS Filter does not address, like persistent XSS. For another, not everyone uses IE 8. If we were to relax server-side requirements now, we would jeopardize IE 7 users, as well as Firefox, Safari, Opera, Chrome, and all the other browsers’ users.

 

But what if these conditions change? What if David and others on the security science team develop a new version of XSS Filter that’s effective against all forms of XSS? And what if all the browser manufacturers develop similar technology and implement it in their browsers? (Or alternatively, what if every user on the planet switches to IE 8? ) Then would we relax the server-side XSS defense requirements? Yes, we probably would.

 

I’ve always been more of a security pragmatist than a security purist. While the security purist in me would want to keep the requirements around to prevent developers from falling back into bad habits, the security pragmatist in me would recognize that development teams have a limited amount of bandwidth, and making them defend against rare, obscure vulnerabilities is a poor use of their time. Unfortunately, we’re not likely to face this scenario any time in the near future, so the SDL will continue to require server-side input validation and output encoding to prevent XSS attacks.

 

We now return you to your regularly scheduled development-focused blog.

Comments
  • PingBack from http://www.easycoded.com/sdl-and-the-xss-filter-revisited/

  • Surely the pragmatic approach would be to not trust the browser facilities at all. After all ValidateRequest can be bypassed as new XSS exploits come out. I'm somewhat shocked that the SDL would relax if all browsers filtered known XSS vectors at the time of their release.

    You were kidding. Right?

  • Actually, no, I wasn’t kidding. If there was near-universal adoption of browser technology with a near-perfect capability of stopping all forms of XSS (which is not likely to happen any time soon) then I would be OK with reducing or removing the server-side requirements. If new exploit vectors were to be discovered later then we would reinstate the requirements.

    Part of the reason the SDL has been successful is that it is practical and reasonable with regards to the time demands it makes on development teams. If we were to treat security as an absolute, and force teams to spend time mitigating any possible vulnerability, known or unknown, that might theoretically exist somewhere in their product, then we would never ship a single product! Security is in many ways a balancing act and if we ever do get to the point where browser technology defeats XSS, I’ll be the first one to celebrate V-XSS Day by tearing out the SDL requirements.

Page 1 of 1 (3 items)
Leave a Comment
  • Please add 3 and 5 and type the answer here:
  • Post