Seen as an end-user issue, cross-site scripting has been ignored for too long. Now attacks are on the rise.
Cross-site scripting (XSS) is one of the most rapidly evolving web application vulnerabilities. At the time of writing, a search for "XSS" on the common vulnerability and exposures database lists around 2,750 separate vulnerabilities.
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.
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 submittinginto 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.
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.
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:
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 email@example.com.