Wrox Programmer Forums
| Search | Today's Posts | Mark Forums Read
BOOK: Professional ASP.NET 3.5 Security, Membership, and Role Management ISBN: 978-0-470-37930-1
This is the forum to discuss the Wrox book Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB by Bilal Haidar; ISBN: 9780470379301
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Professional ASP.NET 3.5 Security, Membership, and Role Management ISBN: 978-0-470-37930-1 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
  #1 (permalink)  
Old February 5th, 2009, 10:52 PM
jminatel's Avatar
Wrox Staff
Points: 17,906, Level: 58
Points: 17,906, Level: 58 Points: 17,906, Level: 58 Points: 17,906, Level: 58
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
Join Date: May 2003
Location: Indianapolis, IN, USA.
Posts: 1,906
Thanks: 62
Thanked 139 Times in 101 Posts
Default Article: ASP.NET Security Preventing Cross-Site Scripting

This article is exerpted from chapter 18 "Best Practices for Securing ASP.NET Web Applications" of the Wrox book Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB by Bilal Haidar and is reused by permission of the publisher. This may not be reused without publisher permission
Cross-Site Scripting
Cross-site scripting, also known as XSS or CSS, is a direct result of not having proper user input validation and failing to encode output to be displayed. The consequences of having improper input validation have been mentioned explicitly in detail. XSS is no different!
For instance, a user enters a public Forum, adds a post to a current or new thread that includes malicious script. The application, if there is improper user input validation and/or encoding for data embedded in the response, takes the input as is and stores it in the database. Now, any user who accesses the same page would have the malicious script executed silently when the application fails to encode the response. The browser is not able to distinguish between harmful and safe scripts. Whatever response the browser receives from the server is simply executed on the client-side. The malicious script could be an annoying one like displaying a pop-up message. Other malicious scripts might be more harmful and could steal stored authentication cookies and send them silently to the attacker.
An attacker usually looks for web applications that redisplay the text that was typed in the input fields via the query string, especially in the case of a search engine, or even a failed trial to validate credentials on a login page.
To protect against XSS, you should consider all input as malicious that requires input validation, encoding for all output, in case it contains HTML characters, regardless of the source for such data.
Validating input has been thoroughly discussed. Accordingly, the input data should be well-validated by checking that the correct type is received, the format of the input data is correct, and that the length and range of values are acceptable. ASP.NET validation controls like RegularExpressionValidator and RangeValidator play an important role in addition to the Regex class in the .NET framework that you can use to validate HTML input fields on the server-side. Programmatic checking for the type of input text can also be accomplished using the type-checking methods in the .NET framework like the Int32.TryParse() method.
As discussed previously, always encode whatever input text you receive from the client-side. The .NET framework provides the System.Web.HttpUtility.HtmlEncode() method to properly encode text before it is processed, whether for storage into the database or storage into files. Encoding text that includes HTML tags converts some of the tags into a different form. For instance, the space character is converted to &nbsp; and the “<” character gets converted to &lt;. In addition, if you need to embed URLs in the response on the server you can use the System.Web.HttpUtility.UrlEncode() method to properly encode the URL. Encoding not only covers the input fields, but also cookies, session variables, query strings, and database access methods. Any source of input data can be a source of harm to your applications.
When talking about encoding output to be displayed on the client-side, it is important to limit the ways in which data entered by end-users can be represented by the application on the server-side. Using a limited character set prevents malicious users from using canonicalization and multi-byte escape sequences to bypass the input validation routines on the server-side code. ASP.NET allows you to specify the character set in three different areas:
asp Code:
<meta http-equiv="Content Type" content="text/html; charset=ISO-8859-1" />
The first option is to use the HTML meta tag in the <head> section of an .aspx page. The above markup line sets the character set of the page to ISO Latin 1 (ISO-8859-1), which is the default character set for early versions of HTML and HTTP. In fact, the ISO Latin 1 is limited but it is recommended to use in your pages.
asp Code:
<% @ Page ResponseEncoding="ISO-8859-1" RequestEncoding="ISO-8859-1" %>
The second way to specify the character set is to set the ResponseEncoding and RequestEncoding properties on the .aspx page directive, as follows:
asp Code:
The third way is to make use of the <globalization> section in the web.config configuration file.
Protecting against harmful user input starts by enabling the ValidateRequest public property on the Page class. By default, request validation is enabled in any ASP.NET application. This property insures that no harmful scripts or HTML tags can ever be sent from the client-side to the server-side. However, as mentioned above, in some cases, there is a need to allow users to enter HTML formatting tags, for example, in a Rich Text Editor. As discussed earlier, you can do some character conversions on the client-side and convert back to the original text on the server-side! Enabling/disabling request validation takes two forms. The first is shown here:
csharp Code:
<%@ Page Language="C#" ValidateRequest="false" %>
vbnet Code:
<%@ Page Language="Vb" ValidateRequest="false" %>
You can configure this property on a page-level as the code snippet shows. The second form is as follows:
asp Code:
  <pages validateRequest="true" />
