Cross Site Scripting Flaws

Definition:

Cross-site scripting, better known as XSS, is in fact a subset of HTML injection. XSS is the most prevalent and pernicious web application security issue. XSS flaws occur whenever an application takes data that originated from a user and sends it to a web browser without first validating or encoding that content.

XSS allows attackers to execute scripts in the victim’s browser, which can hijack user sessions, deface web sites, insert hostile content, conduct phishing attacks, and take over the user’s browser using scripting malware. The malicious script is usually JavaScript, but any scripting language supported by the victim’s browser is a potential target for this attack.

The web application can be used as a mechanism to transport an attack to an end user's browser. A successful attack can disclose the end user’s session token, attack the local machine or spoof content to fool the user.

Protection:
The best protection for XSS is a combination of "white list" validation of all incoming data and appropriate encoding of all output data. Validation allows the detection of attacks, and encoding prevents any successful script injection from running in the browser.

Preventing XSS across an entire application requires a consistent architectural approach:

• Use a standard input validation mechanism to validate all input data for length, type, syntax, and business rules before accepting the data to be displayed or stored. Reject invalid input rather than attempting to sanitize potentially hostile data.

• Ensure that all user-supplied data is appropriately entity encoded (either HTML or XML depending on the output mechanism) before rendering, taking the approach to encode all characters other than a very limited subset.

• Specify the output encoding (such as ISO 8859-1 or UTF 8). Do not allow the attacker to choose this for your users .

• Do not use "blacklist" validation to detect XSS in input or to encode output. Searching for and replacing just a few characters ("<" ">" and other similar characters or phrases such as “script”) is weak and has been attacked successfully.

• Make sure that your application does not decode the same input twice. Such errors could be used to bypass white list schemes by introducing dangerous inputs after they have been checked

.Net Overview:
By default, ASP.NET versions 1.1 and 2.0 request validation detects any HTML elements and reserved characters in data posted to the server. This helps prevent users from inserting script into your application. Request validation checks all input data against a hard-coded list of potentially dangerous values. If a match occurs, it throws an exception of type HttpRequestValidationException.

[ConfigurationPropertyAttribute("validateRequest", DefaultValue = true)]
public bool ValidateRequest { get; set; }

You can set request validation from web.config file for all pages in application.


This property avoids most of attacks, but you should consider more.

Potentially Dangerous HTML Tags
While not an exhaustive list, the following commonly used HTML tags could allow a malicious user to inject script code:

applet>
body>
embed>
frame>
script>
frameset>
html>
iframe>
img>
style>
layer>
link>
ilayer>
meta>
object>

An attacker can use HTML attributes such as src, lowsrc, style, and href in conjunction with the preceding tags to inject cross-site scripting. For example, the src attribute of the tag can be a source of injection.

To prevent cross-site scripting in .NET Web Applications, perform the following steps:

1. Check That ASP.NET Request Validation Is Enabled
2. Review ASP.NET Code That Generates HTML Output
3. Determine Whether HTML Output Includes Input Parameters
4. Review Potentially Dangerous HTML Tags and Attributes
5. Evaluate Countermeasures

More information: http://msdn.microsoft.com/en-us/library/ms998274.aspx