AppSec Blog

AppSec Blog

Ask the Expert - Jim Manico

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?

One of the best XSS prevention guides is the OWASP XSS Prevention Cheat Sheet. Over 500,000 hits and counting.

For advanced practitioners there is the OWASP DOM XSS Prevention Cheatsheet as well.


4. When is XSS going to be solved for good, or will we have to keep on living with the risk of XSS exploits for a long time?

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.

2 Comments

Posted November 26, 2012 at 10:57 PM | Permalink | Reply

Ian Lyons

Completely in agreement. Until CSP is fully implemented and supported, there's simply too much attack surface to make full protection against XSS truly feasible.

Posted December 10, 2012 at 3:25 PM | Permalink | Reply

Antony

To solve the XSS issue, we need to look at the root cause which is the poor security design of current browsers.

This is a very comprehensive guideline for CSP and other browser-based security controls from Australia Gov.

http://dsd.gov.au/publications/csocprotect/protecting_web_apps.htm

Post a Comment






Captcha

* Indicates a required field.