Bypass SameSite cookie restrictions
Last updated
Last updated
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à .com
hoặ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.com
và https://app.example.com
được xem là cross-site trong phần lớn các trình duyệt)
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
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
Cấu hình thủ công: Đưa thuộc tính SameSite
tính vào tiêu đề phản hồiSet-Cookie
cùng với giá trị mong muốn:
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
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
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
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:
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.
Exploit sử dụng top-level navigation: Có thể sử dụng document.location
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 đó.
Đố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=x
như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
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