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.
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…
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.
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
Something that has come up in some of our testing recently is that some of our websites have HTTP verbs allowed that probably should be blocked – and with IIS they can be.
To recap, we’re use to the idea of GET or POST requests, but there are a lot more… Continue reading “Lock down your HTTP Verbs”
The Sitecore security hardening guide 6.0 (or version 7.5 here) describes:
You should prevent anonymous users from accessing the following folders:
And then goes on to describe removing anonymous access to those areas in IIS.
The version 7.5 document goes on to say… Continue reading “Lockdown Sitecore Administration”
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. 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”
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”