Encrypting your ViewState

This one puzzled me a bit – but I wanted to encrypt my viewstate in Sitecore. I set my machine key, and set my algorithms – but it didn’t seem to do anything.

Well, the <pages> node has a viewStateEncryptionMode setting.

<pages validateRequest="true" viewStateEncryptionMode="Always">

Turn that on, and all seems good.

Encrypting your ViewState

Disable trace.axd

This is annoying misconfiguration I’ve come across a few times – tracing has been enabled on production systems.

Having tracing enabled allows an attacker to view the last 50 web requests made to the server, including information like Session ID values and the physical path to the requested files.


One can easily turn this off, though, by setting the <trace> node of web.config

<trace enabled="false"...

However, you can do a bit more than that. I believe that this problem occurred on live sites because configuration files were promoted from development to production. To this end, you can set localOnly="true" – this means that trace is only available on the local developer’s machine. This doesn’t substitute for disabling trace, but it does help reduce that risk.

Disable trace.axd

Secure your ASP.NET Viewstate

This is just a short reminder for myself – when configuring ASP.NET websites, don’t forget to Secure the viewstate. If you don’t, then the ViewState is just base64 encoded – and can be decoded.

Securing this involves:

  • Setting a machine key in the web.config. In a load balanced environment, this machine key should be the same on all front-end servers; it’s used in encryption and decryption of the viewstate, and so has to be the same on all webservers. If it is not, and a user’s session skips to another server, then decryption of the viewstate will fail.
  • Make sure the the validation algorithm is set to ‘AES’
  • Make sure that the ‘decryption’ algorithm is set to auto.

That seems to be it. I did see instructions that said that I should:

  • On the <pages> node, add the attribute viewStateEncryptionMode=”Always”

but I didn’t seem to have to do this. Actually, in the end I did have to set this too.

Edit: How to generate your machineKey easily





Secure your ASP.NET Viewstate

Lockdown Sitecore Administration

The Sitecore security hardening guide 6.0 (or version 7.5 here) describes:

You should prevent anonymous users from accessing the following folders:

  • /App_Config
  • /sitecore/admin
  • /sitecore/debug
  • /sitecore/shell/WebService

And then goes on to describe removing anonymous access to those areas in IIS.

Authentication Settings

The version 7.5 document goes on to say… Continue reading “Lockdown Sitecore Administration”

Lockdown Sitecore Administration

Configuring a Content-Security-Policy

I’ve talked about how to how to remove HTTP Headers that you don’t need from IIS – but there are some that you probably will want. This particular post is about the Content Security Policy (CSP).

I’m not going to describe what one is. @Scott_Helme has already described what a Content Security Policy is far better than I can. Rather, I’m going to describe how to figure out what your policy should be… Continue reading “Configuring a Content-Security-Policy”

Configuring a Content-Security-Policy

Removing Chatty IIS Headers

IIS is, by default, a bit too damn chatty, which isn’t what you want if you’re trying to harden your server:


You can check this with a site like SecurityHeaders.io, which will review all your HTTP Headers for you. It’s very good, I recommend it.

Why would I need to tell the world what ASP version, webserver, etc. that I’m using? Isn’t this just helping potential attackers? Well, yes. How do you remove these headers, though? Continue reading “Removing Chatty IIS Headers”

Removing Chatty IIS Headers