Interesting Links – The ‘Oh God, not Mongo’ edition

My interesting links email is something I send out to my colleagues, well, when I’ve found stuff of interest.

“On two occasions I have been asked, ‘Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?’ I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.”
– Charles Babbage

To be honest, I now believe we should not be building sites which aren’t served over HTTPS. It’s more secure, faster, ranked higher in Google search results, and Chrome won’t mark it as insecure. ‘Nuff said.

Interesting Links – The ‘Oh God, not Mongo’ edition

Subresource integrity (SRI) – and why it needs failover.

When building websites, significant performance gains can be made by using files from a Content Delivery Network (CDN). CDNs usually have nodes much more local (physically) to a visitor, and common files used across many sites (such as jQuery, bootstrap, etc.) may even be already in the visitor’s cache.

However, if you’re using a file from a CDN, well, you don’t really control it. Someone could change it, for honest or nefarious reasons – and your site would still load that resource and try to use it. Continue reading “Subresource integrity (SRI) – and why it needs failover.”

Subresource integrity (SRI) – and why it needs failover.

App Insights Visual Studio Integration is Fantastic

So, I do love App Insights, but I just realised that it’s even better than I’d thought. They’ve integrated it more closely with Visual Studio.

In the code you can see things at the top of each method – how many references it has, who last edited it, how long ago it was edited,, etc.

Well now you can also see the exceptions that were recorded by App Insights for that method in the last 24 hours:

appinsights-in-visual-studio

Fantastic!

(And all those are expected exceptions. If anyone works out a way of doing a Response.Redirect() without a ThreadAbortException and still killing the page processing, let me know)

App Insights Visual Studio Integration is Fantastic

Interesting Links – the “Secure all the things” edition

My interesting links email is something I send out to my colleagues, well, when I’ve found stuff of interest.

Interesting Links – the “Secure all the things” edition

Interesting Links – The secured cookie edition

My interesting links email is something I send out to my colleagues, well, when I’ve found stuff of interest.

Interesting Links – The secured cookie edition

Interesting Links – the CTRL-c, CTRL-v edition

My interesting links email is something I send out to my colleagues, well, when I’ve found stuff of interest.

Interesting Links – the CTRL-c, CTRL-v edition

Interesting Links – Stuff Andy read while waiting for downloads

My interesting links email is something I send out to my colleagues, well, when I’ve found stuff of interest. This one is quite old (December 2015).

Idle thought for the day – should we include in our sites/pages details of ‘how to contact us if you find a vulnerability’?

 

Interesting Links – Stuff Andy read while waiting for downloads

Secure your Sitecore Cookies

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!

Secure your Sitecore Cookies

IIS Redirect HTTP to HTTPS

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>

 

IIS Redirect HTTP to HTTPS