Cookies and Session Management Guide you ever need Part - 1

Before we get into the details of the session management vulnerabilities, let’s first go over the fundamentals, such as what cookies,session, use, and attributes are.

Let's talk about cookies!!

What are Cookies?

Cookies are tiny data files generated by a web server and sent to a web browser. For the duration of a user’s session on a website, or for a predetermined amount of time, web browsers keep the cookies they receive. Any further queries the user makes to the web server are then associated with the pertinent cookies.

What are cookies used for?

1. User sessions
2. Personalization
3. Tracking

what are the types of cookie

---

1. Session Cookies
   Temporary cookies or session cookies are used by websites to identify users and the data they provide while navigating the site. For the duration that a person is on a website, session cookies simply keep track of their activity. The cookies are removed when the web browser is closed. These are frequently utilised on e-commerce and shopping websites.

2. Persistent cookies
   Unlike session cookies, persistent cookies are stored in a user’s browser for an extended period of time, which could be a day, a week, many months, or even years. An expiration date is always present in persistent cookies. In Chrome Developer Tools Menu, persistent cookies have an expiration date, whereas session cookies are marked as ‘session’.

3. Zombie cookies
   

Zombie cookies are exactly what they sound like – cookies that come back to life after you thought they were gone. You may have seen them referred to as “Evercookies,” which are unfortunately not the cookie equivalent of a Wonka everlasting gobstopper. Zombie cookies don’t get cleared because they’re hiding outside of your regular cookie storage. Local storage is a prime target (Adobe Flash and Microsoft Silverlight use this a lot), and some HTML5 storage can also be an issue. The living dead cookies can even be in your web history or in RGB color codes that your browser allows into its cache. All a website has to do is find one of the hidden cookies and it can resurrect the others.

Cookies Attributes

---

In order to protect cookie data, the industry has developed means to assist lock down these cookies and reduce their attack surface. Cookies have evolved into a preferred method of storage for online applications because of their high levels of usability and security. The means to protect the cookies are: Cookie Attributes Cookie Prefixes

1. Secure Attribute

   The Secure attribute instructs the browser to only deliver the cookie if the request is being sent over a secure channel, such as HTTPS. This will lessen the risk of the cookie being sent in an unencrypted request. If the application can be accessed over both HTTP and HTTPS, an attacker could be able to redirect the user to send their cookie as part of non-protected requests.

2. HttpOnly Attribute

   The HttpOnly attribute is used to help prevent attacks such as session leakage, since it does not allow the cookie to be accessed via a client side script such as JavaScript. This doesn’t limit the whole attack surface of XSS attacks, as an attacker could still send request in place of the user, but limits immensely the reach of XSS attack vectors.
   Example:

   Here is an example of how cookies (which are not using HttpOnly flag) can be easily stolen in a website displaying comments:

   1. A field named comment is sent to the server and saved in the database.
   2. When the comments page is loaded, this comment is fetched from db and assigned to a div by innerHtml :
      document.getElementById("commentDiv").innerHTML = commentFromDbVar;
   3. An attacker writes a comment that contains a malicious script which sends all current user cookies to an endpoint (script executes each time comments are loaded)
      

3. Domain Attribute
   The Domain attribute is used to compare the cookie’s domain against the domain of the server for which the HTTP request is being made. If the domain matches or if it is a subdomain, then the path attribute will be checked next.
   Example:

4. Path Attribute
   Verify that the path attribute, just as the Domain attribute, has not been set too loosely. Even if the Domain attribute has been configured as tight as possible, if the path is set to the root directory “/” then it can be vulnerable to less secure applications on the same server.
   For example, if the application resides at /myapp/, then verify that the cookies path is set to “; path=/myapp/” and NOT “; path=/” or “; path=/myapp”. Notice here that the trailing “/” must be used after myapp. If it is not used, the browser will send the cookie to any path that matches “myapp” such as “myapp-exploited”.

5. Expires Attribute
   This attribute is used to set persistent cookies, since the cookie does not expire until the set date is exceeded. This persistent cookie will be used by this browser session and subsequent sessions until the cookie expires. Once the expiration date has exceeded, the browser will delete the cookie. Alternatively, if this attribute is not set, then the cookie is only valid in the current browser session and the cookie will be deleted when the session ends.
   For example, if a cookie is set to"; expires=Sun, 21-Aug-2022 15:45:29 IST"and it is currently August 20th 2022, then the tester should inspect the cookie. If the cookie is a session token that is stored on the user’s hard drive then an attacker or local user (such as an admin) who has access to this cookie can access the application by resubmitting this token until the expiration date passes.

6. SameSite Attribute
   The SameSite attribute is used to assert that a cookie ought not to be sent along with cross-site requests. This feature allows the server to mitigate the risk of cross-origin information leakage. In some cases, it is used too as a risk reduction (or defense in depth mechanism) strategy to prevent cross-site request forgery attacks.

   This attribute can be configured in three different modes:
   ● Strict
   ● Lax
   ● None
   

   Strict Value The Strict value is the most restrictive usage of SameSite, allowing the browser to send the cookie only to first-party context without top-level navigation. In other words, the data associated with the cookie will only be sent on requests matching the current site shown on the browser URL bar. The cookie will not be sent on requests generated by third-party websites. This value is especially recommended for actions performed at the same domain. However, it can have some limitations with some session management systems negatively affecting the user navigation experience. Since the browser would not send the cookie on any requests generated from a third-party domain or email, the user would be required to sign in again even if they already have an authenticated session.

   Lax Value
   The Laxvalue is less restrictive than Strict. The cookie will be sent if the URL equals the cookie’s domain (first-party) even if the link is coming from a third-party domain. This value is considered by most browsers the default behavior since it provides a better user experience than the Strict value. It doesn’t trigger for assets, such as images, where cookies might not be needed to access them.
   

   None Value
   The None value specifies that the browser will send the cookie on cross-site requests (the normal behavior before the implementation of SameSite) only if the Secure attribute is also used, e.g. SameSite=None; Secure. It is a recommended value, instead of not specifying any SameSite value, as it forces the use of the secure attribute.

Httpflag Bypass

⏺️ This could be Bypassed with TRACE HTTP requests as the response from the server (if this HTTP method is available) will reflect the cookies sent. This technique is called Cross-Site Tracking.
⏺️ It’s possible to overwrite HttpOnly cookies by performing a Cookie Jar overflow attack