Skip to main content

Prevent account takeover with proper cookie configuration


 

 

In this blog, I am writing about how improperly configured cookie may lead to account takeover. The type of account takeover I'm writing about is only possible when you're in the same local network as victim. Before explaining the issue, I want to thank Veshraj Ghimire for reviewing this.

 

Misconfiguration #1:  Not using 'secure' flag while setting cookies


What is 'secure' flag?

The secure flag is a setting that can be specified when a cookie is created and sent from a web server to a client browser. When a cookie is marked with the secure flag, the client browser will only transmit the cookie back to the server over a secure HTTPS connection. If the secure flag is not set, the cookie will be sent over both secure and insecure connections, making it vulnerable to eavesdropping and tampering by malicious actors.

 

Misconfiguration #2:  Cookie scoped to all the subdomains

 

 What do I mean by "cookie scoped to all the subdomains"?

If you have an application at yourwebsite.com which uses cookie for authorization and you messed up while configuring them then they will also be sent to app2.yourwebsite.com.

.

How cookies might be scoped to all the subdomains?

When setting the cookie for yourwebsite.com if you have the domain flag set to yourwebsite.com then the cookies will be scoped to all the subdomains. For example:


Set-Cookie: session=secretsessiontoken; domain=yourwebsite.com


How is it an issue if app2.yourwebsite.com can access cookies of yourwebsite.com?

If there are vulnerabilities within app2.yourwebsite.com, such as Cross-Site Scripting then a malicious actor will be able to access the cookies for  yourwebsite.com. Hence, taking over user accounts and accessing sensitive information.


Chaining Misconfiguration #1 and Misconfiguration #2

1. yourwebsite.com uses cookie for authorization and the secure flag is not set

2. Cookies are scoped to all the subdomains


There might be hundreds of applications and assets under a domain in the form of subdomains. To exploit this, we just need one application which supports HTTP(non-encrypted HTTP server). In our case it is cdn.yourwebsite.com

 

Now you need to craft an exploit that you need to send to the victim.


<!DOCTYPE html>

<html>

<body>

      <img src="http://cdn.yourwebsite.com" />

</body>

 </html>


Now, host the page and send it to the victim. 


When the victim opens your page, the webpage will attempt to load an image from http://cdn.yourwebsite.com by sending a HTTP request. Little does the victim know that the request also contains cookie that is tied to the user account in yourwebsite.com.  Now, the malicious actor in the same network can view the unencrypted HTTP request and then access your account at yourwebsite.com.


How to prevent this?

This can be prevented by:

1. Setting secure flag prevents this issue, however, using the httponly cookie flag is also recommended. The httponly flag prevents client side javascript from accessing the cookie. 

Set-Cookie: name=value; secure; httponly
 

 



Comments

Popular posts from this blog

Mysterious Javascript Code Found Infecting Hundreds of Websites

  After installing Wappalyzer in my browser, I decided to test its functionality by visiting a familiar website. To my surprise, I was unexpectedly redirected to a spear phishing campaign. Knowing the website's usual practices, it seemed highly unlikely that they would intentionally redirect their visitors in such a manner. Intrigued by this anomaly, I took it upon myself to investigate the underlying cause of this redirection.   I have not yet known how threat actors implanted the Javascript Code in the victim's application but this is what it looked like.         What does the code do?   The code is simply importing script from biggerfun[.]org domain. In other words, it's simply doing <script src="biggerfun[.]org"></script> Further investigation I wanted to check if others think the website is bad, so I looked into it more. I observed they do things similar to another group called TA569. You can learn more about TA569 here: ...

Getting unlimited money by abusing the 'Send Money' feature

      It has been a while since I published a post. So, I am writing this one to share one of my interesting finding while testing an e-wallet application.     I glanced at my Total Balance and I was wondering if there was a way for me to increase it arbitrarily. So, I thought Race Condition would help me here.  What is a Race Condition vulnerability? "A race condition vulnerability typically occurs when your application has access to the same shared data and attempts to change variables within it simultaneously ." - automox.com So, I loaded up Turbo Intruder in Burp Suite and attempted testing it. I failed. I couldn't exploit it.  I didn't want to give up this soon. I kept that fire bottled up and changed my approach. I realized that the 'Send Money' feature uses basic maths to reduce balance from the sender's account and add it to the receiver's account. So, the feature did the following operations:   function sendMoney(sender, receiver, amoun...

Finding ways to misuse application features | An example

I am publishing this without reviewing or re-reading. I apologize if you see any mistake here. Have a great day!  Introduction  Hi, I hope you are well. I am writing this blog after a long time so some of my writing skills might have faded away. Talking about skills, I've mastered one, and it is my ability to spend unlimited amount of time trying to understand every single feature of a target application. Sometimes I find a way to leverage those features  into vulnerabilities other times I end up learning a lot of things from them. So, I'm using this article as a means to share one of the findings that ended up being duplicate.  Bypassing email verification step when registering new email addresses    I was looking at a bug bounty program and I found an application that allowed anyone to register and login to it. So, I created an account to poke around with the features. The first feature I looked at was the registration feature itself. When I created an ac...