Security for login cookies with ASP.Net MVC3

I was reading here about how it's a bad idea to log into your application using SSL (https) and then revert back to http for subsequent pages. If you do that then you'll send the authentication token over an unencrypted connection, which is a bad thing.

Whilst wondering if there was an easy way to solve that problem, I wrote some code to try and enforce a secure connection whenever the user was authenticated. So I wrote my own [RequireHttpsWhenAuthenticatedAttribute] which inherited from [RequireHttpsAttribute]. The idea was that you apply it to your whole site from your global.asax, and then https will *automatically* be turned on (and enforced) when users are logged in.

After posting that code, I got an e-mail from Andy Brown (thanks Andy) pointing out that if a logged in user switches to http by editing the address in their browser, the cookie will have already been posted back to the site by the time my new attribute is able to do anything. To be totally safe you'd have to assume that the cookie is already compromised at that point. I then realised that even if the site signs them out, the cookie could still be used by a hijacker until it times out.  For example, this article says “Even after the user has logged out of the application and the developer has called FormsAuthentication.SignOut, the authentication ticket remains valid until its time-to-live (TTL) expires, so it can be used by an attacker to impersonate another user.” 

So I went back to the drawing board to try and find an even better way.

In the end, the best option seems to be simply using this option when you set up forms authentication in your web.config:

requireSSL="true"

Rather than refer to your whole site, this attribute just applies to the authentication cookie, meaning the the browser should only send the cookie over https. Using that setting does the same job that my code was trying to do, only better. So I don't need any special code after all.

Mock object of death

Following on from my NullOf<T> class, I decided to write something that enables me to throw an exception from any method on an interface.  That meant I could easily write unit tests to check exception handling.  It does a similar job to the “null implementation” of an interface, but allows you to specify that a certain method will raise an exception.  This is what I’ve got:

using System;
using System.Linq.Expressions;
using Moq;

namespace
MyNamespace
{
    public class OfDeath<T> where T: class
    {
        public static T ErrorsWhen(Expression<Action<T>> someAction)
        {
            return ErrorsWhen(someAction, new Exception("It's all gone horribly wrong!"));
        } 

        public static T ErrorsWhen(Expression<Action<T>> someAction, Exception ex)

        {

            Mock<T> mocker = new Mock<T>(MockBehavior.Loose);

            mocker.Setup(someAction).Throws(ex);

            return mocker.Object;

        }

    }
}

You’ll see that there are two overloads; one allows you to specify whatever exception you like (the other makes an exception for you).  Usage looks like this:

 

MyService service = new MyService(OfDeath<ILog>.ErrorsWhen(x => x.Info(It.IsAny<object>())));

service.DoSomething();


So this example throws an exception when you call ILog.Info(), but not when you call any of the other methods on the ILog interface.  Again, it’s generic, so you can point it at other interfaces and make them throw exceptions too.

 

Mocking null implementations of Interfaces

People who know me understand that I like pretty code.  This post describes something that I came up with to make my units tests look more pretty.  Say you want to run a unit test on a service, and normally that service would log lots of stuff (using log4net for example).  But for the purpose of the unit test you just want to throw away all the log entries.  You might use moq, and do something like this:

log4net.ILog logToNull = new Mock<ILog>(MockBehavior.Loose).Object;
var service = new MyService(logToNull);
service.DoSomething();

...which is all very fine; but not especially pretty.  I decided to make it look a little better -  what if we add this class to our project:

using Moq; 

namespace MyNamespace

{

    public class NullOf<T> where T: class

    {

        public static readonly T Instance = new Mock<T>(MockBehavior.Loose).Object;

    }

}

It’s not very complicated, but means that now we can do this:

 

var service = new MyService(NullOf<log4net.ILog>.Instance);

service.DoSomething();

Ahh, we still have a “null” implementation of the ILog interface, but to me saying “NullOf<log4net.ILog>.Instance“ looks just a bit nicer :-) Better than that, it’s generic, so you can use it on other interfaces too.  Null implementations all round then.

 

Acer Iconia Tab W500

