9

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?

  • 6
    As an aside, the term "session" is very overloaded in web dev. But what I believe you're thinking of here (and read about) is server-side session storage, where you have some per-user information stored either in memory or a database. Then this is somehow mapped to the user (most commonly with a cookie that simply contains a session ID). Some web frameworks automate this for you so you can simply store data in a dictionary and it automatically handles that cookie and all. – Kat Sep 5 '17 at 19:51
  • 2
    But all that said, you can implement this yourself, obviously. You really just have either a DB table or a hashmap of session IDs to whatever arbitrary data you want to store, and expire those sessions at some point. You can also just store all the session data in a cookie (or local storage, if JS access is all you'd need). Remember that cookies get sent with every request and sometimes you might have a bit to store in the session (or don't want the user to know what you store!). – Kat Sep 5 '17 at 19:54
26

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.

  • 7
    This reminds me of a discussion I had just two weeks ago... someone had told me that cookies were not safe for determining identity and that we need to use something more secure like a session variable. It was like saying we can't use granite to defend our city, we need castle walls! What do you think you build those walls out of?! He did also say that any data in it needed to be hashed for security reasons... I had to give up and just wish him luck with his project. – corsiKa Sep 5 '17 at 22:42
  • @corsiKa "Here's a pile of granite, it will keep us safe." -> Army walks around granite -> "Hm, maybe we should have built a wall." Just because the granite / cookies is a necessary ingredient for the walls / session, doesn't make the two equivalent, so I don't think "sessions are more secure than cookies" is as nonsensical as you seem to be claiming. – IMSoP Sep 7 '17 at 12:47
7

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.

  • 1
    Wonderful answer. – Yves Sep 5 '17 at 16:41
1

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.

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.