Cross-Site Scripting


XSS attacks exploit vulnerabilities in Web page validation by injecting client-side script code. This code is subsequently sent back to an unsuspecting user and executed by the browser. Because the browser downloads the script code from a trusted site, the browser has no way of identifying that the code is not legitimate, and Internet Explorer security zones provide no defense. XSS attacks also work over HTTP or HTTPS (SSL) connections. One of the most serious exploits occurs when an attacker writes script to retrieve the authentication cookie that provides access to the trusted site and posts it to a Web address known to the attacker. This allows the attacker to spoof the legitimate user's identity and gain illicit access to the Web site.

Use the following countermeasures to prevent XSS attacks:

  • Validate input

  • Encode output

Validate Input

Validate any input that is received from outside your application's trust boundary for type, length, format, and range using the various techniques described previously in this chapter.

Encode Output

If you write text output to a Web page and you do not know with absolute certainty that the text does not contain HTML special characters (such as < , > , and & ), then make sure to pre-process it using the HttpUtility . HtmlEncode method. Do this even if the text came from user input, a database, or a local file. Similarly, use HttpUtility.UrlEncode to encode URL strings.

The HtmlEncode method replaces characters that have special meaning in HTML to HTML variables that represent those characters. For example, < is replaced with &lt and " is replaced with &quot . Encoded data does not cause the browser to execute code. Instead, the data is rendered as harmless HTML.

 Response.Write(HttpUtility.HtmlEncode(Request.Form["name"])); 

Data-Bound Controls

Data-bound Web controls do not encode output. The only control that encodes output is the TextBox control when its TextMode property is set to MultiLine . If you bind any other control to data that has malicious XSS code, the code will be executed on the client. As a result, if you retrieve data from a database and you cannot be certain that the data is valid (perhaps because it is a database that is shared with other applications), encode the data before you pass it back to the client.

Sanitizing Free Format Input

If your Web page includes a free-format text box, such as a "comments" field, in which you want to permit certain safe HTML elements such as <b> and <i> , you can handle this safely by first pre-processing with HtmlEncode , and then selectively removing the encoding on the permitted elements, as follows :

 StringBuilder sb = new StringBuilder(HttpUtility.HtmlEncode(userInput)) ; sb.Replace("&lt;b&gt;", "<b>"); sb.Replace("&lt;/b&gt;", "</b>"); sb.Replace("&lt;i&gt;", "<i>"); sb.Replace("&lt;/i&gt;", "</i>"); Response.Write(sb.ToString()); 

Defense in Depth Countermeasures

In addition to the techniques discussed earlier, use the following countermeasures for defense in depth to prevent XSS:

  • Set the correct character encoding .

  • Use the ASP.NET version 1.1 validateRequest option .

  • Install URLScan on your Web server .

  • Use the HttpOnly cookie option .

  • Use the <frame> security attribute .

  • Use the innerText property .

Set the Correct Character Encoding

To successfully restrict what data is valid for your Web pages, it is important to limit the ways in which the input data can be represented. This prevents malicious users from using canonicalization and multi-byte escape sequences to trick your input validation routines.

ASP.NET allows you to specify the character set at the page level or at the application level by using the <globalization> element in Web.config. Both approaches are shown below using the ISO-8859-1 character encoding, which is the default in early versions of HTML and HTTP.

To set the character encoding at the page level, use the <meta> element or the ResponseEncoding page-level attribute as follows:

 <meta http-equiv="Content Type"        content="text/html; charset=ISO-8859-1" /> 

OR

 <% @ Page ResponseEncoding="ISO-8859-1" %> 

To set the character encoding in Web.config, use the following configuration:

 <configuration>    <system.web>       <globalization           requestEncoding="ISO-8859-1"          responseEncoding="ISO-8859-1"/>    </system.web> </configuration> 
Validating Unicode Characters

