Cookies are a widely used way to enable authentication in many of the applications out there. Over time, there has been a lot of security implications in Cookie-Based Authentication and new methods such as token-based authentication has entered the picture. Although many modern applications are adapting Token-Based authentication, Cookie-Based Authentication is still alive and can be observed in the wild. From my pentesting experience, I’ve observed that 6 out of 10 applications still utilize cookie-based authentication.

Before reading this article, it is essential to understand cookies and how they work. You can read about them here.

In this article, we will look at various attack scenarios that can be exploited in the wild if the application is using cookies for authentication, tracking, personalization, or some value reflections. The image below is a detailed mind map about various possible (but not limited to) attack scenarios for Cookie-based Authentication Vulnerabilities.

Attack Scenarios

Now, we will take a look at some of the interesting attack scenarios from the above mind map. To give you the tools to better understand your large attack surface when you stumble upon cookies.

Attack — 1: Insecure Direct Object Reference

Let’s assume an application is using cookie-based authentication and supplying a userid parameter in the cookies. However, there is no validation of this userid with other session identifiers due to which an attacker can simply change the userid to the victim user’s id and gain access to its account.

Original Request

GET /userinfo
HOST: harshbothra.tech
Cookies: sessionid=somerandomsessionID;userid=1234;someothercookies=values...

Modified Request

An attacker attempts to change the userid to victim let say 1235.

GET /userinfo
HOST: harshbothra.tech
Cookies: sessionid=somerandomsessionID;userid=1235;someothercookies=values
…

If the attacker is able to access the data of the user, it can be reported as IDOR or Cookie Based Account Takeover based on the situation.

Attack — 2: Privilege Escalation

In this scenario, if cookies are used to define the role (or any other similar key-value pairs that defines some privileges/access rights) and there is no validation, an attacker can abuse this behavior to perform a Privilege Escalation.

Real-Life Finding

1. Login as a victim user and capture the request with Burp Suite.

2. In Cookies section there was a ROLE parameter which has a two-digit value 00.

3. Create an admin account and observe that now ROLE value in cookies is 11.

4. Upon further inspection and mapping User Role & Permission Matrix. I observed that the application uses binary bits for role definition.

00 : User

11 : Admin

5. Now, by changing the ROLE parameter in normal user account to 11, It was possible to perform a successful privilege escalation in Admin User Role.

Attack — 3: File Inclusion

It may sound weird that an attacker can potentially utilize cookies to perform a file inclusion attack, but security issues can arise at any point depending on how an application is implementing various features.

Let’s assume that an application utilizes the following cookie to show a welcome banner.

Cookie: banner=welcome.php; someothercookies=value;

As you can observe, it seems that the application is fetching some welcom.php file from the backend and thus it can be an interesting injection point for the Local File Inclusion.

Cookie: banner=../../../../../../../../etc/passwd; someothercookies=value;

If you see /etc/passwd somewhere in the application in place of a welcome banner, the attack is executed successfully. However, such scenarios are rarely seen and are purely a result of poor implementation.

This is a good read about a real-life finding on LFI via Cookies.

Attack — 4: Cross-Site Scripting

Many applications utilize cookies to display the username or some sort of message within the application user interface. An attacker can tamper with such cookies and inject a malicious JavaScript payload resulting in a Self-XSS.

Original Cookies

Cookie: name=harsh;somecookies=value

Modified Cookies

Cookie: name=<script>alert(document.domain)</script>; somecookies=value

Now the Self-XSS is not impactful and, in general, is considered an acceptable risk. The question is if it is possible to escalate this into a Good XSS. In certain situations, it may be possible. If an application is vulnerable to CRLF injection, an attacker can try to inject a cookie header with attacker-controlled values and send it to the victim, it may turn this into Good XSS. However, usually, the impact stays within the boundaries of Self-XSS only.

Attack — 5: Guessable/Weak Cookie

1. Check if the cookies are generated randomly by issuing multiple cookies and analyzing them.

