1. The server was programmed to dump the most recent available session data, and presumably a lot of users were accessing the site concurrently. This would not be the case in development and thus, during dev, their devs would be seeing only the current session's information.
2. Someone intentionally planted this backdoor.
I hope it is the first case. Because if it is not the second case, it would take some really really apparent mistake or an extremely horrible debugging fashion to match the described behavior.
Why the random visitor technical details were shown is a really good question. I have spent quite some thought time on that also and couldn't come up with a solid answer.
Sloppy but pretty much a non-issue.
1) Log into a site on one computer
4) Paste in the cookie, i.e document.cookie="keyofcookie=valueofcookie"
5) See if your authenticated using the account you 'stole' the cookie from without actually having to authenticate on the second computer
(Rather then using two computers, you could use two different browsers on the same computer)
Nowhere here was PKI used.
One way to mitigate this type of attack is to store the users IP address server side and detect if they change IPs during the same session.
One) Can you please provide technical citations to support this? OTP and PKI are very different technology, and the only way I can make sense of your statement is to guess that the OTP is actually a one-time-password (not a one-time pad) used to initialize the user's PKI account.
Two) If the server is leaking data the user authentication is rendered pretty much irrelevant - and PKI with a one-time initialization code would be used for authentication. PKI may also secure the connection, e.g., using SSL/TLS, but it seems that in this case the server was being most dumb - even if my connection were secured using TLS and the best authentication in the world, it seems I would be able to get your data. Which I am sure you wouldn't want. Nor would you be much mollified by knowing exactly who it was that compromised you.
Actually, as a bank, you only need to be slightly more secure than your competitors.
Moreover, you will never need to be unbreachable; many times I have seen banks not fixing vulnerabilities, simply because these vulnerabilities were not profitable enough for attackers to exploit.
No joke, zero ATMs worked, zero CC machines worked, the entire country's electronic monetary system was completely shut down. Nobody in the country could do anything until they brought it back up 4 hours later.
Apparently this happened several times this year (including Valentines day, one of the biggest economic weekends of the year) with little press and no responsible party blamed.
Being a software dev, first I was lamenting the irony of a "secure" central banking system, then my mind went straight to how screwed I'd be if I wrote the code that brought that down. Now I have a little more perspective and don't feel any better.
However, it's at best a non-issue, because CC terminals can be put in "offline mode". So you can still pay, but the transactions will first be synchronized when the line is back up. So until that, they're stored on the CC terminal itself.
HOWEVER when running in offline mode, the shops will pay a larger transaction fee. Also there are some risks, e.g. the transactions are lost if something happens to the CC terminal, and furthermore, the shop cannot verify the card (which is automatically done when it's online).
So unfortunately, many shops don't want to enable it..
However, the problem relies in Nets itself. They control the credit card systems in Denmark, have monopoly on "Dankort" which is the danish equivalent to Visa (actually you normally get a Visa/Dankort hybrid so that when you're abroad, you use the Visa-part of the card). Nets also controls NemID, which is the Danish authentication method for public stuff (one-time passwords).
They have been criticized, but IT in Denmark is run by morons (sorry..).