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=”002B8A005BC72C2BAADDB2769652FBC3FCCC9CC7E98E452937D7149657FEE580E05092DB5F5B05E25EF1B33FF499FBA0E8E1E7CB738978B7A7088EE9BBA27D3B” decryptionKey=”D90EB3ECE0C91E68E2C180A0D3A952267E80BFA44585FB3C167B504504BA9F61″ 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)
- SSL Required via IIS6 config setting
- permissions are a bit more strict
- 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 sit 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!
ViewState Encryption in ASP.Net
Why is it that I see the same hash value generated when I use different algorithms for viewstate encryption. I have added below lines to the web.config file pages viewstateEncryptionMode=Always enab
ASP.net ViewState encryption and decryption
I heard that .NET framework will encrypt the ViewState using SHA1 or some other algorithm. So if i know the SHA1 encryption and decryption algorithm can i tamper a ViewState?I mean a malicious user st
We are using our website on Windows server 2003 with IIS 6 and also have a test server 2003 with IIS 5. When I tested the page with ViewState on test server, it worked fine. But we tested on other ser
asp.net viewstate encryption
I have a few questions about when and how viewstate is encrypted in asp.net 3.5. For instance, if I have a machinekey entry in my web.config like: decryptionKey=AutoGenerate,IsolateApps validation=
ViewState Encryption doesn’t work with mixed algorithms
I have a client who wants to turn on ViewState encryption in an ASP.NET Web Forms application. They are not able to use the default algorithms because of FIPS compliance. The initial request from the
AspNet MVC template issue
I’m having some trouble with the asp.net register/login system that comes ready with the AspNet MVC template. It worked great for me up until recently that I started receiving the following error:
Change Password Issue in AspNet MembershipProvider
I am using AspNet Membership Provider in MVC 3. I am facing issue in change password. I have two functionality in my project Forgot password : ask security question and based on security answer chan
Testing JSF application with JMeter – ViewState issue
All day I try to run JMeter tests of my JSF application. I am aware of ViewState, but it seemed to be quite simple issue. I prepared Regular Expression Extractor: Reference Name: jsfViewState Regular
Coldfusion Encryption/Decryption issue
I recently did a website for my company using ColdFusion 9. The issue I am having is with the ColdFusion encryption/decryption function. On certain strings that I decrypt I get these weird special cha
Is there a benefit of turning ViewState Encryption Off (asp.net IIS7)?
I understand how to turn off ViewState encryption for asp.net web applications. I want to know if I should. My question is more from a performance stand point than a security one (All of our traffic i
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.
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.
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.
Similar Question i Asked, same issue.