The main reason for this is that it is often overlooked and underestimated by application developers. During penetration tests over the past year, we found that more than 80 per cent of web applications were vulnerable to XSS.
XSS can be defined as the execution of arbitrary client-side code (typically JavaScript/HTML), which has been injected by an attacker onto a web page. It exists wherever input from a user has been accepted and is echoed to an HTML page without being encoded.
Consider a typical website search using a URL-passed parameter query. A simple test is to enter a dynamic HTML into an input form. You should only do this against your own site.
Try submitting into the search form, with the <> signs. In many cases, there are "no search results", but you will see "0 search results" scrolling from right to left across the screen. This would indicate that the page was vulnerable to XSS as one has successfully injected an HTML tag into the results page.
There are two types of XSS: non-persistent and persistent. The first is the most common and is typically exploited through a phishing attack by emailing the victim a link. To succeed, an attacker has to construct a valid list of email addresses for site users, create a message that eludes filtering systems and appear genuine.
Even then, the system users still have to "buy into" the validity of the email and click on the link to executes the malicious JavaScript/HTML.
The second category is far more serious, because the attacker does not have to rely on click-thru. Imagine a news site that allows users to post comments. If an attacker can post an entry including arbitrary JavaScript/HTML, there is the opportunity to create a persistent XSS vulnerability. All a victim has to do is to view the news story.
The boundary for the security implications of XSS is constantly being redrawn. There currently exists proof-of-concept code for keylogging and even internet worms.
Other research is focusing on finding "universal XSS" issues using common browser plug-ins. Take, for example, the Adobe Acrobat PDF plug-in issue where any PDF hosted on a website is vulnerable to XSS. Imagine you are sent an email by a co-worker containing a link to a PDF document on a trustworthy website.
Once you click, XSS executes on your local machine. The vulnerability exploits the plug-in's ability to execute JavaScript commands passed in the URL. Syntax might look like this: http://www.domain.com/test.pdf#a=javascript:alert('XSS'), which would simply pop up an alert in a dialog box, but would indicate that the browser plug-in was vulnerable.
Fortunately, there's a patch available through Acrobat's auto-update feature. One way to test if your current configuration is vulnerable is to open one of the demonstration files that are part of a default Acrobat install. Paste the following in a browser as a test, which will be safe as you're executing the script locally and are in control of the command:
C:\Program Files\Adobe\Acrobat 7.0\Resource\ENUtxt. pdf#a=javascript:alert('XSS').
If you get a dialog box pop-up with 'XSS', you need that patch. If you don't have Acrobat v7, substitute your correct version number in the path above.
XSS issues are usually simple to prevent. First, all web application developers need to be made aware of the issue. Second, all user input should be treated as suspect and checked to match the expected input format.
Third, any user input that is being echoed back to the screen, whether it is coming from a database or straight from an HTTP parameter, should be HTML-encoded before being returned. And finally, bear in mind XSS attacks are evolving fast, so keep up to date on the topic through trusted internet resources.
- Ken Munro, managing director of SecureTest. He can be contacted at ken.munro@securetest.com.