Session hijacking -- easy fix?

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Roja wrote:
nielsene wrote: Hmm? If a user gets another user's session id, game over. There is nothing else to match. Unless you're sending a second cookie/GET based authenticator to compare against?
I usually suggest to do so, yes.
As a user who has my browser to ask me whether or not I want to accept a cookie, I severely dislike sites that shower cookies upon you (especially the ones that are like: Site would like to send a cookie named "test"). Adding extra session cookies helps, but only to a small extent after the second, because if they got one cookie, then they've probably got them all. (of course, there's other ways to get session ids).
You said: HMAC(sessionID,expTime).

Thats not a server secret, and yes, the attacker can generate that same HMAC, so no, its not secure.
I think he meant HMAC(sessionID,expTime,serverSecret)
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

Roja wrote:
nielsene wrote:Hmm? If a user gets another user's session id, game over. There is nothing else to match. Unless you're sending a second cookie/GET based authenticator to compare against?
I usually suggest to do so, yes.
Well in that case, I'd care less about the protecting the session authentictor and more about the username authenticator, and in that case I would include an explicit expTime if it wasn't an emphemeral cookie.

nielsene wrote: Incorrect. An HMAC is a secure hash, designed to detect tampering of the protected contents.
Not the way you are using it isn't. An HMAC is only secure when the contents of the secret aren't known. Since the attacker knows one of the secrets, and can guess the other one, the HMAC becomes a plain hash - not secure. Its repeatable on both sides.
nielsene wrote:And is constructed using a server secret. The attacker can not generate a hash of an arbitrary session id that will succeed.
You said: HMAC(sessionID,expTime).

Thats not a server secret, and yes, the attacker can generate that same HMAC, so no, its not secure.
No I didn't, I said HMAC(sessionID.expTime) (concatenation) my implementation of HMAC pulls the server secret from a constant, not from an argument. So it is sstill an HMAC and not a simple hash.
nielsene wrote:
Roja wrote:Alternatively, you can use a solution that works regardless of SSL's presence: session regeneration, limited session times, and db-driven sessions.
Again, incorrect. Those merely narrow the temporal window for a sniffed attack. (Yes the DB one limits the shared host problem as well.) Session regeneration/limited session times can't distinguish a sniffed token from a valid token, even if using a nonce, as the attacker may submit before the user.
"Narrowing the window" is accurate, but also understating the value. The window may be impossibly small. For example, if I do a session regeneration upon login, and you sniff my session immediately before, we might be talking about a window in miliseconds.
Only when you have the seperate username authenticator token. Without that you have no session protection.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

Ambush Commander wrote: As a user who has my browser to ask me whether or not I want to accept a cookie, I severely dislike sites that shower cookies upon you (especially the ones that are like: Site would like to send a cookie named "test"). Adding extra session cookies helps, but only to a small extent after the second, because if they got one cookie, then they've probably got them all.
I completely agree. Anything beyond sessioncookie (which, being temporary, wont prompt you in some browsers), and a username token means you are doing something wrong.. ie, store it in the db instead.
nielsene wrote:No I didn't, I said HMAC(sessionID.expTime) (concatenation) my implementation of HMAC pulls the server secret from a constant, not from an argument. So it is sstill an HMAC and not a simple hash.
Even with concat, its not a secret. Now, if in fact there is an additional secret, which you aren't listing in that equation, thats different. In the scenario, sessionID is known, expTime can be reliably guessed, and a concat of the two isn't exactly rocket science. Which server secret are you talking about?
nielsene wrote:Only when you have the seperate username authenticator token. Without that you have no session protection.
Again, don't mistake "less" protection with "no" protection. Even without the username token, you are still dramatically reducing the window for attack with session regeneration. Granted, thats still leaving an exploitable window, but its smaller, and thus, it is more protection. (And it is industry best practice to persue that smaller window).
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

Roja wrote:
nielsene wrote:No I didn't, I said HMAC(sessionID.expTime) (concatenation) my implementation of HMAC pulls the server secret from a constant, not from an argument. So it is sstill an HMAC and not a simple hash.
Even with concat, its not a secret. Now, if in fact there is an additional secret, which you aren't listing in that equation, thats different. In the scenario, sessionID is known, expTime can be reliably guessed, and a concat of the two isn't exactly rocket science. Which server secret are you talking about?
No the concatenation is not the secret, simply part of the protected payload. There is a server-side, rotated hash secret (depending on the server using /dev/random, etc). HMAC, to me, always implies such a server secret. I'm sorry I wasn't explicit about that earlier. I think we've been argueing this issue at cross purposes.
nielsene wrote:Only when you have the seperate username authenticator token. Without that you have no session protection.
Again, don't mistake "less" protection with "no" protection. Even without the username token, you are still dramatically reducing the window for attack with session regeneration. Granted, thats still leaving an exploitable window, but its smaller, and thus, it is more protection. (And it is industry best practice to persue that smaller window).
I'm not mistaking it. Simply stating that there are many situations where you don't have a log-in, but do have a session. In those cases your method doesn't help. Modifying the single session token to be tamper resistant is a worthwhile goal, in and of itself.
Post Reply