Secure your Sitecore Cookies

2016-10-212016-10-21 Andy BurnsASP.NET, cookies, HTTP, HTTPS, Security, SSL2 Comments

So a Sitecore site I’ve been working on recently underwent a penetration test, which turned up an interesting item. The ASP.NET_SessionId and SC_ANALYTICS_GLOBAL_COOKIE cookies aren’t set with the ‘Secure’ flag. Further, my own checking showed that the .ASPXAUTH token was also set without the ‘Secure’ flag.

As the entire site is only served over HTTPS, this seems to be a bit remiss.

Fortunately, there are a couple of easy fixes to this that can be set in the Web.config

Under <System.Web> and <httpCookies> set requireSSL:

<httpCookies requireSSL="true" />

And in <forms> set requireSSL too.

<forms name=".ASPXAUTH" cookieless="UseCookies" requireSSL="true" />

This latter one is needed for the .ASPXAUTH cookie, but that seems to do it.

Don’t forget to set the HTTPOnly flag as appropriate for your cookies too!

IIS Redirect HTTP to HTTPS

2016-04-06 Andy BurnsHTTP, IISLeave a comment

Just a quick note – if you want to use an IIS rule to redirect users from HTTP to HTTPS, the following rule seems to work pretty well. You’ll need the IIS URL Rewrite module installed.

<rule name="Redirect to HTTPS" stopProcessing="true"> <match url="(.*)" /> <conditions> <add input="{HTTPS}" pattern="^OFF$" /> </conditions> <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="SeeOther" /> </rule>

Is reading the web config faster than Sitecore’s Cache?

2016-02-292016-10-27 Andy BurnsLeave a comment

Okay, I’ll admit, I felt I knew the answer to this – but after my work with the CustomCache object, I felt that this was an interesting experiment.

If I just need to read string, is it faster to read from the configuration file with Sitecore.Configuration.Settings.GetSetting() or using the cache?

Well, the short answer is that the file is roughly twice as fast. Good, no cache needed! Continue reading “Is reading the web config faster than Sitecore’s Cache?” →

An example caching class for Sitecore

2016-02-262016-01-28 Andy BurnsCaching, CustomCache, PublishingLeave a comment

Previously I posted about the generalities of implementing a Cache in Sitecore using the CustomCache class. Well, I’ve actually implemented a few caches for Sitecore using this; let’s have a look at my general pattern. Continue reading “An example caching class for Sitecore” →

Adding a button to the User Manager

2016-02-152016-01-15 Andy BurnsRibbon, Sitecore Shell, UserManager1 Comment

A quick shout out to this page – Adding Options to Sitecore Applications by Alistair Deneys . It’s a nice guide about how to do exactly that – add options to the menus in Sitecore. It was pretty straight forward to do for the User Manager:

Add an entry in the Core database to represent the button
Add a patch file that defines your command and what class it should call
Add a class file that defines the command in a child of Sitecore.Shell.Framework.Commands.Command . Override and implement Execute

The parameters to the Execute method contains which usernames have been selected. This is as a pipe separated list:

public override void Execute(CommandContext context) { string usernamesParameter = context.Parameters["username"]; string[] usernames = null; if (!string.IsNullOrEmpty(usernamesParameter)) { char[] splitter = {'|' }; usernames = usernamesParameter.Split(splitter, StringSplitOptions.RemoveEmptyEntries); }

That might help.

Awkward Page Request Validation in Sitecore

2016-02-092016-01-11 Andy BurnsSecurity, webconfigLeave a comment

I was configuring a new Sitecore 8.1 instance. It’s a vanilla, straight-off-the-installer instance, and yet I noticed that the node’s request validation was off:

<pages validateRequest="false">

This did, at least, come with a comment above it:

If requestValidationMode attribute of httRuntime node is set to 2.0, Sitecore requires this setting to be set to “false” for Sitecore client to work and it shouldn’t be changed. You can however set ValidateRequest attribute in the @Page directive to “true” for your layout .aspx files.

This is bonkers. The default configuration for this site is to remove request validation on my brand new Sitecore instance on the off-chance I should want to configure it to use an older, non-default requestValidationMode. Instead, I should stumble across this comment in the web.config file and add the appropriate attribute to all the layouts of my solution. And someone thought that this was a good idea?

Even if I were upgrading and I did rely on the httpRuntime requestValidationMode being 2.0, I would prefer that this was set to true, with instructions for how I should handle it in the case of an upgrade.

Crazy. One to be aware of.

Encrypting your ViewState

2016-02-082016-01-11 Andy BurnsMachineKey, Security, ViewstateLeave a comment

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.

Reset your Admin account’s password

2016-02-052015-12-23 Andy BurnsSitecore Admin, SQL1 Comment

I recently had to work with a Sitecore instance where one of my colleagues – who has gone – had not documented the password.

The quickest answer I could find to this was to reset the password to its default:

-- Might want to check that 'B09BBCDE-9B3C-4DCD-B69E-67F615CE01E9' is your Administrator Update [aspnet_Membership] set [Password] = 'qOvF8m8F2IcWMvfOBjJYHmfLABc=', [PasswordSalt] = 'OM5gu45RQuJ76itRvkSPFw==' where UserId = 'B09BBCDE-9B3C-4DCD-B69E-67F615CE01E9'

Disable trace.axd

2016-01-292015-12-17 Andy BurnsSecurity, webconfigLeave a comment

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.

Nasty.

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.

The trace element – https://msdn.microsoft.com/library/6915t83k(v=vs.100).aspx

Secure your ASP.NET Viewstate

2016-01-262016-01-13 Andy BurnsSecurity, ViewstateLeave a comment

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

Andy Burns' Blog

Whatever I'm working on

Sitecore