Nexpose Vulnerability Database

Or, Browse latest vulnerabilities
Search Hints
  • Try searching for a product or vendor.
  • Only vulnerabilities that match all search terms will be returned.
  • Enclose search terms in double quotes for an exact search.
  • For CVE searches, only enter the CVE-YYYY-XXXX code.

Get Nexpose now

Search vulnerabilities with Rapid7's vulnerability management solution

FREE DOWNLOAD

DOM-based Cross Site Scripting Vulnerability

Severity   CVSS   Published   Added   Modified  
Severe (5) 6.4 (AV:N/AC:L/Au:N/C:P/I:P/A:N) Oct 31, 2006 Oct 31, 2006 Jan 28, 2011

Description:

The website or application is vulnerable to DOM-based cross-site-scripting (XSS). Cross-site scripting allows a malicious attacker to trick your web application into emitting the JavaScript or HTML code of his choice. This malicious code will appear to come from your web application when it runs in the browser of an unsuspecting user.

Whereas traditional XSS takes advantage of vulnerable back-end CGI scripts to directly emit the code into served pages, DOM-based XSS takes advantage of vulnerable JavaScript scripts which execute directly in the user's browser. For example, a the following vulnerable script can be used to launch an XSS attack:

	var loc = document.location + '?gotoHomepage=1';
	document.write('<a href="' + loc + '">Home</a>');

In this case, the JavaScript variable "document.location" is under the direct control of an attacker, but it is being written directly into the document content without escaping. An attacker could construct a URL containing <script> tags in it and trick an unsuspecting user into visiting the vulnerable website. A URL such as http://your_application/index.html?"><script>alert(document.cookie)</script> can be constructed that would cause the script above to write the attacker's malicious script tags directly into the user's document, where they will be executed.

An exploit script can be made to:

  • access other sites inside another client's private intranet.
  • steal another client's cookie(s).
  • modify another client's cookie(s).
  • steal another client's submitted form data.
  • modify another client's submitted form data (before it reaches the server).
  • submit a form to your application on the user's behalf which modifies passwords or other application data

The two most common methods of attack are:

  • Clicking on a URL link sent in an e-mail
  • Clicking on a URL link while visiting a website

In both scenarios, the URL will generally link to the trusted site, but will contain additional data that is used to trigger the XSS attack.

Note that SSL connectivity does not protect against this issue.

Vulnerability Management

Get your solution now

 FREE DOWNLOAD

References:

Solution:

Fix DOM-based Cross Site Scripting Vulnerability

Audit all JavaScript code in use by your application to make sure that untrusted data is being escaped before being written into the document, evaluated, or sent as part of an AJAX request. There are dozens of JavaScript functions and properties which must be protected, including some which are rather non-obvious:

  • The document.write() function
  • The document.writeln() function
  • The eval() function, which executes JavaScript code from a string
  • The execScript() function, which works similarly to eval()
  • The setInterval(), setTimeout(), and navigate() functions
  • The .innerHTML property of a DOM element
  • Certain CSS properties which allow URLs such as .style, .backgroundImage, .listStyleImage, etc.
  • The event handler properties like .onClick, which take JavaScript code as their values

Any data which is derived from data under the client's control (e.g. request parameters, headers, query parameters, cookie names and values, the URL of the request itself, etc.) should be escaped before being used. Examples of user-controlled data include document.location (and most of its properties, e.g. document.location.search), document.referrer, cookie names and values, and request header names and values.

You can use the JavaScript built-in functions encode() or encodeURI() to handle your escaping. If you write your own escaping functions, be extremely careful. Rather than using a "black list" approach (where you filter dangerous characters and pass everything else through untouched), it is better to use a "white list" approach. A good white list approach is to escape everything by default and allow only alphanumeric characters through.

Download Nexpose

Download our vulnerability management solution, Nexpose, for free today. Scan 100% of your infrastructure for vulnerabilities, understand your risk exposure, compare and prioritize your vulnerabilities and verify that they are remediated.