Dynamic Web sites suffer from a threat that static Web sites don't, called cross-site scripting (XSS). An XSS vulnerability is created by the failure of a Web-based application to validate user-supplied input before returning it to the client system.
The XSS flaw exploit can cause serious problems -- including accessing the user's session cookie -- thereby allowing an attacker to hijack the session and take over the account. It can also install malware, redirect the browser and disclose sensitive information.
XSS has been around for quite awhile. A simple code example of an XSS vulnerability is as follows:
- Sample web request code could be:
- The HTML returned by the server after making this request includes the code:
- The user input passed to the "title" query string parameter was probably placed in a string variable and inserted by the Web application into an <h1> tag.
By providing the input the attacker controls the HTML. If the site is not filtering input server-side, an attacker could inject code by breaking out of the <h1> tag, such as:
Therefore, the HTML output from the attacker's input would look like:
As far as testing for XSS vulnerabilities, automated scripts can be used, but the testing is most typically performed manually. Microsoft has a good piece on how to test for XSS using various tools and a reporting methodology.
Nessus, Nikto and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.
The best way to protect a Web application from XSS attacks is ensure that your application performs validation of all headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters) against a rigorous specification of what should be allowed.
To learn more about penetration testing, visit the Penetration Testing Project Guide.
This was first published in April 2007