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)
  • 2
    any data that you send to the client can be manipulated – schroeder Aug 12 '15 at 19:02
  • 1
    from the application and from the application. ? – user45139 Aug 12 '15 at 19:09
  • 1
    google 'cookie tampering'. One example -> infosectoday.com/Articles/Cookie_Tampering.htm – Oleg Mazurov Aug 12 '15 at 19:10
  • Thank you for the link. Do these attacks apply to 'Secure' cookies? – Yazad Aug 12 '15 at 19:22
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.

  • 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? – Yazad Aug 12 '15 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. – Rоry McCune Aug 12 '15 at 21:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.