Tl;dr
Về cơ bản thì XS-Search là 1 dạng tấn công client-site, tiền đề khai thác là 1 hoặc nhiều bug CSRF. Impact thường là leak các thông tin nhạy cảm của người dùng và gửi đến hacker.
Thông tin đầy đủ vui lòng tham khảo tại: https://xsleaks.dev/
Như vậy các điều kiện để khai thác thành công sẽ là:
Ví dụ 2: website X có 1 endpoint như sau:
POST /backup
pincode=123456
Chức năng này sẽ tạo 01 url download bản sao lưu data của khách hàng. Để tạo link thì server cần khoảng 20s để xử lý. Mã pincode dạng 6 số có thể bruteforce được. URL download file backup tồn tại khoảng 3 phút và có dạng:
https://example.com/backup/[userID]/md5(hhmmss_pincode).zip
Như vậy để khai thác thì hacker cần soạn javascript để nạn nhân gửi hàng loạt request bruteforce pincode tạo file backup. Từ đó hacker sẽ có được pincode của nạn nhân.
Ghi chú:
Kết luận
Từ các ví dụ ở trên chúng ta nhận thấy đều là các dạng tấn công trên các website sử dụng cookie làm cách xác thực. Như vậy có phải đồng nghĩa với việc bó tay với các dạng website xác thực dựa trên Bearer token, Same-origin policy, same site cookie, x-frame header,….???
Câu trả lời là Không. Qua tìm hiểu thì mình thấy vẫn có cách khai thác bug XS-Search bằng cách điều khiển trình duyệt nạn nhân để tấn công, mọi người có thể tham khảo tại report: https://hackerone.com/reports/491473 của bạn terjanq bằng cách sử dụng window.opener.
Ref:
https://book.hacktricks.xyz/pentesting-web/xs-search
https://xsleaks.dev/
https://hackerone.com/reports/491473
- Nạn nhân phải ghé thăm 1 website do hacker kiểm soát.
- Hacker biên soạn và chèn vào các đoạn mã javascript để điều khiển trình duyệt nạn nhân thực hiện khai thác các bug CSRF để leak thông tin và gửi về cho hacker.


- Một cách huyền bí nào đó Chrome không đính kèm cookie khi gửi request fetch lên server qua method POST.
- Trong vòng 2 phút, nếu request đầu được server trả về set-cookie thì khi gửi POST sẽ đính kèm cookie
- Request 01 truy cập 1 ảnh để nhận set-cookie sau đó request 2 mới dùng được.

794 lượt xem