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.comHow 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
Post a Comment