28 Feb, 2023

Insecure Use of Cookies

Vulnerability Assessment as a Service (VAaaS)

Tests systems and applications for vulnerabilities to address weaknesses.

Insecure use of cookies refers to a security vulnerability that arises when cookies, which are small text files stored on a user’s computer by a website, are not properly secured. Cookies can be used to store user preferences and login information, but they can also be exploited by malicious actors to gain unauthorized access to a user’s account or steal sensitive information.

Insecure use of cookies can occur when websites transmit sensitive information, such as usernames and passwords, in plain text rather than encrypting them. This makes it easy for an attacker to intercept the information and use it to gain access to the user’s account. Insecure cookies can also be manipulated or forged by attackers to gain access to sensitive areas of a website.

Example of vulnerable code on different programming languages:


in JavaScript:

				
					// Set a cookie with user's session ID
document.cookie = "session_id=" + session_id;

// Retrieve the session ID from the cookie
var session_id = document.cookie.split(';').find(cookie => cookie.startsWith('session_id=')).split('=')[1];

				
			


This code is vulnerable because it sets the session ID in a cookie without the HttpOnly and Secure flags. This makes it easy for an attacker to steal the session ID and gain unauthorized access to the user’s account.

• in PHP:

				
					// Set a cookie with user's username and password
setcookie('user_info', $username . ':' . $password);

// Retrieve the username and password from the cookie
list($username, $password) = explode(':', $_COOKIE['user_info']);

				
			


This code is vulnerable because it stores the user’s username and password in a cookie without encrypting it. This makes it easy for an attacker to intercept the cookie and steal the user’s login credentials.

• in Python:

				
					# Set a cookie with user's session ID
response.set_cookie('session_id', session_id)

# Retrieve the session ID from the cookie
session_id = request.COOKIES.get('session_id')

				
			


This code is vulnerable because it sets the session ID in a cookie without the HttpOnly and Secure flags. This makes it easy for an attacker to steal the session ID and gain unauthorized access to the user’s account.

• in Ruby:

				
					# Set a cookie with user's session ID
response.set_cookie('session_id', session_id)

# Retrieve the session ID from the cookie
session_id = request.cookies['session_id']

				
			


This code is vulnerable because it sets the session ID in a cookie without the HttpOnly and Secure flags. This makes it easy for an attacker to steal the session ID and gain unauthorized access to the user’s account.

Examples of exploitation Insecure Use of Cookies

Session hijacking:

If a website stores a user’s session ID in an insecure cookie, an attacker can intercept the cookie and use the session ID to gain access to the user’s account. This is known as session hijacking.

Cross-site scripting (XSS):

If a website stores user input in a cookie without properly sanitizing it, an attacker can inject malicious code into the cookie. When the user’s browser reads the cookie, the malicious code can execute and steal sensitive information or perform unauthorized actions.

Cross-site request forgery (CSRF):

If a website stores authentication information in an insecure cookie, an attacker can create a fake form on a different website that sends a request to the vulnerable website using the user’s authentication cookie. This is known as cross-site request forgery.

Cookie tampering:

If a website stores sensitive information in a cookie without properly encrypting it, an attacker can intercept the cookie and modify its contents. For example, an attacker could change a user’s account balance in a cookie to steal money from the user’s account.

Privilege escalation techniques for Insecure Use of Cookies

Session fixation:

An attacker can set the session ID in a cookie to a known value before the user logs in, or force the user to use a specific session ID. This allows the attacker to use the known session ID to access the user’s account after they have logged in, effectively hijacking the user’s session.

Session poisoning:

An attacker can inject malicious code into a cookie that modifies the user’s session data. For example, an attacker could change the user’s role or privilege level in the session data to gain access to higher levels of access on the website.

Cookie poisoning:

An attacker can modify the contents of a cookie to gain access to higher levels of access on the website. For example, an attacker could modify a cookie that stores the user’s role or privilege level to gain access to higher levels of access.

Cookie replay:

An attacker can intercept a cookie and replay it to gain access to the user’s account. This is possible if the cookie does not have a limited lifespan or is not invalidated when the user logs out.

Cookie theft:

An attacker can steal a user’s cookie, either by intercepting it over an insecure connection or by using a cross-site scripting (XSS) attack to inject malicious code that steals the user’s cookies.

General methodology and checklist for Insecure Use of Cookies

