# Cookie Security

## Cookie attributes

`Ultimate` cookie:

```http
Set-Cookie: __Host-SessionID=3h93...;Path=/;Secure;HttpOnly;SameSite=Strict
```

### Secure attribute

Cookies marked with the `Secure` attribute are only sent over encrypted HTTPS connections. The `Secure` attribute only protects the **confidentiality** of a cookie against MiTM attackers - there is no integrity protection.

![](https://75567829-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoxBK8Dd08qrrJGkzYlVB%2Fuploads%2Fgit-blob-ee72b033b4790f29188502f27fb8b787ef97b1c9%2Fmitm-attack.png?alt=media)

* Mallory can't read `Secure` cookies
* Mallory can still **write/change** `Secure` cookies

### HttpOnly attribute

Cookies marked with the `HttpOnly` attribute are not accessible from JavaScript. The `HttpOnly` attribute only protects the **confidentiality** of a cookie, but `HttpOnly` cookies can be replaced by overflowing the cookie jar from JavaScript.

### Path attribute

The `Path` attribute limits the scope of a cookie to a specific path on the server and can therefore be used to prevent unauthorized access to it from other applications on the same host.

#### Cookie scope vs Same-Origin Policy

![](https://75567829-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoxBK8Dd08qrrJGkzYlVB%2Fuploads%2Fgit-blob-47c8bfde7c63b41c55a5c560fb0d16503987ef8c%2Fscope-sop-cookie.png?alt=media)

#### Isolation two different applications on shared host

![](https://75567829-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoxBK8Dd08qrrJGkzYlVB%2Fuploads%2Fgit-blob-23421ec8398d5b5ffdf3a3ccc29f955a48f238fc%2Fisolation-sop-cookie.png?alt=media)

### Domain attribute

The `Domain` specifies allowed hosts to receive the cookie.

* If the `Domain` attribute unspecified, it defaults to the host of the current document location, excluding subdomains
  * IE will always send to subdomains regardless
* If the `Domain` attribute is specified, cookies will be sent to that domain and **all its subdomains**

### Expires attribute

The `Expires` attribute allows you to set the maximum cookie lifetime.

* If the `Expires` attribute unspecified, cookie lifetime is equal to session lifetime
* It is up to the browser to decide when the session ends
* `Non-persistent` session cookies may actually be persisted to survive browser restart

![](https://75567829-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoxBK8Dd08qrrJGkzYlVB%2Fuploads%2Fgit-blob-99c5fb4dbd0e481905cbd32ed95e2c59ff8d42ea%2Fcookie-survive.png?alt=media)

References:

* [MDN Web Docs - Document.cookie](https://developer.mozilla.org/en-US/docs/Web/API/document/cookie)

### SameSite

The `SameSite` attribute prevents the browser from sending cookies along with cross-site requests. The `SameSite` attribute can have one of two values (case-insensitive):

* `Strict`, if the URL of the constructed request is different from the URL of the current page, `Strict` cookies will not be included in the request
  * Possible problem: `Strict` cookies will not be sent when clicking on a link from another site
  * Possible solution: Use two cookies. The first cookie, **without** `SameSite`, as a uniq user id, allows you to show username e.g. Second cookie, **with** `SameSite`, to make purchases, profile changes, and more
* `Lax`, adds an exception allowing the send a cookies when navigating from an external URL, which uses `secure` HTTP methods, for example, when clicking on the link. The `secure` methods: `GET, HEAD, OPTIONS и TRACE`.

{% hint style="info" %}
From Chrome 80 (February 2019) the default behaviour of a cookie without a cookie SameSite attribute will be Lax, check the [link](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)

Temporary, after applying this change, the cookies without a SameSite in Chrome will be treated as None during the first 2 minutes and then as Lax, [Bypass SameSite Cookies Default to Lax and get CSRF](https://medium.com/@renwa/bypass-samesite-cookies-default-to-lax-and-get-csrf-343ba09b9f2b)
{% endhint %}

References:

* [MDN Web Docs - Set-cookie: Browser compatibility](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Browser_compatibility)

## Cookie prefix

The `Cookie Prefix` allows the send of cookie prefix information to ensure that certain attributes are present in a cookie request. Supported prefixes:

* `__Secure-`, tells the browser that the `Secure` attribute is required,
* `__Host-`, tells the browser that the `Path = /` and `Secure` attributes are required, and at the same time that the `Domain` attribute should not be present.

References:

* [MDN Web Docs - Set-cookie: Browser compatibility](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Browser_compatibility)

## Cookie-list sorting

The [RFC6265](https://tools.ietf.org/html/rfc6265#section-5.4) standard defines the order of cookies:

```
2.  The user agent SHOULD sort the cookie-list in the following order:

    *  Cookies with longer paths are listed before cookies with shorter paths.

    *  Among cookies that have equal-length path fields, cookies with earlier creation-times are listed before cookies with later creation-times.
```

as a result, if the vulnerable application uses only the first cookie, you can force it to use your cookie by adding the `Path` attribute with longer path.