description |
---|
- Introduction to SameSite Cookies:
- SameSite is a browser security mechanism that determines when a website's cookies are included in requests originating from other websites.
- It provides partial protection against cross-site attacks like CSRF, cross-site leaks, and some CORS exploits.
- Understanding SameSite Terminology:
- A "site" refers to the top-level domain (TLD) plus one additional level of the domain name.
- An "origin" includes one domain name, determined by scheme, domain name, and port.
Difference between origin and site
Request from | Request to | Same-site? | Same-origin? |
---|---|---|---|
https://example.com |
https://example.com |
Yes | Yes |
https://app.example.com |
https://intranet.example.com |
Yes | No: mismatched domain name |
https://example.com |
https://example.com:8080 |
Yes | No: mismatched port |
https://example.com |
https://example.co.uk |
No: mismatched eTLD | No: mismatched domain name |
https://example.com |
http://example.com |
No: mismatched scheme | No: mismatched scheme |
-
How SameSite Works:
- Before SameSite, browsers sent cookies in every request to the domain that issued them.
- SameSite enables limiting which cross-site requests should include specific cookies.
- Major browsers support three SameSite restriction levels: Strict, Lax, and None.
-
Types of SameSite Restrictions:
- Strict: Cookies are not sent in any cross-site requests.
- Lax: Cookies are sent in cross-site GET requests triggered by top-level navigations.
- None: Cookies are sent in all cross-site requests.
-
Bypassing SameSite Lax Restrictions:
-
Using GET requests: By eliciting a GET request from the victim's browser, even if the request involves a top-level navigation.
<script> document.location = '<https://vulnerable-website.com/account/transfer-payment?recipient=hacker&amount=1000000>'; </script>
<!-- Bypass using Symfoney framework Symfony supports the _method parameter in forms which takes precedence over the normal method for routing purposes: --> <form action="<https://vulnerable-website.com/account/transfer-payment>" method="POST"> <input type="hidden" name="_method" value="GET"> <input type="hidden" name="recipient" value="hacker"> <input type="hidden" name="amount" value="1000000"> </form>
-
Using on-site gadgets: Finding gadgets like client-side redirects within the same site to bypass restrictions.
-
Via vulnerable sibling domains: Auditing all available attack surfaces, including sibling domains[subdomains], for vulnerabilities.
-
-
With newly issued cookies: Exploiting a two-minute window where Lax restrictions aren't enforced for top-level POST requests.
To bypass SameSite Lax restrictions with newly issued cookies:
- Typically, cookies with Lax SameSite restrictions aren't sent in cross-site POST requests, except for some scenarios.
- Chrome doesn't enforce Lax restrictions for the first 120 seconds on top-level POST requests to prevent issues with single sign-on (SSO) mechanisms.
- Exploiting this window involves finding a way to force the user's browser to issue a new session cookie.
- One method is to trigger a cookie refresh during a top-level navigation, such as completing an OAuth-based login flow, ensuring the inclusion of current session cookies.
- Another method is triggering the refresh from a new tab to avoid leaving the page, though browsers may block popup tabs unless opened manually.
- To overcome this blocking, you can wrap the window.open() method in an onclick event handler so that it only activates upon user interaction.
-
Conclusion and Resources:
- SameSite cookies provide security against cross-site attacks but can be bypassed using various techniques.
- Developers and testers need to be aware of these bypass methods to thoroughly test for vulnerabilities.