Methodology:

  1. Identify the cookies used by the application: Review the application’s documentation or source code to identify the cookies used by the application, and note the names, values, and purpose of each cookie.

  2. Determine the cookie attributes: Determine whether the cookies have attributes such as HttpOnly, Secure, SameSite, and expiration time. If any of these attributes are missing or set incorrectly, the cookies may be vulnerable to attacks.

  3. Test for session hijacking: Attempt to intercept the user’s cookies and use them to gain access to the user’s account. This can be done using a proxy tool such as Burp Suite, or by sniffing network traffic with a packet sniffer.

  4. Test for session fixation: Attempt to set the user’s session ID to a known value before the user logs in, or force the user to use a specific session ID. Then, attempt to use the known session ID to access the user’s account after they have logged in.

  5. Test for cookie poisoning: Attempt to modify the contents of a cookie to gain access to higher levels of access on the website. For example, attempt to modify a cookie that stores the user’s role or privilege level to gain access to higher levels of access.

  6. Test for cookie replay: Attempt to intercept a cookie and replay it to gain access to the user’s account. This is possible if the cookie does not have a limited lifespan or is not invalidated when the user logs out.

  7. Test for cookie theft: Attempt to steal a user’s cookie, either by intercepting it over an insecure connection or by using a cross-site scripting (XSS) attack to inject malicious code that steals the user’s cookies.

  8. Test for anti-CSRF measures: Check if the application implements anti-CSRF measures to prevent cross-site request forgery attacks.

  9. Report findings and suggest remediation: Document any vulnerabilities found and report them to the application owner or development team. Suggest remediation measures such as implementing secure cookie handling practices and validating session and cookie data on the server side.

Checklist:

  1. Identify all cookies used by the application, including their names, values, and purposes.

  2. Check if all cookies are marked as HttpOnly to prevent cross-site scripting (XSS) attacks.

  3. Check if all cookies are marked as Secure to prevent interception over unencrypted connections.

  4. Check if all cookies have a SameSite attribute set to either Strict or Lax to prevent cross-site request forgery (CSRF) attacks.

  5. Check if all cookies have an appropriate expiration time to limit their lifespan and reduce the risk of theft or replay attacks.

  6. Check if the application implements anti-CSRF measures to prevent CSRF attacks.

  7. Check if the application properly invalidates session cookies when a user logs out to prevent replay attacks.

  8. Check if the application uses session IDs that are randomly generated and not easily predictable to prevent session fixation attacks.

  9. Check if the application properly validates session and cookie data on the server side to prevent poisoning attacks.

  10. Test the application for session hijacking, session fixation, cookie poisoning, cookie replay, and cookie theft.

  11. Document any vulnerabilities found and report them to the application owner or development team.

  12. Suggest remediation measures such as implementing secure cookie handling practices and validating session and cookie data on the server side.

Tools set for exploiting Insecure Use of Cookies

Manual Tools:

  • Burp Suite: A popular intercepting proxy tool that allows for manual manipulation of HTTP requests and responses. Can be used to intercept and modify cookies, test for session hijacking and other vulnerabilities.

  • OWASP ZAP: An open-source web application security scanner that can be used to manually test for insecure cookie usage.

  • Tamper Data: A browser plugin that allows for manual manipulation of HTTP requests and responses. Can be used to intercept and modify cookies.

  • Cookie Editor: A browser plugin that allows for manual editing of cookies. Can be used to modify cookie attributes and values.

  • EditThisCookie: A browser plugin that allows for manual editing of cookies. Can be used to modify cookie attributes and values.

  • Chrome DevTools: A built-in developer tool in the Chrome browser that can be used to inspect and modify cookies.

  • Firefox Developer Tools: A built-in developer tool in the Firefox browser that can be used to inspect and modify cookies.

  • Firebug: A popular browser plugin that allows for manual inspection and manipulation of HTTP requests and responses. Can be used to intercept and modify cookies.

  • TamperIE: A browser plugin that allows for manual manipulation of HTTP requests and responses in Internet Explorer. Can be used to intercept and modify cookies.

Automated Tools:

  • Nessus: A network vulnerability scanner that includes checks for insecure cookie usage.

  • Acunetix: A web vulnerability scanner that includes checks for insecure cookie usage.

  • Netsparker: A web vulnerability scanner that includes checks for insecure cookie usage.

  • Qualys: A web application security scanner that includes checks for insecure cookie usage.

  • IBM AppScan: A web application security scanner that includes checks for insecure cookie usage.

  • Nikto: An open-source web server scanner that can be used to check for insecure cookie usage.

  • Skipfish: An open-source web application security scanner that can be used to check for insecure cookie usage.

  • Wapiti: An open-source web application security scanner that can be used to check for insecure cookie usage.

  • Vega: An open-source web application security scanner that can be used to check for insecure cookie usage.

  • Arachni: An open-source web application security scanner that can be used to check for insecure cookie usage.

  • Metasploit: A popular penetration testing framework that includes modules for testing for insecure cookie usage.

