After SQL injection, the second most common type of attack against web sites and web applications is cross-site scripting also known as XSS. Often these are caused when an attacker enters some client side script code such as JavaScript or VBScript into a data entry form. This code will then be displayed in other users’ browsers where it would be executed causing the browser to run a malicious program from another site, redirect the browser to another web page or steal a user’s cookie and thus allowing an attacker to gain access to a protected site. XSS attacks could also come from a user’s cookie, user supplied cascading style sheet code, an XML web service or a JSON script. They could be concealed in an innocent looking e-mail, in comments from a user review/feedback site, in an instance message conversation or in links contained on popular social networking or social bookmark sites.

XSS intrusions can fall into one of three categories: non-persistent vulnerabilities, persistent vulnerabilities and DOM-based vulnerabilities. Non-persistent vulnerabilities are short lived; once injected into a page they are rendered briefly on the site but they are never stored on the site’s server. Persistent vulnerabilities, on the other hand, because they become written to a file or stored in a database through forums, guest books or comment pages and can remain active on a site till they are detected and removed. DOM-based vulnerabilities make use of the dynamic content capacities of modern web browsers to accomplish their exploits.

The remedies for dealing with cross-site scripting include:

  • Not trusting user supplied input (including cookies) – all user input must be validated and escaped (rendered safe)
  • Proper encoding of HTML control characters, JavaScript, CSS, URLs to render them harmless before they are displayed in a browser
  • Implementing cookie security (as Robert Hafner explains in his article, How to Create Totally Secure Cookies: limit the domain and path for accepting cookies, set them as HttpOnly , use SSL and never store confidential data in cookies)
  • Or disabling the use of client site scripts

There are a number of security libraries available for encoding user input:

Web users can also take steps to prevent becoming a victim of cross-site scripting by installing browser addons that disable scripts on all but trusted sites. NoScript is a browser addon for FireFox; Chrome and Opera users can use an addon called NotScripts.

For more information see:

Prevent Cross-Site Scripting

Cross-site Scripting (XSS)

How To: Prevent Cross-Site Scripting in ASP.NET

The Cross-Site Scripting (XSS) FAQ

ASP.NET Cookies Overview

Bullet Proof Cookies

Quick Security Reference: Cross-Site Scripting (XSS)

Testing Your Web Applications for Cross-Site Scripting Vulnerabilities