Even though ViewState is unreadable by the human eye, it is nothing but a base64 encoded
string that easily decodes by a piece of software like this
one. With this knowledge in mind, you might want to look at how you can secure
the ViewState to avoid tampering and maybe even identity theft in extreme cases.

Let’s take a look on how to secure the ViewState and at the same time, keeping it
simple to implement.

Encryption

The first thing we need to do is to add encryption to the ViewState. This is done
by editing the web.config only. We need to tell the web application to enable ViewStateMac.
This will generate a hashed code and add it to the ViewState. If the hashcode is tampered
with, any postback will fail. It is still not secure before we add encryption. That
is also done in the web.config by telling the application to use the 3DES encryption
algorithm. Add these two lines to the web.config’s <system.web> section:

<pagesenableViewStateMac="true" />

<machineKeyvalidation="3DES" />

The ViewState is now encrypted on an application wide basis, but it can still be compromised
by a skilled hacker.

User key

To further enhance the security ASP.NET can add another level of encryption based
on the actual user. If the user is authenticated by a logon form or similar authentication,
you can use the username as the encryption key. Override the OnInit method of your
web page or master page to add the username as key:

protectedoverridevoid OnInit(EventArgs e)

{

base.OnInit(e);

if (User.Identity.IsAuthenticated)

{

base.ViewStateUserKey
= User.Identity.Name;

}

}

This works great if the user is authenticated by the server, but what about web sites
where users don’t sign in, but still requires strong security like a webshop? You
cannot make it as secure without the username of the authenticated user, but you can
do something else to identify the user.

You can generate a key based on the IP-address, user-agent string and registered browser
languages. It is not 100% tamper-proof but it will make it much harder to break the
encryption. Here’s a method that generates a somewhat unique user key.

privatestring GenerateUserKey()

{

System.Text.StringBuilder sb
= new System.Text.StringBuilder();

sb.Append(Request.UserHostAddress);

sb.Append(Request.UserAgent);

if (Request.UserLanguages
!= null)

{

foreach (string language in Request.UserLanguages)

{

sb.Append(language);

}

}

return sb.ToString().GetHashCode().ToString();

}

This method creates one big string with information about the user’s browser environment
and then returns the hashcode of that string. Now we just need to add it to the OnInit
method like so:

protectedoverridevoid OnInit(EventArgs e)

{

base.OnInit(e);

base.ViewStateUserKey
= GenerateUserKey();

}

For this to be compromised, the hacker needs to know the users IP-address, user-agent
string and what languages is registered in the browser. The method could
also be extended to include more unique stuff from the session, cookies, cache or
anything else you can use to identify the user. That’s up to you.