ASP.NET 2.0 Security Guidelines - Parameter Manipulation

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley, Kishore Gopalan


Contents

Do Not Make Security Decisions Based on Parameters Accessible on the Client-Side

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.


Validate All 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, such as 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 such as apostrophes 
 // for names such as D'Angelo.
 if (!Regex.IsMatch(Request.QueryString["name"], @"^[a-zA-Z'`-ยด\s]{1,40}$"))
    throw new Exception("Invalid name parameter");
 // Use individual regular expressions to validate all other
 // query string parameters.
 ...
}
 

For more information, see How To: Protect from Injection Attacks in ASP.NET and How To: Use Regular Expressions to Constrain Input in ASP.NET.


Avoid Storing Sensitive Data in ViewState

Avoid storing sensitive data in ViewState. ViewState is not designed for sensitive data, and protecting it with encryption adds to performance overhead. If you need to manage sensitive data, maintain it on the server; for example, maintain it in session state.

If your ViewState does contain sensitive data, you should consider protecting it against eavesdropping by enabling ViewState encryption as described in the next section.


Encrypt ViewState if It Must Contain Sensitive Data

Using SSL protects ViewState while it is passed over the network between server and browser, but it does not stop it being viewed and modified on the user's computer.

To prevent ViewState from being viewed on the user's computer (and over the network), use ASP.NET ViewState encryption. Do not use it if your ViewState does not contain sensitive data because encryption significantly adds to the size of the ViewState and this impacts performance.

For more information about protecting ViewState, see How To: Configure the Machine Key in ASP.NET 2.0.


Consider Using Page.ViewStateUserKey to Counter One-Click Attacks

Consider using Page.ViewStateUserKey to counter one-click attacks. If you authenticate your callers and use ViewState, set the Page.ViewStateUserKey property in the Page_Init event handler to prevent one-click attacks.


void Page_Init (object sender, EventArgs e) {
  ViewStateUserKey = Session.SessionID;
}
 

Set the property to a value you know is unique to each user, such as a session ID, user name, or user identifier.

A one-click attack occurs when an attacker creates a Web page (.htm or .aspx) that contains a hidden form field named __VIEWSTATE that is already filled with ViewState data. The ViewState can be generated from a page that the attacker had previously created, such as a shopping cart page with 100 items. The attacker lures an unsuspecting user into browsing to the page, and then the attacker causes the page to be sent to the server where the ViewState is valid. The server has no way of knowing that the ViewState originated from the attacker. ViewState validation and HMACs do not counter this attack because the ViewState is valid and the page is executed under the security context of the user.

By setting the ViewStateUserKey property, when the attacker browses to a page to create the ViewState, the property is initialized to his or her name. When the legitimate user submits the page to the server, it is initialized with the attacker's name. As a result, the ViewState HMAC check fails and an exception 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.

Personal tools