47

I tried to export all my cookies through the 'Edit This Cookie' extension on a logged-in page which uses cookie authentication. While logged out I tried inserting those cookies hoping that I would be logged in, but nothing happened.

After searching I came to know that the cookies sent are in encrypted form. But the page wasn't using any TLS encryption. Am I missing anything?

EDIT: I tried using the same cookies while Logged in i.e exported all the cookies and imported on an incognito window but nothing happened.
Also, this kind of attack doesn't seem to be working on most popular sites like Google, Facebook etc. So how do they protect against such attacks?

Improve this question
3
  • 49
    Logging out should not just delete the cookies but invalidate the current session, that's good practice. So you shouldn't be able to reuse session cookies after logging out.
    – Arminius
    Jan 29, 2018 at 17:27
  • 10
    How did you achieve becoming "logged out"? Did you use a private browser session, did you simply delete the cookies after exporting them, or did you use a log-out button on the web page?
    – Bergi
    Jan 29, 2018 at 19:41
  • The answers below also answer your new edit.
    – schroeder ♦
    Jan 30, 2018 at 14:42

7 Answers 7

Reset to default
59

Technically, even if the contents in the cookie were to be encrypted, if cookies are properly copied to the new browser and the new browser sends the same HTTP headers (same user agent string, referrer is as expected, computer has same IP address, and all other headers the server could have previously stored and and compare against), the server theoretically wouldn't be able to differentiate between the original browser and the new browser.

I'm assuming that you're trying to copy the cookie(s) from a site that auto-logs you on every time you open your browser and you haven't logged out.

Some sites could use other ways to detect if this is a stolen cookie/session, but it's a losing battle because all those can still be spoofed E.g.:

  • Check if the IP address changed
  • Is the User-Agent the same
  • Check if the referrer makes sense
  • Any other HTTP headers that the browser sends

To answer your question, you should be able to make it work if you're dealing with an auto-login site and you haven't logged out. Make sure that all the HTTP headers your new browser is sending are the same, that the IP address is the same, the referrer is the expected one, same user agent.

Note that also perhaps the service you're using is using a 2nd cookie that you forgot to copy, and thus creates an anomaly and kicks you out.

Improve this answer
4
  • 11
    Great answer. Only thing i am missing is timeout - even if the request is exactly the same, the session could have timed out between the two requests.
    – Anders
    Jan 29, 2018 at 22:29
  • Some even use additional nonce to check that you actually used link from previously loaded page but this can also be stolen and does mostly mitigate xss
    – Sampo Sarrala - codidact.org
    Jan 30, 2018 at 4:59
  • This is why the session validation is done server-side. If your token has expired, there is no way for you to fake a valid session, unless you have direct access to the token storage (but at that point, there are FAR bigger problems than simple cookie-stealing).
    – Juha Untinen
    Jan 31, 2018 at 14:54
  • You can start by sending exactly the same headers, then wittle out the ones you don't need. I recently made an app which interfaces to a website's API which I had reverse engineered. It turns out I only needed the session cookie, the referrer and the CSFR token (for posts). I don't even know what user agent I'm sending, probably "Java".
    – Rodney
    Feb 1, 2018 at 14:45
32

The contents of a cookie are application-defined, and there are all sorts of ways to use them. Here is a short list of some of the possible reasons why your effort failed.

  1. The cookie is bound to the IP address, device fingerprint, or other non-cookie data that you didn't capture.
  2. The original cookie contains an expiration and it has passed.
  3. The cookie is single-use, i.e. the server rotates the value with every request/response and invalidates any cookie value that has already been used.
  4. The cookie was bound to a session that no longer exists on the server (potentially because you logged out).
  5. The cookie is paired with a hidden element within the page (e.g a CSRF token) and you didn't capture or recreate that value.
  6. The server is load-balanced, with session state in proc and a temporary session stickiness mechanism enforced by the load balancer. In your new session, your client was assigned a different node within the farm where the session doesn't exist.
  7. The web server uses a rules engine to detect suspicious activity, and your spoofed cookie was presented out of sequence or at an unexpected time.
  8. The cookies were fine, but you messed up some other detail, such as the referrer header.
