Why doesn't Tornado have session

Question

I've heard that cookies is less secure than the session.
For example, if a web uses a cookie to detect if an user has logged in or not, people can forge a cookie to simulate a false user because he can read the cookie and forge one easily. Here is a link that I've found: Session vs Cookie Authentication

Now I'm using Tornado with python to build a website. Here is a simple example of the module of login with Tornado: https://stackoverflow.com/questions/6514783/tornado-login-examples-tutorials
To my surprise, there is no session in Tornado. Its doc says that there is the secure cookies but I don't think it is safer than ordinary cookies.

ordinary cookie:

browser ------- I'm Tom, my password is 123 -------> server

secure cookie:

browser ------ &^*Y()UIH|>Guho976879 --------> server

I'm thinking that if I could get &^*Y()UIH|>Guho976879, I can still forge the cookie, right?

If I'm correct, why doesn't Tornado have the session? Or is there some way that can make the secure cookie is the same secure as the session? Maybe that I erase the cookies when the browser is closed can be safer?

Answer 1

I've heard that cookies is less secure than the session.

You must have misinterpreted something. In fact HTTP sessions are usually implemented using cookies.

I'm thinking that if I could get &^*Y()UIH|>Guho976879, I can still forge the cookie, right?

Sure you can change the cookie, but will it be accepted by the server as valid? If you take an actual look at the documentation you'll see:

Cookies are not secure and can easily be modified by clients. If you need to set cookies to, e.g., identify the currently logged in user, you need to sign your cookies to prevent forgery. Tornado supports signed cookies with the set_secure_cookie and get_secure_cookie methods. ...
Signed cookies contain the encoded value of the cookie in addition to a timestamp and an HMAC signature. If the cookie is old or if the signature doesn’t match, get_secure_cookie will return None just as if the cookie isn’t set.

Thus, if you try to manipulate the secure cookie the framework will notice and treat the cookie as invalid, i.e. like the cookie was never sent in the first place.

Answer 2

I think the other answers fail to address the primary attack which is being protected against here, which is not forging the cookie, but tampering with it, or inspecting it.

If you send a cookie to a browser saying "current_user=tom", the user can send you back an alternative cookie saying "current_user=dave". If you have nothing to validate the cookie against, your application will assume they are logged in as "dave".

This could be mitigated by signing the cookie using a secret key - the tampered cookie would not have the correct signature, so would be rejected.

However, there may still be a problem: if part of the state you want to store is secret. For instance, you might want to store the cost price and markup of the products in the user's basket; clearly a plaintext cookie that the user can read is not appropriate here.

This leaves you with two solutions:

• Encrypt the contents of the cookie, so that it can be neither read nor amended without knowing the private key.
• Store the actual data locally (e.g. in a disk or memory store) and send only an identifier in the cookie. This is generally known as "session data".

Sessions are relatively easy to implement and are provably safe against these particular attacks. However, they place burdens on your back-end infrastructure, because your web / application servers need to be able to write and read the data; this can be tricky in complex load balancing setups, for instance. As such, encrypting a small amount of data directly in the cookie may be a sensible alternative, since now the only data that needs to be shared between your application servers is the private key.

Note that neither of these protect directly against other attacks, such as hijacking, where a malicious user simply clones the cookies from a genuine session. Session tokens may also be vulnerable to a related attack called "session fixation", where an attacker chooses the identifier before a genuine user connects, and can thus create identical cookies to them; this would not be possible with an encrypted cookie, but I'm sure there are other attacks unique to it in turn.

Answer 3

The question you've found doesn't really describe what (I think) you're referring to. The difference they are describing is whether the user's session information (so things like what item is in their shopping basked for example) server-side and only pass a unique identifier (a.k.a session cookie) to the client, or whether to store the whole thing on the client.

All web applications have to have some mechanism of maintaining state. HTTP is stateless by default, so there is no way for a server to correspond one request to another.

The way that most applications solve this is to use cookies. The security challenges of using cookies are well understood and, if correctly implemented, they shouldn't cause significant security issues.

The other options for doing this are generally authorisation headers, so either using HTTP digest or NTLM auth. which is more common in internal corporate applications, or to generate those headers using JavaScript (which you see with some modern Single Page applications).

Regardless there needs to be some information passed from client to server with each request to identify the user.

As to forging cookies, usually a session token will have a large degree of randomness so it's not practical to forge a cookie value.