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:
- OWASP Encoding Project available at Google Code
- The HTML Purifier or Htmlawed for PHP
- Anti-XSS Class for .net applications
- AntiSamy API for .Net
- XSS-HTML-Filter for Java
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:
How To: Prevent Cross-Site Scripting in ASP.NET
The Cross-Site Scripting (XSS) FAQ
Quick Security Reference: Cross-Site Scripting (XSS)
Testing Your Web Applications for Cross-Site Scripting Vulnerabilities