Average CVSS score of stack Insecure Use of Cookies

It is difficult to provide an exact average CVSS score for vulnerabilities related to Insecure Use of Cookies, as the score can vary depending on the severity and impact of each individual vulnerability. However, in general, vulnerabilities related to Insecure Use of Cookies are often classified as Medium to High severity, with CVSS scores typically ranging from 4.0 to 9.0.

The exact score will depend on various factors such as the nature and impact of the vulnerability, ease of exploitation, and the overall security posture of the application. It is important to note that even vulnerabilities with lower CVSS scores can still pose a significant risk, and should not be ignored or dismissed. It is crucial to address any vulnerabilities related to Insecure Use of Cookies in a timely and effective manner to ensure the security of the application and its users.

The Common Weakness Enumeration (CWE)

• CWE-614: Sensitive Cookie in HTTPS Session Without “Secure” Attribute: This weakness occurs when sensitive cookies, such as session cookies, are transmitted over an unencrypted HTTP connection, or when the “Secure” attribute is not set on cookies transmitted over HTTPS.

• CWE-613: Insufficient Session Expiration: This weakness occurs when session cookies do not expire after a reasonable period of time, or when session cookies can be reused even after a user has logged out.

• CWE-285: Improper Authorization: This weakness occurs when cookies are used to authenticate users, but the authorization process is not properly implemented or enforced.

• CWE-352: Cross-Site Request Forgery (CSRF): This weakness occurs when an attacker can forge a request that appears to come from a legitimate user, using cookies to trick the application into executing unauthorized actions.

• CWE-362: Race Condition: This weakness occurs when cookies are used to store or manage state information in a way that can be manipulated by an attacker, leading to unexpected behavior or unauthorized access.

• CWE-200: Information Exposure: This weakness occurs when sensitive information, such as session IDs or user credentials, are stored in cookies in plaintext or otherwise disclosed to unauthorized parties.

• CWE-399: Resource Management Errors: This weakness occurs when cookies are not properly managed or protected, leading to potential attacks such as cookie poisoning or cookie theft.

• CWE-287: Improper Authentication: This weakness occurs when cookies are used to authenticate users, but the authentication process is not properly implemented or enforced.

• CWE-400: Uncontrolled Resource Consumption: This weakness occurs when cookies are not properly managed, leading to potential attacks such as cookie poisoning or cookie theft.

• CWE-613: Insufficient Session Expiration: This weakness occurs when session cookies do not expire after a reasonable period of time, or when session cookies can be reused even after a user has logged out.

Top 10 CVES related to Insecure Use of Cookies

• CVE-2022-38846 – EspoCRM version 7.1.8 is vulnerable to Missing Secure Flag allowing the browser to send plain text cookies over an insecure channel (HTTP). An attacker may capture the cookie from the insecure channel using MITM attack.

• CVE-2022-35284 – IBM Security Verify Information Queue 10.0.2 could disclose sensitive information due to a missing or insecure SameSite attribute for a sensitive cookie. IBM X-Force ID: 230811.

• CVE-2022-35223 – EasyUse MailHunter Ultimate’s cookie deserialization function has an inadequate validation vulnerability. Deserializing a cookie containing malicious payload will trigger this insecure deserialization vulnerability, allowing an unauthenticated remote attacker to execute arbitrary code, manipulate system command or interrupt service.

• CVE-2022-34313 – IBM CICS TX 11.1 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic. X-Force ID: 229449.

• CVE-2022-34307 – IBM CICS TX 11.1 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic. IBM X-Force ID: 229436.

• CVE-2022-31629 – In PHP versions before 7.4.31, 8.0.24 and 8.1.11, the vulnerability enables network and same-site attackers to set a standard insecure cookie in the victim’s browser which is treated as a `__Host-` or `__Secure-` cookie by PHP applications.

• CVE-2022-22329 – IBM Control Desk 7.6.1 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic. IBM X-Force ID: 219124.

• CVE-2021-46416 – Insecure direct object reference in SUNNY TRIPOWER 5.0 Firmware version 3.10.16.R leads to unauthorized user groups accessing due to insecure cookie handling.

• CVE-2021-38977 – IBM Tivoli Key Lifecycle Manager 3.0, 3.0.1, 4.0, and 4.1 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic. IBM X-Force ID: 212782.

• CVE-2021-29883 – IBM Standards Processing Engine (IBM Transformation Extender Advanced 9.0 and 10.0) does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic. IBM X-Force ID: 207090.