This way, you can configure validation at the application-level by configuring the <pages> configuration sections inside the web.config configuration file. Figure 18-6 shows the page that ASP.NET generates when request validation is enabled and a user enters some HTML tags or any other JavaScript scripts.
The ASP.NET and Application Consulting & Engineering (ACE) teams at Microsoft provided the Microsoft Anti-Cross Site Scripting Library V1.5 encoding library that is designed to help developers protect their web applications from cross-site scripting attacks. This library differs from other encoding libraries in that it uses the principle-of-inclusions technique. This technique is similar to the concept of whitelisting and it works by defining a set of allowable or valid set of characters and encoding anything outside this set:
csharp Code:
namespace Microsoft.Application.Security
    public class AntiXss {
    public static string HtmlEncode(string s);
    public static string HtmlAttributeEncode(string s);
    public static string JavaScriptEncode(string s);
    public static string UrlEncode(string s);
    public static string VisualBasicScriptEncode(string s);
    public static string XmlEncode(string s);
    public static string XmlAttributeEncode(string s);
vbnet Code:
Namespace Microsoft.Application.Security
   Public Class AntiXss
       Public Shared Function HtmlAttributeEncode(ByVal s As String) As String
       Public Shared Function HtmlEncode(ByVal s As String) As String
       Public Shared Function JavaScriptEncode(ByVal s As String) As String
       Public Shared Function UrlEncode(ByVal s As String) As String
       Public Shared Function VisualBasicScriptEncode(ByVal s As String) As String
       Public Shared Function XmlAttributeEncode(ByVal s As String) As String
       Public Shared Function XmlEncode(ByVal s As String) As String
   End Class
End Namespace
This code shows the set of methods that are available by the library that you can use to protect against the input you receive from end-users, and to properly send encoded data to the client-side.
The HtmlEncode() method is used to encode text that is to be displayed in the context of HTML. The container that will hold the encoded text can be any ASP.NET server control that can display text:
csharp Code:
this.lblName.Text = Microsoft.Security.Application.AntiXss.HtmlEncode this.txtName.Text);
vbnet Code:
Me.lblName.Text = Microsoft.Security.Application.AntiXss.HtmlEncode(Me.txtComments.Text)
The HtmlEncode() method can also be used when displaying text directly inside HTML tags using <%= %> block:
asp Code:
<% = Microsoft.Security.Application.AntiXss.HtmlEncode(this.txtName.Text) %>
The HtmlAttributeEncode() method is used to encode attributes when embedding HTML elements into the page and specifying its attributes that might be used by attackers to send malicious and harmful scripts to the server:
csharp Code:
this.ltSeperator.Text =
     "<hr noshade size="+
     Microsoft.Security.Application.AntiXss.HtmlAttributeEncode (
vbnet Code:
Me.ltSeperator.Text = _
    "<hr noshade size=" & _
    Microsoft.Security.Application.AntiXss.HtmlAttributeEncode ( _
    Me.txtSizeInPixels.Text) & _
This example shows how to safely encode HTML attributes when embedding dynamic HTML elements on the page.
The other methods available in the library are used in the same manner as the above sample methods. You can read more about the Anti-Cross Site Scripting library by reading the article on MSDN at: http://msdn.microsoft.com/en-us/library/aa973813.aspx.
Attached Thumbnails
Click image for larger version

Name:	Figure 18-6.jpg
Views:	21
Size:	256.1 KB
ID:	7  
Jim Minatel
Associate Publisher, WROX - A Wiley Brand
Did someone here help you? Click on their post!

Last edited by jminatel; February 5th, 2009 at 10:56 PM..
  #2 (permalink)  
Old June 18th, 2010, 06:36 PM
Registered User
Join Date: Aug 2003
Location: , , .
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
Default Cross-Site Scripting

re: "Cross-Site Scripting" Jim Minatel's article as excerpted from chapter 18 of the book by Bilal Haidar ( Professional ASP.NET 3.5 Security, Membership, and Role Management)

I have question about a line of ASP code in this article:

<% = Microsoft.Security.Application.AntiXss.HtmlEncode(this.txtName.Text)%>
Where do you make references in the ASP code/app to the AntiXss DLL and what folder/directory location do you put the AntiXss DLL? And, what are the particulars for registering this DLL?

Similar Threads
Thread Thread Starter Forum Replies Last Post
article posted: ASP.NET 2.0 security jminatel ASP.NET 2.0 Professional 0 May 11th, 2006 02:45 PM
Cross-site security problem! dutguoyi ASP.NET 1.0 and 1.1 Professional 2 April 11th, 2006 02:55 AM
Cross-platform scripting jhusain XSLT 1 January 13th, 2005 05:37 AM

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.