asp.net viewstate encryption issue

Question

I am attempting to turn on viewstate encryption Always as a security measure for my ASP.NET 3.5 website hosted in IIS6. We have viewstate turned off but still see some "controlstate" in this string. In a test environment I am able to simply set the following in web.config and i can no longer base64 decode the viewstate to semi-plaintext:

<pages enableViewState="false" enableViewStateMac="true" viewStateEncryptionMode="Always">

I have even added the following (genereated by machine key generater) to machine.config and still encrypts the viewstate fine on my test server:

<machineKey validationKey="002..." decryptionKey="D90E..." validation="SHA1" decryption="AES" />

My non-test environment doesn't seem to pick up the above changes as i can always base64 decode the viewstate to plain text with the above settings. I always iisreset after i make any changes.

Some info about my non-test webserver:

• Web Farm/Load Balanced (but only one server up for testing right now)
• Sql Session State (machinekey in machine.config was initially needed to set this up)
• machine.config: deployment retail="true"

Can anyone suggest where to look for additional settings that might interfere with asp.net viewstate encryption?

EDIT: Now on my iis test server i cannot undo the viewStateEncryptionMode setting as it is encrypting the viewstate even when i set it to "Never" and none of my other websites seem to take a hold of this setting. Where can i possibly look to see where this property is being overridden? Is there any cache where this setting is stored that needs to be cleared besides what would be done when i iisreset/stop www service/touch machine.config?

EDIT FINAL: After days of studying config files i gave up and implemented this via code. I already had a security module that was attaching to page events so in Page_Load i added: Page.RegisterRequiresViewStateEncryption();

I would really love to know what was preventing this setting from getting picked up on IIS6 immediatley. When i run cassini locally if i set the viewStateEncryptionMode to "Always" via the pages node i would immediately see it encode the viewstate and render the additional hidden field with id="__VIEWSTATEENCRYPTED". When i then set it to "Never" i would immediately see the encryption turn off. If i make the same exact change to the website on my IIS6 hosted website, it would have no effect immediately but if i allow the setting to stay there it would eventually take hold. I would stop/start www service, reset iis, clear ASPNET temp cache but i don't know what else to try? Hopefully this post can ROT for a while and someone in the future will see the same behavior i experienced and we can further figure this out!

Redouble

Turns out that RegisterRequiresViewStateEncryption also turns on ViewstateMAC validation even though i explicitly set this to false in my web.config. Since my site is a custom "MVC" that sits on top of WebForms where i redirect to different pages sometimes on POSTS i cannot have MAC validation. I am thinking that my web.config settings of ViewStateMAC = false and ViewStateEncryption = true was not a good combination. – Redouble

Answer 1

Web.config page settings do not apply to pre-compiled ASP.Net application with updatable option disabled. It has been a while but my test server i likely had deployed with updatable option disabled ... lesson learned.

SEE MSDN

Similar Question i Asked, same issue.

Redouble

Answer 2

I know it's been a while since you posted this, but have you considered making your own implementation of PageStatePersister? PageStatePersister is the component responsible for formatting the ViewState and ControlState data embedded in your page. If security is your primary concern you can use whatever encryption algorithms you'd like to ensure your data remains private. Based on your configuration it sounds like you're in a rather capable environment, so obviously load-test first. It's also worth mentioning that I have no idea regarding or experience with MVC's layered involvement in ViewState when incorporated in a "classic" ASP.NET WebForms site.

Good luck.

B

Fleurdelis

Thanks for the suggestion. I never explored this route, looking into all the issues that can be caused by putting viewstate in session i strayed away from rolling my own PageStatePersister. If i crack this back open I will definitely explore your idea of encrypting the session myself. – Redouble

Answer 3

My guess is the that load balanced web farm is the source of the confusion. You stated that only "only one server [is] up for testing right now", but all the symptoms you're experiencing sound exactly like what would happen if multiple servers in the web farm were running, but you only made the web.config and machine.config changes on one server. When you hit the website with your browser, sometimes you would hit one server that was configured one way, sometimes you would hit another server that was configured another way.

Cookie

That thought crossed my mind many times throughout the week I spent playing with this. I continuously checked this, and when frustrated moved to my dev server which is not load balanced. BUT you do have a valid point and it is important for everyone in a load balanced environment to understand – Redouble