AppSec Blog

AppSec Blog

Top 25 series - Rank 1 - Cross Site Scripting

My honor to kick off with the first programming error on the Top 25 list. Ranked number 1 on the list is the Cross Site Scripting issue.

Cross Site Scripting like many other Web security problems is caused by simple flaws related to user input but the potential attack scenarios can be diverse and the fix is not easy. The fundamental flaw of Cross Site Scripting is malicious user input got sent from the server to the victim's browser, all within the HTTP response that the browser is ready to "render" on screen for the user. The browser cannot distinguish between the real site content and user input that actually "means something malicious". The malicious code gets "rendered" by the browser as HTML or scripting command while it should just be a plain looking text string on the screen.

One often ignored fact in Web security, if I control your browser, I win. By injecting malicious content to the victim's browser, an attacker can effectively use the awesome power of Javascript to alter content of the current page or redirect the user else where on the Web.

Imagine a log in page where the user can type in user name and password. When you type in user name "Jason" and a password then press enter, the website might respond with "Invalid login information - username: Jason". Now, think maliciously for a sec, what if the input is <img src="http://sans.org/evil.jpg">? When the login error message get displayed, the message becomes "Invalid login information - username: <img src="http://sans.org/evil.jpg">" The <img> tag gets rendered (or executed) by the browser and this is how cross site scripting works. In specific, this is a reflected cross site scripting attack.

There are three types of XSS - reflected, persistent and DOM based. Out of the three types, reflected is the most common.

XSS vulnerabilities are everywhere, the site xssed.com documented many of these cases. All the recent major political election campaigns had some associated XSS attacks.

With the vulnerabilities so wide spread, how do we fix it? Just filter out that <> characters? Nah... Wrong answer. Effective XSS prevention requires both input validation and output encoding.

Input validation get rid of all the noise and reduce overall security exposure but input validation is hard, so hard that it is impossible to completely filter out XSS. Check into XSS cheat sheet and you will know why. Another thing thats really killing input validation is the increasing sources of information in web applications. With the mashup Web model, you have sources that you don't even know you have and absolutely no idea whether they are fully validated or not. Output encoding comes to the rescue. Before output, all those <> and offending characters are mapped to another representation so the browser knows to display them on screen instead of executing them.

Output encoding sounds easy but you need to do it right and do it consistently in order for it to work. As a start, set the page encoding using meta tag, this ensuring the browser is displaying the encoding you intend to deal with. The actual encoding is context specific, you have to do the right encoding for different part of the HTML document. The XSS Prevention Cheat Sheet has detailed instruction on what to do where in the HTML page. Rule #1 and Rule #2 in the cheat sheet will serve you for 95% of the situations but be aware there are 5% of situations where the other rules applies. Various development framework have different functions or API to handle the output encoding process.

Consistency is another big factor in wining the XSS game. Make sure all developers have the same understanding and preferably use the same common API to deal with this complex output issue. There are projects like OWASP ESAPI that provide usable API to take the guess work out of the developer's hand.

Since one of the most common goal of XS attacks are to steal session cookie. The HTTPOnly cookie flag was developed specifically to cut down on this risk. However, keep in mind that it only cut down on the risk but is not an all encompassing solution.

Hope you enjoyed reading this post, it's a long post but as 1st place in the Top 25 list, I think XSS deserve this much verbiage. We will try to keep the length reasonable for the lower ranking issues. :-) Feedback always welcomed.

4 Comments

Posted February 22, 2010 at 2:27 PM | Permalink | Reply

Andre Gironda

Is reflected XSS the "most" common? Why? Where are statistics to back this up?

Do rules 1 and 2 from the OWASP XSS Prevention sheet really remove 95 percent of XSS vulnerabilities? Why? Where are statistics to back this up?

Your sentence, "Since one of the most common goal of XS attacks are to steal session cookie" contains some errors.

What is the difference between XHTML and HTML? By "HTML" do you sometimes really mean "XHTML" instead? Thanks!

Posted February 23, 2010 at 12:19 AM | Permalink | Reply

Wireghoul

XSS is one tricky beast, there are so many vectors. I found this one right here...you might want to fix that

http://blogs.sans.org/appsecstreetfighter/?s=%22%29;alert%28document.cookie%29;eval%28%22

Posted April 06, 2010 at 3:41 PM | Permalink | Reply

Top 25 Series &#8211; Summary and Links

[...] &#8211; Cross-Site Scripting (XSS) 2 &#8211; SQL Injection 3 &#8211; Classic Buffer Overflow 4 &#8211; Cross-Site Request Forgery [...]

Posted August 11, 2010 at 11:24 AM | Permalink | Reply

Seven Security (Mis)Configurations in Java web.xml Files

[...] the cookie cannot be accessed via client side scripts. This helps mitigate some of the most common XSS attacks. Just like the &#8220;Secure&#8221; flag, older versions of the Servlet specification [...]

Post a Comment






* Indicates a required field.