3

I am looking for an event to automatically logout a user from the application. Typically I would do it when an inactive session expires. I was wondering if it is secure to do so using cookies. So here are my questions,

  • Is it secure to have logout algorithm tied cookie expiry?
  • Can the expiry date/time of the cookie be manipulated by the client?
  • If manipulation is possible does it hold true for "secure" cookies (Secure / HttpOnly flag set)
4
  • 2
    any data that you send to the client can be manipulated
    – schroeder
    Commented Aug 12, 2015 at 19:02
  • 1
    from the application and from the application. ?
    – user45139
    Commented Aug 12, 2015 at 19:09
  • 1
    google 'cookie tampering'. One example -> infosectoday.com/Articles/Cookie_Tampering.htm Commented Aug 12, 2015 at 19:10
  • Thank you for the link. Do these attacks apply to 'Secure' cookies?
    – Y123
    Commented Aug 12, 2015 at 19:22

1 Answer 1

6

Session state within an application should ideally be managed server-side from a security perspective.

So in terms of expiry a list of active sessions should be stored and they should be removed from the server after an agreed period of inactivity (exactly what this would be depends on the application sensitivity, user base etc)

The application should also offer an explicit logout facility which terminates the users session server-side.

If you rely on a client-side measures (e.g. cookie expiry) there is always the risk that an attacker will get access to a cookie and replay it after the expiry has passed. If your application is unable to tell whether that cookie should still be valid then this may expose it to unauthorised access.

In this case the use of cookie flags (e.g. secure, httpOnly) may reduce the risks of an attacker compromising a user's session token, but don't remove the central issue that the server can't tell whether the cookie should still be valid or not.

It is possible to handle session expiry without holding state on the server by using cookies which are protected from tampering and store the expiry date/time within them (e.g. ASP.NETs default session management) but this suffers from the weakness of making it hard to allow users to explicitly terminate the session prior to the time stored in the cookie.

2
  • Thank you (Voted up) - I had one follow-up question. You have stressed the use of sessions on the server side which I agree with, but when you talk of sessions in a Java based servlet container the session management involves either cookies or URL Rewriting. Doesn't that in some ways defeat the security of managing this on the server side?
    – Y123
    Commented Aug 12, 2015 at 20:56
  • 1
    well you need a cookie to tie the requests to an existing session, the point was more that security decisions relating to expiry of the token should be made on the server-side and not relying on a client-side element, like cookie-expiry. Commented Aug 12, 2015 at 21:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .