Let's say I used a malware or some other method that will get my hands on the victim's encrypted cookie, encrypted because the victim was using SSL/TLS. Is it possible to (re)use that cookie and impersonate the victim? If not, is there anyway to get the encryption key and use that too?

  • 1
    If the person was using SSL/TLS, how do you know what is the message that you got? How do you know that it's a plaintext cookie encrypted by SSL or an encrypted cookie encrypted by SSL?
    – Limit
    Oct 2, 2016 at 6:49

3 Answers 3


If the victim was using TLS, you either weren't actually able to get the cookie at all - all you would see in that case is a handshake followed by a stream of encrypted traffic (ciphertext), with no way to identify "this part is a cookie" - or you were able to Man-in-the-Middle (MitM) them due to bypassing certificate validation somehow (or having a fraudulent certificate). Or maybe you stole the cookie some other way (a memory leak out of the client or server? XSS on a non-HttpOnly cookie?) and can't actually read the client's network traffic.

In the first case (network attack against client using TLS), even if you somehow identify which bytes of the TLS ciphertext are the cookie, it won't do you any good. You don't know how to decrypt the cookie, and TLS uses different keys for every encrypted session so if you tried just replaying the message the server wouldn't decrypt it to what you thought it as supposed to be.

In the second case (successful MitM on the TLS connection, or no TLS at all), you can definitely reuse the cookie. Same goes for the third case (cookie stolen via side-channel attack). Anything that gives you the cookie in plain text will let you use it, unless the server does some additional filtering (like tying each session to an IP address, and you're not on the same external address as the attacker... but this is very uncommon).

  • How about using a malware to get the cookies?
    – mzcoxfde
    Oct 2, 2016 at 7:49
  • 1
    That's a side channel (third case of the categories above). To quote myself: "Anything that gives you the cookie in plain text will let you use it".
    – CBHacking
    Oct 2, 2016 at 7:51

You question is extremely broad, I'm trying to answer anyway.

  1. session cookies and https have absolutely nothing to do with each other. https uses TLS which means "Transport layer security". The transport layer is encrypted. Session cookies are sent on the application layer. The application receiving the cookies has usually no knowledge about how it got the cookie.
  2. Whether or not a stolen cookie can be used for something depends on the application using the cookie. None can generally say yes or no. The application might store the IP address of the client in the session and reject you if you have a different one. It might use other cookies or http headers for plausibility. There are so many possibilities why it might not work to just replay the stolen session.

However that said I don't doubt that there are many applications that just simply take the session cookie they get and map it to a user/session without any more intelligent checking. So attacks on session cookies should be taken seriously.

  • Not 'absolutely'; (HTTP) cookies have an optional 'secure' attribute that causes the client (browser) to send them only over HTTPS; see stackoverflow.com/questions/13729749/… . Although the application layer doesn't know the details of the SSL/TLS cryptography (ciphersuite, certs, keys, etc). Oct 2, 2016 at 9:26

Short answer: Probably

Long answer: Assuming that you somehow have access to the unencrypted cookie (I dont know how you are going to do this if they were using SSL), it is quite likely that you will be able to impersonate the user of the site. But be aware that some sites may check other headers (including the user agent) to ensure you are using the same browser to improve security.

You must log in to answer this question.

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