Insecure Use of Cookies exploits

  • Session hijacking: This is a technique where an attacker steals a user’s session cookie and uses it to take over the user’s session, gaining unauthorized access to the user’s account or sensitive information.

  • Cross-site scripting (XSS) attacks: This is a type of attack where an attacker injects malicious code into a website, often through a vulnerability in a cookie, and then tricks a user into executing the code, which can lead to the theft of sensitive information or the execution of unauthorized actions.

  • Cross-site request forgery (CSRF) attacks: This is a type of attack where an attacker can trick a user into performing an action on a website without their knowledge or consent, often by exploiting a vulnerability in a cookie.

  • Cookie poisoning: This is a technique where an attacker modifies the contents of a cookie, often by intercepting and manipulating the cookie in transit, to gain unauthorized access to a user’s account or sensitive information.

  • Cookie theft: This is a technique where an attacker steals a user’s cookie, often by intercepting the cookie in transit, and uses it to take over the user’s session, gaining unauthorized access to the user’s account or sensitive information.

  • Cookie replay attacks: This is a type of attack where an attacker intercepts a valid cookie and then replays it in order to gain unauthorized access to a user’s account or sensitive information.

Practicing in test for Insecure Use of Cookies

Understand how cookies work: Before testing for Insecure Use of Cookies, it’s important to have a clear understanding of how cookies work and how they are used by web applications. This will help you identify potential vulnerabilities and weaknesses.

Use a variety of tools: There are many tools available for testing for Insecure Use of Cookies, both automated and manual. It’s important to use a variety of tools to ensure comprehensive coverage of potential vulnerabilities.

Use a variety of testing techniques: In addition to using a variety of tools, it’s important to use a variety of testing techniques, such as manual testing, automated testing, and penetration testing. This will help you identify potential vulnerabilities from different angles.

Test across different browsers and devices: Cookies can behave differently across different browsers and devices, so it’s important to test for Insecure Use of Cookies across a variety of platforms.

Test in different contexts: Cookies can be used in a variety of contexts, such as login pages, shopping carts, and user profiles. It’s important to test for Insecure Use of Cookies in different contexts to ensure comprehensive coverage.

Use real-world scenarios: Use real-world scenarios to test for Insecure Use of Cookies. This will help you identify potential vulnerabilities that may not be apparent in a controlled testing environment.

Keep up-to-date with new vulnerabilities: New vulnerabilities related to Insecure Use of Cookies are discovered regularly. It’s important to keep up-to-date with new vulnerabilities and techniques so that you can continue to improve your testing practices.

For study Insecure Use of Cookies

OWASP: The Open Web Application Security Project (OWASP) is a non-profit organization that provides resources and tools for web application security. They have a dedicated page on their website that covers Insecure Use of Cookies, including information on vulnerabilities, testing techniques, and best practices.

NIST: The National Institute of Standards and Technology (NIST) is a government agency that provides guidelines and standards for information security. They have a publication on their website that covers guidelines for protecting sensitive information with cookies.

SANS: The SANS Institute is a private company that provides training and certification for information security professionals. They offer a variety of courses and resources on web application security, including Insecure Use of Cookies.

Books: There are many books available that cover web application security and Insecure Use of Cookies specifically. Some popular books include “The Web Application Hacker’s Handbook” by Dafydd Stuttard and Marcus Pinto, and “Web Application Security: A Beginner’s Guide” by Bryan Sullivan and Vincent Liu.

Online courses: There are many online courses available that cover Insecure Use of Cookies and web application security in general. Some popular platforms for online courses include Udemy, Coursera, and Pluralsight.

Books with review of Insecure Use of Cookies

The Web Application Hacker’s Handbook by Dafydd Stuttard and Marcus Pinto – This book is a comprehensive guide to finding and exploiting security vulnerabilities in web applications. It includes a section on Insecure Use of Cookies.

Web Application Security: A Beginner’s Guide by Bryan Sullivan and Vincent Liu – This book is an introduction to web application security and covers a variety of topics, including Insecure Use of Cookies.

Black Hat Python: Python Programming for Hackers and Pentesters by Justin Seitz – This book teaches Python programming for security professionals, including techniques for exploiting Insecure Use of Cookies.

Hacking Web Applications: Hacking Exposed by Joel Scambray, Mike Shema, and Caleb Sima – This book provides a detailed guide to web application security, including Insecure Use of Cookies.

Mastering Modern Web Penetration Testing by Prakhar Prasad – This book covers modern techniques for web penetration testing, including testing for Insecure Use of Cookies.

