I came across an interesting issue on a test the other day. I’ve never heard of this before (or come across it for that matter), so I am going to call it “Reverse Session Fixation” which describes it quite well.
The site used ASP.NET and had quite a common problem where the developer had (presumably accidentally) used ASP.NET_SessionID as the only session token (instead of using .ASPXAUTH). The consequence of this is that by default (and also by Microsoft’s design) the token doesn’t change when the user successfully authenticates, and it often can be set to a fixed value which then also doesn’t change.
In other words, if I manually create a cookie in my browser and set it to ‘ASP.NET_SessionID=aaaaaaaaaaaaaaaaaaaaaaaa’ with the correct host, then when I log in, it stays the same, and the classic consequence of this is that another user who has tricked me into setting the cookie knows its value and can therefore piggy-back onto my session whenever I am logged in.
But in the case of this particular site (an online shop) there was another interesting consequence. Given an attacker who knows that the victim is already using a session identified by the server as ‘bbbbbbbbbbbbbbbbbbbbbbbb’, he sets ASP.NET_SessionID in his browser to be the same value and then logs on. On this site, this caused the victim’s browser to acquire the attacker’s session (I suspect this may be the normal behaviour in this case because it is hard to see what else the server would do), with the consequence that when the victim then purchased something from the site, he was actually purchasing it for the attacker whose identity he had been tricked into taking on (although he was paying for it himself as the credit card details were not held in the site and had to be manually entered).
This is an interesting effect and illustrates another danger of mixing up the functionality of the two .NET cookies.