Cross-site scripting vulnerability penetration testing

Russell Dean Vines discusses how to test a Web application for cross-site scripting (XSS) vulnerabilities, how to perform penetration testing for XSS and what type of code would exhibit XSS threats.

I would like to know how to test a Web application for cross-site scripting (XSS) vulnerabilities, how to perform...

penetration testing for such vulnerabilities and what type of code would exhibit such threats.

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.

XSS attacks usually come in the form of embedded JavaScript; however, any embedded active content is a potential source of danger, including ActiveX, VBscript and Flash.

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:

  1. Sample web request code could be:

  2. The HTML returned by the server after making this request includes the code:

    "<h1>Section Title</h1>"
  3. 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:

XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript.

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.

Dig Deeper on Cybersecurity risk assessment and management