Improve this answer
29
  1. The cookies themselves may have been signed or encrypted, not the connection that delivered them.
  2. The server may have removed the session from it's database when you logged out.
Improve this answer
12
  • 7
    Also note that sessions are sometimes bound to more than just the cookie, such as user agent or IP address. If those change, the cookie also might not work.
    – Chris
    Jan 29, 2018 at 19:31
  • 3
    Only one of these is true.
    – micheal65536
    Jan 30, 2018 at 8:43
  • 13
    @Naim Signed or encrypted cookies won't prevent an attack that involves copying the cookies directly.
    – micheal65536
    Jan 30, 2018 at 9:16
  • 2
    @Naim Signing the cookies enables the server to check that they haven't been modified (badly-made sites sometimes stored the user ID in the cookie, and the user could access someone else's account by changing the stored ID) but if your cookies store only a session ID (which is all that they should store) then again this isn't necessary. Needing cookies to be either signed or encrypted is indicative of bad design elsewhere.
    – micheal65536
    Jan 30, 2018 at 9:17
  • 6
    Could you please expand on #1? I don't see how encrypting/signing the cookie contents can prevent session hijacking (which is essentially what the OP tried to do on himself).
    – Bergi
    Jan 30, 2018 at 10:25
8

As mentioned, when you logged out, the server invalidated the cookie you just stole, making it worthless for trying to pretend to be yourself.

So if you want to truly test trying to steal your cookies to test what is needed to steal your session from this particular web-service, you will need to export your cookies and import them into a new browser/incognito mode without logging out in your original browser tab.

But, just to note, cookies are also often checked against a slew of other criteria. We can check against IP, user-agent, etc. https://wingsdream.wordpress.com/tag/mitigating-http-session-hijacking/

We could also devise even more clever strategies, like a system of continual refreshing of tokens or browser fingerprinting, to double check that the person in possession of this cookie is the person that we gave that cookie to, and that it wasn't stolen. So, even if your 'steal' the authentication cookies, you still may not be able to authenticate with them.

Improve this answer
4

The session was invalidated on the server. Secure websites do this to prevent exactly the kind of attack that you're describing. When you log out, the server deletes the session from its own database so that even if the same session cookies were used again they won't be accepted by the server. This is why it's important to properly log out from the website instead of just closing your browser, even if your browser doesn't keep the cookies.

Insecure websites may leave the session lying around on the server so that even once you've "logged out" (i.e. deleted the cookies from your browser), the same session cookies can still be used again later.

Try repeating your experiment, but this time don't log out beforehand. Log in to the website and then manually delete the cookies from your browser. If you visit the website again without the cookies, you won't be logged in. Now restore the cookies and try visiting the website again, and you should be logged in again.

Improve this answer
1

For simple sites copying the cookies should be enough. More "secure" site pin your session as others mentioned to other factors such as IP.

There is also the possiblity that there is some javascript code which checks other persistent values like Local/Session Storage, IndexDB and so on. Try to have a look at them. It would also be possible that this is an single site application where all data is loaded via ajax and oAuth together with a form of persistent storage is used. No cookies needed since the secret is stored elsewhere.

Improve this answer
0

In many cases stealing cookies IS enough to authenticate, chances are that you did something wrong.

Note, TLS/encryption are not relevant here. By the time you're reading the cookie from the header, the traffic has already been decrypted. Everything chrome shows you is already decrypted, encryption is entirely transparent.

To answer the question. Authentication schemes vary. Sometimes they only use cookies, in which case stealing them will be enough. Sometimes they don't use cookies at all. Sometimes they use a mix of cookies and other data.

There are infinitely many cookie schemes. There is no simple answer for all of them.

Improve this answer

You must log in to answer this question.

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