Common Misconceptions in Web Application Security, Part 2

In Part 1 of this thread, I mentioned how there were a number of people that had misconceptions about Web Application Security, especially Cross-site scripting (XSS). Last week, a blog called Neosmart posted an article on why XSS is not a vulnerability. I found this to be a perfect example of the largest and most dangerous misconceptions in Web Application Security.

"The problem isn’t so much in the attack itself as much as it is in the usage of the term. XSS is not a real security vulnerability in a product or script since it does not directly result in the loss of data integrity, but rather can be used as a tool in social engineering attacks and can never compromise the security of a server/host under any conditions nor that of an end-user on its own."

XSS is possible due to the lack of input validation on a web application. This allows an attacker to place malicious script (not only JavaScript, but also VBScript) in a page that will be returned to the user. The danger occurs because the user trusts that the webpage only contains content from the original website. The user doesn’t expect that page to contain script that would exploit them.

The list of possible payloads of a XSS attack are extensive. Common perception is that XSS attacks do annoying things like popping up ads or messages in the users browser. While these annoying payloads do occur, XSS exposes the user to numerous other dangers such as:

- Session Hijacking
- Phishing Scams
- Information/Identity Theft
- Denial of Service attacks against user’s browser
- Denial of Service attacks against any website
- Facilitate execution of other vulnerabilities
- Self propagating worms that manipulate large systems (i.e. MySpace.com worm, Yahoo’s Yamanner worm)

The article goes on to make the claim the XSS is something that is fixed in the browser.

"Even that is inconsequential however, because today all modern browsers protect against XSS attacks in one form or the other. To test that, our testers headed off to OSVDB and searched for “XSS” “pops cookie” and “document.cookie,” which are the words most often associated with XSS vulnerabilities. Although the results varied from one browser to the other and from one build to the next, on average 60% - 70% of the XSS vulnerabilities that were present and “functional” in the “last generation” of browsers (Firefox < = 1.0, Opera 8, Internet Explorer 6) didn't work in the "new generation" of browsers (Firefox 2.0-3.0 builds, Opera 9, Internet Explorer 7)."

This is statement shows there is confusion about how XSS works because browsers can't be "cured" of XSS. The vulnerability isn't in the browser! It exists in the improper input validation in the server's web application. The browser only follows directions by running script found in the page with basic security restraints to stop the script from doing blatantly harmful items (accessing the file system, reading inside a remote iframe, etc...). The attacks possible with XSS can not be stopped at the browser level stopped because script has legitimate, non-malicious purposes. Furthermore, legitimate script looks exactly like malicious script. Both make requests for images and more script, possible from other hosts. Both hook events like mouse movement or keyboard activity. Both read and modify the HTML of the page. Both access and manipulate web form values and cookies. Both can use Ajax request to make hidden requests using a user’s credentials without there knowledge. From the browser’s point of view, script is script, regardless of whether it is script from a XSS attack for not.

What should you take away from all of this? Simple. Cross Site-scripting is a security vulnerability. XSS can have a number of very dangerous payloads from annoying popups to session hijacking to complex, self propagating malware that uses Ajax. XSS occurs because web applications fail to validate input properly, allow attackers to submit HTML and JavaScript. XSS is also a 100% preventable problem. You should understand how it works and how you to can design secure applications.

Comments
| ‎07-04-2006 11:42 PM
Good explanation of real XSS threats.  I was initially disappointed by the amount of attention given to this guy's fairly erroneous claims.  However, I hope that the resulting discussions helped to actually increase awareness among developers and other professionals.
| ‎10-17-2006 02:30 PM
XSS is not a result of a lack of input validation, it's a result of a lack of output filtering. That script might not come from the user, it could come from a B2B connection, a db administrator putting stuff into the DB, or out of thin air. It only becomes "script" or injected code when it's displayed. There's nothing inherently wrong with putting in script - there IS a problem with outputting script I didn't intend to.
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.