2. Check if some weak or known cryptography is used. Let’s assume the cookies are using Base64 Encoding and can be decoded/forged easily.

Attack — 6: Sensitive Data Exposure

Sometimes cookies are used to store user’s personal information, especially in Health Care related applications. Always check for the following:

1. Check if any PII or Other Sensitive Information Stored in Cookies by simply using DevTools/Burp Suite/Cookie Editor
2. This information usually includes: Email, Date of Birth, Mobile, Address, SSN, Etc

Attack — 7: Direct Request/Authorization Bypass

Let’s assume that the application has the following endpoint which allows an authenticated user to view some protected sensitive information.

GET /protected-resource

HOST: harshbothra.tech

Cookies: sessionid=somesessionID; someotherkey=value

...

GET /protected-resource

HOST: harshbothra.tech

...

If the application doesn’t validate if the user is authenticated or not, an attacker can access the protected-resource without being authenticated to the application. This results in a Direct Request or Authorization Bypass Issue.

Attack — 8: Insecure Deserialization

If the cookies are using any serialized object, it is possible to perform object injection or serialization-based attacks. This allows an attacker to perform privilege escalation, authentication bypass, and other attacks based on how serialized objects are used.

Read More: https://portswigger.net/web-security/deserialization/exploiting 

Attack — 9: Mass Assignment/Parameter Pollution

If an application accepts the use of a duplicate parameter (the same parameter used multiple times) or multiple values within the same parameter, it may be vulnerable to Parameter Pollution or Mass Assignment Attacks.

Real Life

1. Assume that the cookies utilize a parameter called "user_id=" to retrieve some data. However, the application is not vulnerable to IDOR and changing "user_id=" to victim value, doesn't help out
2. An Attacker tries to add an additional "user_id=" parameter value to the cookie with victim's user ID. Like: "user_id=attacker&user_id=victim"
3. As a result, an attacker is able to retrieve the data of Victim User as the application's parameter processing preference is given to the later parameter and the checks are bypassed.

Attack — 10: Missing Cookie Security Attributes

This is a simple security misconfiguration and is easy to check. As soon as you log in to the application, use any cookie editor or Browser Developer Tools (preferred) to see if the cookies are missing the following attribute (flags not set):

• HTTPOnly: Protects cookies from being stolen using Scripting Attacks such as XSS.

• Secure: Protects cookies from being stolen over Insecure Communication channels and attacks such as Man-in-the-Middle attacks.

There are more attacks than the ones mentioned above, but it’s a good place to start. I have shared more details on each attack in Learn365 GitHub Repository.

Remediations

1. Implement all the required cookie security attributes such as HTTPOnly & Secure.

2. Ensure that plain cookies are not used to define the privileges. For example, sending role parameters to define privilege should not be implemented.

3. Ensure that no sensitive data is directly used in cookies. If due to any business requirements it is required to used this data, make sure it’s strongly encrypted and can’t be decrypted.

4. Always perform validations on the protected endpoints and ensure that they are not accessible without authentication.

5. Prefer token-based authentication over cookie-based authentication or implement an additional Authorization header to make sure such attack attempts are reduced to a greater extent.

6. Never allow reading server-side components such as files using cookies & ensure that the proper validation checks are in place to mitigate such attacks.

Takeaways

1. Always check for weak cryptography in the cookies or check if any known library is used to generate the cookies. This may often allow you to perform an account takeover resulting in critical severity issues.

2. Always map an application to understand what values are dynamically changed using session identifiers/variables and try to abuse them.

3. Always look for Server-Side issues in the Cookies as well. In many cases, you may find interesting security vulnerabilities.

4. Check if the cookies are properly validated for the protected resources, failing to do so may result in authorization bypass.

5. Always, always dig deep, and when you encounter cookies next time, you know what you need to do next ;)

Thanks for checking out my post, feel free to comment below with any questions or additional resources. And don’t forget to check out the Cookies Based Authentication Vulnerability mind map.