In the previous articles of this series we discussed basic concepts of cookies. How to view and edit cookies, types of cookies such as session cookies and third party cookies, etc. If you haven’t read the first two parts of the blog, I recommend reading part 1 and part 2. In this blog post we will discuss the security specific flags of a cookie as promised viz, Secure, HttpOnly and SameSite.
Why cookie security is necessary? Should we actually protect it? Ever thought what will happen if someone steal your cookie? Let’s experiment with that. Let’s login to some website and steal your cookies and see what happens.Let us use OwnCloud’s demo website, open a new tab and browse to https://demo.owncloud.org. Type test/test as login credentials and press submit. Get your EditThisCookie Extension ready, let’s play like a hacker.
I am using Chrome, so I will go to EditThisCookie extension and view the cookie information of this website. This website uses two cookies to track the user’s session namely oc9h6pkm5pd2 and oc_sessionPassphrase. Fine, let’s copy the value of oc9h6pkm5pd2. Remember you are a hacker now 😀 So, you need to use this value somewhere. Ideally, the hacker will be using a different machine from some other unknown location. But for the purpose of demo let’s use another browser in our machine. Open firefox and browse to https://demo.owncloud.org. In firefox I will use Cookie Manager addon to add/edit cookies. Once you have installed this addon a new icon will appear on the firefox toolbar. Click on it and open it for demo.owncloud.org’s tab. It will list the cookies of demo.owncloud.org. Click the edit button near to oc9h6pkm5pd2. U will get a window like shown below.
Paste the contents we have copied to the Value field and click save. Now, copy the value of oc_sessionPassphrase and repeat the same. The final settings would look like this
Now, go to the tab in Firefox where demo.owncloud.org is running and refresh it. What do you see? Pwned!
What are the chances of a cookie being stolen?
We now know that if an attacker is able to steal our cookie he can take over our web session. He can do whatever he wants. Taking over a session by stealing cookies is called Session Hijacking. The next question is obviously, how to steal cookies? We never allow an attacker to use our machine, do we?
There can be many ways by which an attacker with great knowledge,patience and a mindset to work can steal your cookie. We will discuss one major hack here.
Cross site scripting and HttpOnly cookie
Let’s exploit this
Observe the url now,
The special characters in our query such as <,>,(,) are converted to some encoded format. This type of encoding is called url encoding and the browser does this by itself for security. Well, let’s try something else now. I am going to hit <script>alert(document.cookie)</script> in the search bar. Well, it shows me the cookie of my current session.
Don’t you still find anything fishy? Then, let’s dig a bit more deeper. Lets copy the url for the above code
And send it to some friend in chat. They would only see some junk url. But since they trust you they might click it.
Now, if they click the url, it will open in a new tab and show their cookie as a popup. Well wait, what if I change the code a bit, such that the code can email that cookie to me? Boom! Easily their cookie is now mine, their session is now mine. This is a classical example of Cross Site Scripting, but the scope of this attack is way beyond than this. I am not going to it in depth right now. But I will later write detailed article on it. Now, for the purpose of understanding cookie security, this is enough.
Cross Site Request Forgery and SameSite cookie
Just like XSS, Cross Site Request Forgery(CSRF) is another type of attack in which the attacker gains access to a legitimate user’s session. As compared to XSS, here the attacker will not steal anything such as cookies. Instead he will use the user’s session without consent. We will see how this is possible.
Imagine that there is a banking application. Suppose the application url be https://www.testbankapp.com. When you transfer $1000 from this bank to account number 875495878521, suppose that the bank is using the following query.
Here, amt is the amount to be transferred, toAccNo is the account number to which the money is to be transferred and fromAccNo is the account number from which money is withdrawn. If you think like a hacker, you would have probably thought to change the value of toAccNo to your account number and pwn the user. Good thought! But it’s not easy, reason being the cookies. When a user is logged in, there will be a unique session cookie assigned to him. The cookie will be sent as post data with every request to the server. The bank server will verify this cookie before executing each transfer request. So, it is clear that we cannot use this url unless we get access to his cookie. Let’s see how we can get access to this cookie in terms of CSRF.
The attacker will create an attractive website based on the target user’s interest, lets call it http://www.trustmedude.com for instance. For example, a website that provides live cricket score or even a porn website. Inside that application he can embed an ajax request to call the url
Where 258946257412 is the account number of the attacker. Now, if the legitimate user is logged into the bank’s original website, then the attacker will force the user to browse his website http://www.trustmedude.com by some means, for example by sending the url in chat. When the user clicks on the the website, the Ajax request embedded in the website will be executed in the background. If the user is actually logged into the bank application in another tab, then his cookies will be readily available in the browser. The browser will see a request is being sent to the bank’s website. Since the request is being initiated to the testbankapp.com domain, the browser will not think twice before sending the valid cookie of the user. That’s it, pwned!
The solution with samesite cookie
This is a typical example of CSRF attack. In a real world attack this will be more complex. To prevent stealing cookie by means of CSRF, HTTP working group introduced the SameSite cookie flag in 2016. Let’s understand how it works. Basically SameSite key has two values available namely lax and strict. Example with SameSite:
Set-Cookie: phpsessid=oIZEL75Sahdgf34ghLnw; HttpOnly; Secure; SameSite=Strict
Consider our CSRF example above. In case of SameSite=Strict, the browser will not send the cookie to an already authenticated web site, if the link derives from an external site. So, in our example the browser will not send the cookies even if the user clicks on the malicious url sent by the attacker. The value strict will block the cookie from any cross origin usage, and hence it is considered as most appropriate for a banking application.
But there can be other cases where a limited cross origin usage is required. For example if a website wants to direct users to Github, session cookie needs to be allowed when following a regular link from this website. This can be achieved by setting SameSite=lax. In lax mode limited cross site usage will be allowed, i.e if the request is a GET request and the request is top-level. Top level means the url bar should indicate the cross origin request. For example, consider the case when you are redirected to facebook.com from some YouTube comment.
The table below shows what requests are sent with a cross origin request. The corresponding SameSite values are also shown.
It should be noted that implementing SamSite isn’t the exact fix to CSRF. SameSite is just an additional layer of protection.
And the Secure flag
Now we have a basic idea on HttpOnly and SameSite cookie flags. Last one is the Secure flag. There is no big deal here. It deals with SSL. Have you heard about Man in the Middle(MiTM) attacks? A man in the middle attack is a common type of attack in which the attacker tries to capture the web traffic from any intermediate nodes such as routers or wires. HTTP is a plain text protocol, which means anything you send through the internet is transmitted as clear text. Anyone sitting in between the client and server can view everything that’s being sent through the wire.
It is really dangerous and in order to prevent it SSL(Secure Socket Layer) was introduced. You might have noticed some websites having url starting with https instead of http right? Those are SSL enabled website. Once enabled, SSL ensures that the contents being transmitted back-forth between client browser and server will be encrypted. Which means, man in the middle attacker will only see encrypted data now. He will not have the decryption key and hence cannot retrieve the original data. Well, the cookies in our browser needs to be transmitted in the same way right? Otherwise the MiTM attacker will capture the cookies.
If we implement SSL, ideally all the requests must be transmitted as https. But sometimes due to several reasons, even if SSL is enabled some websites allow to be rendered via http. In that case, the cookie will also be transmitted as clear text. But we can tell the browser explicitly to send the cookies only if an https channel is found. Once the Secure flag is set as True, browser will send the cookies only if an https channel is found. In all other cases, it will fail the request and saving the cookie. All caught up 🙂
That’s it for now. I have covered the very basics of Secure, HttpOnly and SameSite flags in this articles. Please do research on everything we have discussed. I will soon write an article soon on SSL and it’s working. Please keep visiting and encourage me. If you like reading through my blog posts consider donating something. Easiest thing you can do is clicking and browsing any advertisement shown in the blog pages. Thanks!