Is ProtonMail implemented a mechanism to prevent cookies stealing?
I want to check if I can steal my own ProtonMail cookies. I connect to my account, I delete the cookie named
AUTH-x12334xxxaazzzrf6567788ddd(cookie name is randomized name). I refresh the page and as expected, I am disconnected. It means that cookie
AUTH-xxxx...is a session cookie.
I connect again; I have a new cookie. I copy the name, the content and the path (
/api/) of the cookie. I paste this cookie into a new private Firefox window (With F12 and storage --> cookies) but I am not connected.
How is it possible? Has ProtonMail implemented a mechanism to invalidate a cookie after a first usage? It's the first time I have seen such behaviour on a website.
A (specific) : I'm not getting the same results as you are. I can take the session and AUTH cookies, and re-use them in a terminal window to
curlfor the Conversations JSON payload (among others).
I can even remove the cookie called
Session-IDand it still works. I will note that I deleted the header called
x-pm-uidand the subsequent request failed. Maybe you've missed that one in your custom user agent?
For others that may be unaware, to achieve this, I opened DevTools (as described in my rather condescending comment
8Dand thanks to @mti2935 for F12), performed a login against https://dev.protonmail.com, found an appropriate network event after login was successful, then right-clicked, and selected Copy -> Copy as cURL.
(Note: I tested against dev.protonmail and also mail.protonmail - both worked in parallel, in the same manner.)
A (hypothetical) : Without having put any decent amount of thought into this, my idea to try and force users to continue to use the device they authenticated on would be to cryptographically bind the AUTH session cookie to various properties of the remote user's session and software: this would no doubt look similar to browser fingerprinting techniques.
I would then also re-encrypt the AUTH cookie each time with AEAD. The nonce would encode the number of times the cookie has been used. I would look at deriving this from a short timestamp combined with a pseudo-random seed that becomes an incrementing counter^. The server would need to keep a local copy of the counter and seed, as a session variable, so as to avoid replay and nonce-reuse. Any attempt at regression would invalidate the protocol instance and force another login.
All of this could be side-stepped, of course, however, it could be made to be quite painful to achieve for the average joe... sons and daughters of any dev coding a new UA would curse my name for generations to come... aah, infamy! ... but I digress. It would no doubt thoroughly p*** the users off as well, as they had to keep logging in any time they resized their browser window or idled and then reconnected to the server!
^ (The main reason why you would do it this way is to further frustrate any attempt to lift the AUTH cookie. The server could derive the seed from the authentication and the timestamp using some keyed hash, and then increment this as each iteration of the protocol progresses. Here is an unrelated but quite interesting tangent on visualising un/predictable TCP sequence numbers Zalewski '01.)