Microsoft ASP.NET Coding Strategies with the Microsoft ASP.NET Team (Pro-Developer)

Before we start talking more about identity primitives and role checking, let’s look at a new feature of ASP.NET version 1.1 that makes it easier to avoid an entire category of security problems. The problem is generally called cross-site scripting and refers to inadvertently presenting client-side script to the user. Cross-site scripting occurs when invalidated user input is returned in the page. One example of this would be an attacker presenting the user with a link to a trusted Web site that has script embedded in the query string of the URL. If the site uses the QueryString variable in the response, the browser will try to execute the script, and the user will think the script is being sent by the trusted Web site. The attacker gets the user to execute her code by making it appear as though the script comes from somewhere else.

By default, ASP.NET parses the data submitted by the browser, looking for potentially dangerous strings. This helps guard against the user forgetting that it’s not a good idea to simply return user input directly in the response. Many books about Web programming include a Hello World example that is vulnerable to exactly this sort of threat. The user is asked to enter her name and when the form is submitted, the name is returned to her. Figure 8-4 shows the error that happens when submitting potentially dangerous form data. It is relatively straightforward for a hacker to construct a link to a page that has script included as part of the input. When the script comes back as part of the response, the user thinks the page is coming from the target site. Figure 8-5 illustrates the interactions that occur in a cross-site scripting attack. The user follows a link from the malicious site to the trusted site and gets a page with script provided by the malicious site.

Figure 8-4: Validation failure

Figure 8-5: Cross-site scripting

Input validation is controlled in several ways. The pages element of machine.config includes a validateRequest attribute that is set to true by default. It can also be controlled in a page directive with the same name or in a web.config file at the application level. It is also possible to cause input validation on demand by calling the new ValidateInput method of the System.Web.UI.Page class. In most scenarios, leaving the default input validation configuration intact should suffice.

If you need to allow the user to submit markup, be sure to encode it with HTML before displaying it in a page. In Code Listing 8-11, we turned off validation in a simple Hello Scripted World.aspx page. The user is allowed to submit anything, but the content is encoded before being displayed.

Code Listing 8-11: Hello Scripted World.aspx

<%@Page language="C#" validateRequest="false" %> <script runat="server">void Page_Load(object o, EventArgs e) { if(IsPostBack) { message.Text = "Hello! Your input was: " + Server.HtmlEncode(userInput.Text); }}</script> <form runat="server"><asp:label runat="server" text="Please input your name, or some malicious script." /><br><asp:textbox runat="server" /><br><asp:button runat="server" text="submit" /><br></form>

Most applications will not need to disable the automatic validation for pages and will benefit from the added protection provided by ASP.NET. If any pages require input that is blocked, be sure to encode all that input before displaying it to the user.