ASP.NET ViewState: Approach with Caution

You already know this, somewhere in the back of your mind your little inner voice keeps telling you that you shouldn’t be putting into ViewState anything that’s even remotely close to looking as if it could ever be sensitive.

Although ViewState provides some built in mechanisms to prevent tampering and hijacking (via Machine Authentication Check, know as MAC), and is very useful to developers, the thing to remember is that it is completely readable text, stored on the client’s browser, in the markup of the page.

What do you mean “completely readable”? I mean just that, it’s a base 64 encoded string that is easily decoded into human (or hacker software) readable. To see for yourself just download and use the ViewState Decoder, available from the awesome guys at PluralSite (http://www.pluralsight-training.net/community/media/p/51688.aspx ).

It’s not uncommon to store custom items in ViewState, while this can be extremely useful it’s important to remember that this information will be packaged up into the Base 64 encoded string (ultimately ended up as the Value of a Hidden Field) and easily viewable to the world with little effort.

If you don’t need ViewState then turn it off. This is easily accomplished at the control and/or page level or globally via the Web.config file (a.k.a. ViewStateEnabled = “false”). To learn more about ViewState please visit http://msdn.microsoft.com/en-us/library/ms972976.aspx pay special attention to the section about ViewStateMAC and Server.Transer, read the KB Article which explain in detail the security whole you open up when disabling the ViewStateMAC security feature (http://support.microsoft.com/default.aspx?scid=kb;EN-US;316920 )

An important thing to remember is that ViewState can grow to be extremely large, bloating the page size that must be downloaded to the end users computer both on the initial visit to the page and with each postback, resulting in slower site performance and heavier loads on the server and network.

Integrated Windows Authentication: Getting FireFox to Play Nice

If you protect your web applications using Integrated Windows Authentication (IWA), typical with company Intranets, FireFox will prompt users to provide their network credentials (i.e. their Username and Password) when they try to access the site.

You can side step this by making minor changes to FireFox so that it will negotiate with the web server behind the scenes, effectively performing a “silent login” like Internet Explorer does automatically when accessing IWA protected apps.

 

IMPORTANT: Your IIS node needs to allow fall back to NTLM Authentication for this to work.

Using the Metabase Manager, part of the IIS Resource Toolkit that is available from Microsoft, will showNegotiate, NTLM under Authentication. If you removed NTLM than this tutorial is a waste of your time

Step 1:

Open FireFox, in the Address Bar type about:config, you will be prompted with a warning like the following.

FF-Intranet-Support1

Step 2:

Click the “I’ll be careful, I promise!” button. In the “Filter” textbox type network.automatic

FF-Intranet-Support2

Step 3:

Select the 2nd option named network.automatic-ntlm-auth.trusted-uris. Enter the values of your Intranet sites, separating them with a comma, and click OK

FF-Intranet-Support3

FireFox will then negotiate your login silently, eliminating the need for the Server Login prompt.