Re: Replay attacks with cookie session

Brad Ediger
2007-03-22T19:29:40Z

On Mar 22, 2007, at 2:21 PM, Jeremy Evans wrote:

>
> On 3/22/07, Brad Ediger <brad@bradediger.com> wrote:
>>
>> On Mar 22, 2007, at 1:53 PM, Courtenay wrote:
>>
>>>
>>> On 3/22/07, S. Robert James <srobertjames@gmail.com> wrote:
>>>> On Mar 22, 10:44 am, Brad Ediger <b...@bradediger.com>
wrote:
>>>> Now, I click "Log Out", and get up from the
library''s computer,
>>>> only
>>>> to let the person waiting after me to retrieve the old
cookie....
>>>> That
>>>> innocuous user id just became both sensitive and transient.
>>>
>>> You click ''log out'' and it deletes the cookie.
>>> This is no different to a normal server-based session.
>>
>> Oh, but it is. With a server-based session, I "Log Out" and
my
>> session can be purged from the server, leaving the old session ID
>> worthless. With cookie sessions, the cookie is still valid to the
>> server even if deleted from the browser''s cookie repo. There
is no
>> way to selectively expire sessions from the server.
>>
>> Server-side: someone gets my session ID, I log out, they present the
>> session ID to the server -> worthless.
>> Client-side: someone gets my session cookie, I log out, they present
>> the cookie to the server -> impersonation!
>
> It''s possible mitigate the problem somewhat by having an
expiration
> time put into the session (which cannot be modified by an attacker due
> to the HMAC).  However, you still won''t be able to manually expire
> sessions (i.e. log out).

This is the best idea I''ve seen so far, but it still requires
balancing the attack window (as small as possible) against the
maximum allowed time between requests. Given that replay attacks can
be automated, the acceptable values for these numbers may or may not
overlap, depending on the application.