Hacker News Reader

Comment by espeed | Hacker News Reader

A few days ago I asked, "Ask HN: Best Approaches to Prevent Session Hijacking?" (http://news.ycombinator.com/item?id=2663293) and presented a technique I'm experimenting with that uses session timestamps as tokens to validate that each request is authentic and an attacker hasn't stolen the session key.

It works by updating the token (timestamp) on the server and in the cookie on each request and they both have to match on the next request. A short buffer (say 30 seconds) is permitted to avoid false positives from click-happy users on slow/flaky connections.

Has anyone used this technique in production?

View on HN

How do you mitigate problems with a user opening multiple tabs over a span of time, and attempting to submit the first one opened?

I believe the best practice is to provide the user's session id in their cookie and provide that with the requests via javascript or even at the time of page rendering. Since a third party (untrusted domain) cannot access information from your cookie, they also cannot form a valid request.

This method is called double submitting cookies.

See: https://secure.wikimedia.org/wikipedia/en/wiki/Cross-site_re...

A session is shared between multiple browser tabs so this shouldn't be a problem. If the user opens a new tab/browser in incognito mode, then the browser will ask them to login in again b/c it can't read their session to authenticate their identity, and then when they login they will have two separate sessions going, each with a unique token/timestamp so multiple sessions isn't a problem either.

My bad, I thought the timestamp was being inserted into a form ala Rails' authenticity_token method in a way that would allow it to go stale if a new request was submitted in a new tab.

Although this makes sense, I feel it is not as safe as double submitting cookies, which effectively creates pseudo-random requests, but should still be safe enough in practice.

If you double submit on each request, this will double the number of requests on your server and reduce your server's capacity. And isn't all JavaScript subject to being subverted in XSS attacks, thus potentially rendering it ineffective?

In double cookie submission, you are not issuing two requests to the server, but rather using javascript to append the session id to either the post body or the URI.

Since the browser automatically submits the cookie via HTTP Headers, single submission by itself is not safe. Since a third party cannot read the value of the cookie, they cannot recreate the proper request and will, consequently, fail.

Of course, both our methods will fail under an XSS, but should still prevent CSRF. I still think a cryptographically generated secret stored in the cookie is less guessable than a timestamp.

The timestamp, session_id and user_id are tucked away in an AES encrypted bundle with a SHA-1 signature.

How much does running everything over HTTPS mitigate this cross-site stuff?

It doesn't. HTTPS mitigates passive sniffing and most MITM attacks but does not have any effect against cross-site script attacks such as CSRF and XSS.

Reply on news.ycombinator.com