> I can just set my cookie to $their_session_id:$hmac_of_their_session_id
If you can steal somebody else's cookies (which are not Channel-bound) then that's true. If you can only steal or predict somebody else's session ID's, the HMAC provides protection.
It's not atypical for session IDs to be simple counters that get incremented for each new session. If your session ID is 100042, it's a pretty good bet that 100041 and 100043 are valid session IDs as well, and without HMAC, a user could take over these sessions trivially.
The even better mitigation to cookie theft, which I also mention, is TLS ChannelID.
ChannelID creates a unique private/public keypair for each new TLS connection, and sends the public part along in the TLS handshake. Then, when you resume sessions from the same machine, you can prove that you have the private part and the server can accept your existing cookies. With this approach, cookies are no longer bearer tokens and stealing cookies becomes worthless.
This can be hardened even against local malware running as the same principal as the user doing the browsing if the browser's ChannelID implementation generates and stores the private key inside a TPM or HSM.
> If you can steal somebody else's cookies (which are not Channel-bound) then that's true. If you can only steal or predict somebody else's session ID's, the HMAC provides protection.
Session fixation. You don't need to steal any cookies. The attacker can plant his own session ID cookie in the victim's browser using the OP exploit. Using signed cookies doesn't change this attack at all.
If you can steal somebody else's cookies (which are not Channel-bound) then that's true. If you can only steal or predict somebody else's session ID's, the HMAC provides protection.
It's not atypical for session IDs to be simple counters that get incremented for each new session. If your session ID is 100042, it's a pretty good bet that 100041 and 100043 are valid session IDs as well, and without HMAC, a user could take over these sessions trivially.
The even better mitigation to cookie theft, which I also mention, is TLS ChannelID. ChannelID creates a unique private/public keypair for each new TLS connection, and sends the public part along in the TLS handshake. Then, when you resume sessions from the same machine, you can prove that you have the private part and the server can accept your existing cookies. With this approach, cookies are no longer bearer tokens and stealing cookies becomes worthless.
This can be hardened even against local malware running as the same principal as the user doing the browsing if the browser's ChannelID implementation generates and stores the private key inside a TPM or HSM.