Authentication Session Cookie
Most if not all web applications (or entities acting on their behalf, usually fronting them) inject as session cookie into the user’s browser, so the user doesn’t need to log in every time they refresh or access the page. For example, if you go to FaceBook you are required to provide credentials – username and password, sometimes a second factor, but when you go back to your FaceBook page the next day, you are already logged in. That’s thanks to the cookie, which resides inside your browser (client side). Whenever you make a request to facebook.com (open marketplace for example) the cookie is sent, too. Server validates the cookie contents and identifies the user that way.
What is Pass-The-Cookie Attack?
Very simple, you take the cookie from the user’s browser and put it somewhere else. Technically this is very simple and with just a few clicks, you can get to the cookies in the browser. If you copy the right cookie’s contents into another browser (on the same or another device) and request the resources… you will be granted access with no questions asked.
Please don’t panic just yet, the challenge is actually getting to the point where you can get the cookies. They are protected, but not in line with the zero-trust concept, we use perimeter security for those little bits of information. Remember Ocean’s 11 movie? Danny and his crew come up with an elaborate plan how to get into Bellagio’s vault and steal the money. Once they have the money, they can use it and (in principle) no one will ask any questions – cash rules. Same with our cookies.
The Elaborate Plans To Steal
Let’s try to get into Danny’s role in our world of cookies and browser security. How do I steal one from your browser? Remember, we said it’s perimeter security, meaning I have to be inside the circle of trust to get it. In this case – I need to make my way to your device – for example a laptop. But let’s try to think about it with another dimension in mind. It doesn’t mean I have to be sitting if front of your laptop to get inside it. I may use a malicious code like malware or a trojan horse to extract the information or open a back door. I may also send you a mobile charging cable or a memory stick that will inject a payload into your device and in consequence let me get ‘inside’ it from a distance. In the older days, XSS (Cross Site Scripting) was also used to steal the cookies. While we have a lot of controls to protect from XSS, especially client side (modern browsers simply don’t allow it), it’s still possible to steal the cookie that way, too.
Why Pass-The-Cookie?
This type of attack becomes more and more popular for one reason. While we work so hard to harden systems with complex passwords, multi factor authentication mechanisms, even passwordless and biometrics… the ‘key’ to the vault that we issue at the end of the authentication process is still very vulnerable and in this case the weakest link. Without origin protection or as some call Proof-Of-Possession, it becomes a valuable target. No matter how secure the authentication process is, if I have the cookie, I can access the information with no questions asked.
The Origin Protection
By origin protection we mean, that even if you stole the money from Mr. Benedict’s casino, in order to spend it, you have to prove that you were the person who received the money in a legitimate manner. For example, in UK if you’re caught by Police running around with large amounts of cash and there is a suspicion that it may be a proceed from a crime, you may have to prove how you got the money in the first place. And it better be a good one, like withdrawal from a bank or a payment for an invoiced service.
How do we apply this concept to session cookies? Well, in today’s world there’s no 100% method that would allow us to do so, but we can get to confidence as high as… 99.5%.
Continuous Authentication
Vendors need to realise, that JIT (Just-In-Time) authentication is no longer enough. We need to re-authenticate the users throughout the lifecycle of the session, ideally with every call. I know this puts an extra load on the resources, but that’s the reality, at least for critical resources.
It means that, if I request a resource for the first time, I get authenticated. When I request same resource for subsequent time, I get re-authenticated. Re-authentication does not imply asking for credentials, as this would be a terrible experience and would end the SSO concept (Single Sign On), but we may want to re-evaluate the context in which the request is made. For example, geo-location.
The Context – Risk Based Authentication
Imagine I am a Krakozhian hacker and steal the cookie from your device in New York. We all know Krakozhia (if you don’t, watch ‘The Terminal’ with Tom Hanks), is a fair distance from New York. It would require a craft travelling at 2000 mph to make the journey in time. RBA will trigger what’s called an impossible travel signal and raise the risk, so additional controls are required to ‘re-authenticate’ the user. For example an MFA. This is useful and there a few more signals we can look at, but it’s not a 100% method. I would be crazy trying to put a number on it, so not even going to attempt any fortune telling, but put it this way, we can do better.
The Context On Steroids – Device Fingerprint
What if we could distinguish user’s devices with a high level of confidence? Believe it or not, every browser on every device like laptop, mobile or tablet can deliver a unique signature. Once again it’s not a 100% thing, but close. Writing your own algorithm to deliver the signature would be an attempt to reinvent the wheel or a nice science project, but in a commercial setup we have products on the shelf, available to us right here, right now. It won’t be a sales pitch, if I mention fingerprint.com, purely because I used them for testing and a proof of concept. It helped that the service is free for developers. It comes in two flavours – open source/free, with around 50% confidence score (uniqueness of the signature) and PRO – delivered with a whopping average of 99.5% certainty! This level of cardinality almost, well almost allows us to authenticate the users. While it’s slightly more complex than I am trying to portrait here, the concept doesn’t change.
So, here’s how this plays out. You request the resource for the first time. The app challenges you for credentials, MFA, you name it. The app also fingerprints your device and delivers a signature. This signature is then included (encrypted) in your cookie. When you request the resource again, the app fingerprints your device again and compares if that signature matches the one in the cookie. If you copied the cookie to a different browser (Pass-The-Cookie), it won’t match and you will need to log in again. Because the signature is delivered server-side and encrypted in the cookie, by default it’s not easy to tamper with.
Et Voila, we managed to eliminate 99.5%* of Pass-The-Cookie attacks!
*in theory 😉