Play framework security issue regarding cookies and sessions
Play Framework uses stateless sessions. There is no state stored on the server side, rather, all the state is stored in the session cookie. To validate a session, Play signs the sessions using a secret key, and validates the signature when a request with a session cookie arrives. If a user was to tamper with the session data, for example, if they changed the email address in the session to someone else's email address, then the signature would not match, and so Play would reject the session cookie.
Yes, you can copy the cookie and use it later. But you can't change the cookie. This means the only cookie that you can "steal" is your own, but stealing from yourself is not really stealing. So no, you can't steal sessions, except through exploiting other vulnerabilities such as XSS, but session tokens are vulnerable to this too.
By default, Play is configured to create "session" cookies, ie, cookies that expire when you close the browser. So if a user quits out of their browser, the browser will delete all the session cookies, and the user will not be logged in anymore. This is the same for session tokens.
There is one consideration to be aware of, and that is that session tokens also expire on the server because the server holds state. Stateless signed sessions, such as those used in Play, don't. However, you can implement an expiration mechanism yourself, by storing a timestamp inside the session when it is created, and verifying that that timestamp is no older than a configured expiration period in the getUsername() method. Since the timestamp is stored in the session, which is signed, the timestamp can't be tampered with without changing the signature, so this simple mechanism is quite safe. A more advanced solution might be to implement a filter that updated that timestamp each time a request came in, so that expiration could be based on last accessed, rather than when the user logged in.
Your assumption is absolutely correct, you cannot invalidate a session on the server following the Zentask example. Although the session cookie is signed with the private key from the configuration file, the same value produces the same signed cookie. As you already figured out, if someone steals the cookie from a user neither the user nor you (the server) can prevent the thief from "logging into" the user's account.
There are basically two options now:
- Store volatile information you already have about the user in the cookie that only you and the user know and changes from time to time. An example would be part of the password hash. Once the user changes the password, the information is no longer valid and all old session cookies are invalid. A downside of this method: If the user does not change the stored information, the cookie will be valid over a long time, maybe even forever.
- Create a server-side session management. For this you have to have a database, a key-value cache or something similar. In there you store a randomly generated (cryptographically secure) key for the session, the user's name/ID and the date when the session will be automatically invalidated. You can also store the IP address to improve the security against cookie stealing. The session key must then be written into the cookie. When the user clicks on the logout button you invalidate the current session (or alternatively all sessions for this user).