The Basics of Web Hacking: Tools and Techniques to Attack the Web by Josh Pauli – This book covers the basics of web hacking and includes a section on exploiting Insecure Use of Cookies.

OWASP Testing Guide v4.0 by OWASP – This guide is a comprehensive resource for web application security testing and includes a section on testing for Insecure Use of Cookies.

Gray Hat Python: Python Programming for Hackers and Reverse Engineers by Justin Seitz – This book teaches Python programming for security professionals, including techniques for exploiting Insecure Use of Cookies.

The Art of Exploitation by Jon Erickson – This book covers the basics of hacking and exploitation, including techniques for exploiting Insecure Use of Cookies.

The Tangled Web: A Guide to Securing Modern Web Applications by Michal Zalewski – This book covers the complexities of modern web applications and includes a section on securing against Insecure Use of Cookies.

List of payloads Insecure Use of Cookies

  • '"><script>alert(1)</script>: This payload can be used to test for a vulnerability that allows injection of script tags in cookie values.

  • %22%3E%3Cscript%3Ealert(1)%3C/script%3E: This is an encoded version of the previous payload that can be used in certain contexts where special characters are not allowed.

  • document.cookie="name=value; path=/; domain=.example.com;";alert(1);: This payload sets a cookie and also executes a script that triggers an alert box.

  • name=value; HttpOnly: This is a cookie that sets the HttpOnly flag, which prevents client-side scripts from accessing the cookie.

  • name=value; Secure: This is a cookie that sets the Secure flag, which ensures that the cookie is only sent over a secure connection (HTTPS).

  • name=value; SameSite=Strict: This is a cookie that sets the SameSite attribute to Strict, which restricts the cookie to first-party contexts only.

  • name=value; SameSite=Lax: This is a cookie that sets the SameSite attribute to Lax, which allows the cookie to be sent in some third-party contexts (such as when loading an image or script from a third-party domain).

  • name=value; domain=evil.com: This is a cookie that sets the domain attribute to a different domain than the one the cookie was issued from, which can be used to exploit vulnerabilities that allow cookie injection.

  • name=value; path=/../: This is a cookie that sets the path attribute to a directory traversal sequence (/../), which can be used to exploit vulnerabilities that allow cookie injection.

  • name=value; expires=Wed, 21 Oct 2020 07:28:00 GMT: This is a cookie that sets an expiration date, which can be used to test for vulnerabilities related to cookie expiration.

How to be protected from Insecure Use of Cookies

  1. Use the HttpOnly flag: By setting the HttpOnly flag on your cookies, you can prevent client-side scripts from accessing them. This makes it harder for attackers to steal your cookies using cross-site scripting (XSS) attacks.

  2. Use the Secure flag: By setting the Secure flag on your cookies, you can ensure that they are only sent over a secure (HTTPS) connection. This makes it harder for attackers to intercept your cookies using network sniffing tools.

  3. Use the SameSite attribute: By setting the SameSite attribute on your cookies to Strict or Lax, you can prevent them from being sent in cross-site requests. This makes it harder for attackers to use your cookies to perform cross-site request forgery (CSRF) attacks.

  4. Use token-based authentication: Instead of relying on cookies for authentication, use a token-based authentication scheme. This can be more secure because the tokens can be designed to expire quickly, and they can be validated on the server-side to prevent tampering.

  5. Use a Content Security Policy (CSP): By using a CSP, you can prevent your pages from loading scripts or other resources from untrusted domains. This can help prevent attacks that rely on injecting malicious scripts or other content into your pages.

  6. Keep your software up to date: Make sure you are running the latest versions of your web server, database server, and application software. This can help protect you from known vulnerabilities that have been patched in newer versions.

  7. Use a web application firewall (WAF): A WAF can help protect your application from attacks by filtering incoming traffic and blocking requests that match known attack patterns.

  8. Use strong passwords: Make sure you are using strong passwords for your accounts, and consider using a password manager to generate and store them securely.

Conclusion

Insecure Use of Cookies vulnerabilities can have serious consequences for web applications and their users. Attackers can exploit these vulnerabilities to steal sensitive data, impersonate users, or perform other malicious activities.

To prevent Insecure Use of Cookies vulnerabilities, it is important to use secure coding practices and follow best practices for cookie management. This includes using HttpOnly, Secure, and SameSite attributes, as well as token-based authentication and other security measures.

Regular testing and vulnerability scanning can also help detect and remediate Insecure Use of Cookies vulnerabilities before they can be exploited by attackers.

Other Services

Ready to secure?

Let's get in touch