ASP.NET ViewState Security

ASP.NET ViewState data is stored in a single Base64-encoded string  such as  this:

id="__VIEWSTATE" value="dDw3NDg2NdTI5MDg7Ozr4="/>

Since this value is not formatted in clear text, developers sometimes assume that their ViewState data is encrypted which is most certainly not the case. This data string can be reverse-engineered this and then viewed. This is an obvious security issue if sensitive data is being stored in ViewState.

To make ViewState secure, there are two choices, hash codes and ViewState encryption.

Use a hash code.

A hash code  is a cryptographically strong checksum. When you use a has code, ASP.NET calculates the checksum based on the current ViewState content data and then adds this to the hidden input field when the page  when is returned to the client.  On the page post back, ASP.NET then recalculates the checksum to  ensures a  match. If a malicious user were to  change the ViewState data, ASP.NET can detect the  the change reject the postback.
Hash codes are enabled by default,  however, sometimes developers elect  to disable hash codes to prevent problems on a web farm when  servers have different keys. Hash codes can be disabled on the page in the .aspx file’s Page directive:

<%@ Page EnableViewStateMac="false" ... %>

To disable hashing site-wide use the  ViewStateMac attribute of the pages  element in  web.config :

<configuration>
<system.web>
<pages enableViewStateMac="false" />
...
</system.web>
</configuration>

For more on hashing, please refer to C# Security – Hashing

Use ViewState Encryption.

Hash codes help to prevent ViewState data from being tampered with but they do not provide much assistance in preventing ViewState data from being read since hash codes can still be converted to clear text. To prevent ViewState being read, use the  ViewState Encryption, which can be turned on at the page level using the ViewStateEncryptionMode property of the Page directive:

<%@Page ViewStateEncryptionMode=”Always” … %>

Or site-wide in the web.config file:

<pages viewStateEncryptionMode=”Always” />

There are three settings for viewStateEncryptionMode:

  1. Always : All ViewState data is encrypted.
  2. Never : No ViewState data is encrypted.
  3. Auto : Data is only encrypted when specifically requested by the ASP.NET control.

The default setting is Auto so no data will be encrypted unless otherwise requested by a control on a page. For a control to request encryption in needs to call the Page.RegisterRequiresViewStateEncryption() method before it is rendered to HTML.

Note that using encryption incurs a performance penalty so it should only be used when necessary.

ASP.NET Client-Side State Management – ViewState, Cookies and QueryString

Web form pages are HTTP-Based, they are stateless, which means they don’t know whether the requests are all from the same client, and pages are destroyed and recreated with each round trip to the server, therefore information will be lost and state management is a major issue in developing web applications. In this article we review how to handle state manage on the client using ViewState , Cookies, Hidden Fields and QueryStrings.

1. ASP.NET ViewState

Each control on a Web Forms page, including the page itself, has a ViewState property, it is a built-in struture for automatic retention of page and control state, which means you don’t need to do anything about getting back the data of controls after posting page to the server.

Here, which is useful to us is the ViewState property, we can use it to save information between round trips to the server.

//to save information
ViewState.Add(“shape”,”circle”);
//to retrieve information
string shapes=ViewState[“shape”];

Note: Unlike Hidden Fields, the values in ViewState are invisible in the ‘viewsource’ of the page, they are compressed and encoded.

2. ASP.NET Cookies .

A cookie is a small amount of data stored either in a text file on the client’s file system or in-memory in the client browser session. Cookies are mainly used for tracking data settings.

Let’s take an example: say we want to customize a welcome web page, when the user request the default web page, the application first to detect if the user has logined before, we can retrieve the user informatin from cookies:

if(Request.Cookies[“username”]!=null)
 lbMessage.text=”Dear“+Request.Cookies[“username”].Value+”, Welcome shoppinghere!”;
else
 lbMessage.text=”Welcome shoppinghere!”;

If you want to storeclient’s information, you can use the following code:

Response.Cookies[“username’].Value=username;

So next time when the user request the web page, you can easily recongnize the user again.

3. ASP.NET Hidden Fields

A hidden field does not render visibly in the browser,but you can set its properties just as you can with a standard control. When a page is submitted to the server, the content of a hidden field is sent in theHTTP Form collection along with the values of other controls.

A hidden field acts as a repository for any page-specific information that you would like tostore directly in the page. Hidden field stores a single variable in itsvalue property and must be explicitly added it to the page.
ASP.NET provides the HtmlInputHidden control that offers hidden field functionality.

protected System.Web.UI.HtmlControls.HtmlInput Hidden Hidden1;
//to assign a value to Hiddenfield
Hidden1.Value=”this is a test”;
//to retrieve a value
stringstr=Hidden1.Value;

Note: Keep in mind, in orderto use hidden field, you have to use HTTP-Post method to post web page. Although its name is ‘Hidden’, its value is not hidden, you can see its value through ‘view source’ function.

4. ASP.NET QueryStrings

Query strings provide a simple but limited way of maintaining some state information.You can easily pass information from one page to another, But most browsers and client devices impose a 255-character limit on the length of the URL. In addition, the query values are exposed to the Internet via the URL so in some cases security may be an issue.Continues…