Parameter Manipulation

Parameters, such as those found in form fields, query strings, view state, and cookies, can be manipulated by attackers who usually intend to gain access to restricted pages or trick the application into performing an unauthorized operation.

For example, if an attacker knows that you are using a weak authentication token scheme such as a guessable number within a cookie, the attacker can construct a cookie with another number and make a request as a different (possibly privileged) user .

The following recommendations help you avoid parameter manipulation vulnerabilities:

• Protect view state with MACs .

• Use Page.ViewStateUserKey to counter one-click attacks .

• Maintain sensitive data on the server .

• Validate input parameters .

Protect View State with MACs

If your Web pages or controls use view state to maintain state across HTTP requests , ensure that the view state is encrypted and integrity checked through the use of MACs. By default, the enableViewStateMac attribute on the <pages> element in Machine.config ensures that view state is protected with a MAC.

 <pages buffer="true" enableSessionState="true"        enableViewState="true" enableViewStateMac="true"         autoEventWireup="true" validateRequest="true"/> 

Note  

The @Page directive also supports the preceding attributes, which allows you to customize settings on a per-page basis.

While you can override whether or not view state is enabled on a per-control, page, or application basis, make sure enableViewStateMac is set to true whenever you use view state.

Server.Transfer

If your application uses Server.Transfer as shown below and sets the optional second Boolean parameter to true so that the QueryString and Form collections are preserved, then the command will fail if enableViewStateMac is set to true.

 Server.Transfer("page2.aspx", true); 

If you omit the second parameter or set it to false, then an error will not occur. If you want to preserve the QueryString and Form collections instead of setting the enableViewStateMac to false, follow the workaround discussed in Microsoft Knowledge Base article 316920, "PRB: View State Is Invalid" Error Message When You Use Server.Transfer."

For information about configuring the <machineKey> element for view state encryption and integrity checks, see Chapter 19, "Securing Your ASP.NET Application and Web Services."

Use Page.ViewStateUserKey to Counter One-Click Attacks

If you authenticate your callers and use view state, set the Page.ViewStateUserKey property in the Page_Init event handler to prevent one-click attacks. A one-click attack occurs when an attacker creates a prefilled Web page (.htm or .aspx) with view state. The view state can be generated from a page that the attacker had previously created, for example, a shopping cart page with 100 items. The attacker lures an unsuspecting user into browsing to the page, then causes the page to be sent to the server where the view state is valid. The server has no way of knowing that the view state originated from the attacker. View state validation and MACs do not counter this attack because the view state is valid and the page is executed under the security context of the user.

Set the Page.ViewStateUserKey property to a suitably unique value as a countermeasure to the one-click attack. The value should be unique to each user and is typically a user name or identifier. When the attacker creates the view state, the ViewStateUserKey property is initialized to his or her name. When the user submits the page to the server, it is initialized with the attacker's name. As a result, the view state MAC check fails and an exception condition is generated.

Note  

This attack is usually not an issue for anonymously browsed pages (where no user name is available) because this type of page should make no sensitive transactions.

Maintain Sensitive Data on the Server

Do not trust input parameters, especially when they are used to make security decisions at the server. Also, do not use clear text parameters for any form of sensitive data. Instead, store sensitive data on the server in a session store and use a session token to reference the items in the store. Make sure that the user is authenticated securely and that the authentication token is secured properly. For more information, see "Session Management" earlier in this chapter.

Validate Input Parameters

Validate all input parameters that come from form fields, query strings, cookies, and HTTP headers. The System.Text.RegularExpressions.Regex class helps validate input parameters. For example, the following code shows how to use this class to validate a name passed through a query string parameter. The same technique can be used to validate other forms of input parameter, for example, from cookies or form fields. For example, to validate a cookie parameter, use Request.Cookies instead of Request.QueryString .

 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.QueryString["name"],                       @"^[\p{L}\p{Zs}\p{Lu}\p{Ll}]{1,40}$"))     throw new Exception("Invalid name parameter");   // Use individual regular expressions to validate all other   // query string parameters   . . . } 

For more information about using regular expressions and how to validate input data, see "Input Validation" earlier in this chapter.