Use the following code to validate Unicode characters in a page:

 using System.Text.RegularExpressions; . . . private void Page_Load(object sender, System.EventArgs e) {   // Name must contain between 1 and 40 alphanumeric characters   // together with (optionally) special characters '` for names such   // as D'Angelo   if (!Regex.IsMatch(Request.Form["name"], @"^[\p{L}\p{Zs}\p{Lu}\p{Ll}]{1,40}$"))     throw new ArgumentException("Invalid name parameter");   // Use individual regular expressions to validate other parameters   . . . } 

The following explains the regular expression shown in the preceding code:

  • {<name>} specifies a named Unicode character class.

  • \p{<name>} matches any character in the named character class specified by {<name>} .

  • {L} performs a left-to-right match.

  • {Lu} performs a match of uppercase.

  • {Ll} performs a match of lowercase.

  • {Zs} matches separator and space.

  • {1,40} means no less that 1 and no more than 40 characters.

  • {Mn} matches mark and non-spacing characters.

  • {Zs} matches separator and space.

  • * specifies zero or more matches.

  • $ means stop looking at this position.

Use the ASP.NET validateRequest Option

The validateRequest attribute is a .NET Framework version 1.1 feature. This attribute is set to true by default on the <pages> element in Machine.config. It instructs ASP.NET to examine all data received from the browser for potentially malicious input, for example, input that contains <script> elements. ASP.NET examines input received from HTML form fields, cookies, and query strings. .NET Framework version 1.0 does not provide any equivalent functionality, but the IIS URLScan Internet Server Application Programming Interface (ISAPI) filter can perform a similar job. You can also apply the setting to each page using the @ Page tag, as follows:

 <% @ Page validateRequest="True" %> 

Install URLScan on Your Web Server

URLScan is an ISAPI filter that is installed when you run the IISLockdown tool. This helps mitigate the threat of XSS attacks by rejecting potentially malicious input. For more information about IISLockdown and URLScan, see Chapter 16, "Securing Your Web Server."

Note  

IIS 6.0 on Windows Server 2003 has functionality equivalent to URLScan built in.

Use the HttpOnly Cookie Option

Internet Explorer 6 Service Pack 1 supports a new HttpOnly cookie attribute, which prevents client-side script from accessing the cookie from the document.cookie property. Instead, an empty string is returned. The cookie is still sent to the server whenever the user browses to a Web site in the current domain.

Note  

Web browsers that do not support the HttpOnly cookie attribute either ignore the cookie or ignore the attribute, which means it is still subject to XSS attacks.

The System.Net.Cookie class does not currently support an HttpOnly property. To add an HttpOnly attribute to the cookie, you need to use an ISAPI filter, or if you want a managed code solution, add the following code to your application's Application_EndRequest event handler in Global.asax:

 protected void Application_EndRequest(Object sender, EventArgs e)  {   string authCookie = FormsAuthentication.FormsCookieName;   foreach (string sCookie in Response.Cookies)    {     // Just set the HttpOnly attribute on the Forms authentication cookie     // Skip this check to set the attribute on all cookies in the collection     if (sCookie.Equals(authCookie))     {        // Force HttpOnly to be added to the cookie header       Response.Cookies[sCookie].Path += ";HttpOnly";     }   } } 
Note  

A future version of the .NET Framework is likely to have an HttpOnly property on the Cookie class.

Use the <frame> Security Attribute

Internet Explorer 6 and later supports a new security attribute on the <frame> and <iframe> elements. You can use the security attribute to apply the user's Restricted Sites Internet Explorer security zone settings to an individual frame or iframe . By default, the Restricted Sites zone doesn't support script execution. If you use the security attribute, it must currently be set to "restricted" as shown below:

 <frame security="restricted" src="http://www.somesite.com/somepage.htm"></frame> 

Use the innerText Property

If you create a page with untrusted input, use the innerText property instead of innerHTML . The innerText property renders content safe and ensures that script is not executed.




Improving Web Application Security. Threats and Countermeasures
Improving Web Application Security: Threats and Countermeasures
ISBN: 0735618429
EAN: 2147483647
Year: 2003
Pages: 613

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net