Jim Manico is the VP of Security Architecture for WhiteHat Security, a web security firm. Jim is a participant and project manager of the OWASP Developer Cheatsheet series. He is also the producer and host of the OWASP Podcast Series.
1. Although SQL Injection continues to be one of the most commonly exploited security vulnerabilities in the wild, Cross Site Scripting (XSS) is still the most common security problem in web applications. Why is this still the case? What makes XSS so difficult for developers to understand and to protect themselves from?
Mitigation of SQL Injection, from a developer point of view, is very straight forward. Parameterize your queries and bind your variables!
Unfortunately, mitigating XSS can be very difficult. You need to do contextual output encoding in 5 or more contexts as you are dynamically creating HTML documents on the server. You also need validate untrusted HTML that is submitted from widgets like TinyMCE. You also need to parse JSON using safe APIs such as JSON.parse. And then you need to deal with the very challenging issue of DOM Based XSS, a challenge that even tools have a problem discovering. And this problem is getting worse in the era of rich internet application development.
2. What’s the real risk of XSS – what can attackers do if they find an XSS vulnerability? How seriously should developers take XSS?
Attackers can use XSS to set up keyloggers, deface a website, steal session cookies or other sensitive data, redirect the user to an untrusted website, and circumvent CSRF protections … just to get started. If developers want to build secure web applications they NEED to take XSS defense seriously. And it can be quite difficult to accomplish this – especially for modern RIA/AJAX applications.
3. Where can developers and testers and security analysts go to understand XSS? What tools can people use to prevent XSS today and where can they find them?
For advanced practitioners there is the OWASP DOM XSS Prevention Cheatsheet as well.
If developers are forced to manually output encode ever variable, I feel XSS will always be with us.
But there is hope in standards.
Content Security Policy 1.1 is a W3C draft which promised to make XSS defense a great deal easier on developers. There is only mixed browser support for CSP today, but in 2-3 years when all browsers full support the CSP standard, there will be a browser-based highly effective AntiXSS methodology available to all.
I’m also fond of the HTML5 iframe sandboxing mechanism for XSS defense.