My last couple of posts have been made from my new Iconia Tab W500.  Too many evenings have had me sitting on the sofa hunched over a laptop, whilst my wife looks much more relaxed with her iPad.  I'd get an iPad myself - they are brilliant - but you can't program on them, so that is a deal breaker for me.  The Iconia Tab W500 tries to be a laptop and a tablet:

Acer Iconia Tab W500

When in tablet mode it is not as good as the iPad.  The touchscreen pointer does not seem as accurate and you're left feeling that Windows 7 wasn't designed with tablets in mind.  The on-screen keyboard (which is a special version for this machine, not the standard Windows 7 version) is better than on the iPad ... but the less accurate pointer means that you get the wrong key sometimes.  Battery life seems OK when compared to other laptops - I have taken notes on it all day (with careful use of the screen brightness control) and still had some power left.  When I got the machine I did a BIOS update which seemed to make the battery life much better though.

Acer Iconia Tab W500

But ... you can run Visual Studio 2010 on it - so it scores bonus points there for me.  All-in-all I'm quite happy with it, it does what I wanted it to.  Perhaps there will be better Windows based tablets to follow.

Podd can ... drink

Since I have gotten Podd running again, I have been going through the actions, reminding myself how they looked. Currently, the one I like best is 'drink' ... this gives you an idea:

Podd can drink

Nice! I think that I used monochrome sprites, which I recoloured as they were put on screen. Although some stuff was just drawn directly to the screen. I think there was double-buffering too. It was all written in C on RISC OS. Ahh, those were the days...

Oh My Podd

As I have previously reported here, I have been trying to better archive my author's copy of Podd (a piece of educational software that I wrote way back). It would be nice to keep it on a more permanent type of storage.

My plan was to get my copy running in an emulator, but that wasn't easy since the floppy disk it came on was protected by the publisher. My theory was that I could write a Windows driver to install a virtual drive, then run an Archimedes emulator and tell it to get a disk image from my new virtual drive. This would give me the ability to implement some virtual flakyness to keep the protection routines happy.

Well that was the theory. I didn't know if it would really work. I knew I'd be getting somewhere if the Podd program prompted for registration details. If you just make a copy of the original floppy, the program just refuses to run. But I did indeed get it going, look at this:

Podd screenshot

Yay! It works! Well... at first, it failed because the emulator (Arculator) cached the disk image, making my virtual flaky sector code useless. Enter the Red Squirrel emulator, which does not cache the disk content. After some tinkering to get the precise collection of bytes to be flaky we were away.

It has been a nice little challenge. I'll post some more Podd screenshots when I get time.

Archimedes Podd

Back in the early 90’s I was employed to convert a piece of educational software called ‘Podd’ from the BBC Micro to the Acorn Archimedes.  What I actually did was take a look at the BBC version, but completely re-write the code in C for RISC OS.  When the software was released the publisher sent me a complimentary copy, since I was the author.  I carefully put this copy aside for safe-keeping, where it has stayed for nearly a couple of decades.  The 800k floppy disk that was included has never even been inserted into a machine.

Until last week that is.  A friend of mine is restoring his Acorn A3000 (you read about his efforts here). So I decided that he should try and read the floppy to see if it was still intact.  The good news is that the disk seems fine.  My name was even left inside one of the files:

Podd Screenshot

So now we’ve decided to try and make a copy of the disk, before the original is lost for all time.  The only problem is that the publisher used copy protection when duplicating the disks, so I can’t just copy the disk bit-for-bit.  I seem to remember that they used “flaky sector” for copy protection.  So I’ve written some code using the Dokan library to create a virtual drive on my Windows machine.  Then I’ve written a few extra lines of code that takes a disk image file stored on this virtual drive and emulates a flaky sector.  This means that I may be able to create an image of the disk that works on an emulator on top of Windows (like the Arculator).  Perhaps I’ll be able to make an exact image of the disk, including the flaky sector, and maybe my ‘authors copy’ can be properly archived for safe storage…

I don’t know if this will actually work yet, I’ll have to report back.  But it has been a nice trip down memory lane…