ASP.NET 1.1 Security Guidelines - Parameter Manipulation

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan


Contents

Avoid storing sensitive data in view state

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

If your view state does contain sensitive data, you should consider protecting it against eavesdropping.

References


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." at http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh19.asp

References


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.

References


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" at http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh10.asp?frame=true#c10618429_012

References


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"], 
                    @"^[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 about using regular expressions and how to validate input data, see "Input Validation" at http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh10.asp?frame=true#c10618429_006 .

References

Personal tools