Hacker News Reader

Comment by radiospiel | Hacker News Reader

While the leaked data is probably not cool and shows internal information which a client should never see, the alarmist tone - HACKED! NO SSL! - is not approbriate here… I think this is "just" a dumped HTTP GET request between the SSL termination and the ultimative server (and not, as the article assumes, some data from some client).

View on HN

I think the point is that the debug is leaking sessionid cookies, which could be transplanted into your browser to fake a session.

I think that these are bound to the user's own session, which is already in the browser cookie.

He would not have been able to hijack any sessions with this information, as he claims. Danske Bank, like all banks in Denmark, uses the government's public key infrastructure for authentication (based on one-time pads which all citizens receive by mail).

Sloppy but pretty much a non-issue.

Two points.

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.

Session management and authentication (PKI / one time pad) are two complete different subjects. If a session cookies is leaked from a customer, then authentication checks can be bypassed completely. So certainly an issue.

You are confusing how the attack is done. PKI has nothing to do with it. Try this with Chrome -

1) Log into a site on one computer

2) In the javascript console (tools->developer tools) type 'document.cookie'

3) On a separate computer visit the same site but don't log in. Open the javascript console.

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.

Reply on news.ycombinator.com