Client-Side Path Traversals
CSPT xuất hiện ngày càng nhiều do các modern app hoạt động dựa theo cơ chế client-side rendering thay vì server-side rendering như trước đây. Cụ thể hơn, thay vì load toàn bộ HTML/CSS/JS từ server trong 1 request duy nhất, các modern app sẽ chỉ load về client-side script và sau đó trigger một request đến backend để lấy data và đưa cho client-side script để render.
Target mà các tác giả test có CSPT ở endpoint /categories/[number]: nó sẽ trigger một request gửi đến /api/v2/categories/[number].json. Hơn thế nữa, front-end truy xuất các giá trị trong JSON response trả về và render ra giao diện sử dụng innerHTML. Nếu ta có thể kiểm soát được nội dung JSON trả vì có thể thực hiện XSS.
Lý tưởng nhất là tìm ra một controlled JSON file ở các endpoint có prefix là /api/v2. Hoặc tìm được một endpoint có thể thực hiện open redirect chẳng hạn như /api/v2/redirect?url=[redirect_url]. Khi đó, CSPT payload có thể là /categories/..%2fredirect%3furl%3d=malicious.com (chúng ta cần encode để nó trở thành một ID hợp lệ và không phải là một path segment hay query param). Payload này khi decode sẽ trở thành /categories/../redirect?url=malicious.com. Domain malicious.com có thể là nơi mà ta host malicious JSON.
Tuy nhiên, các tác giả không tìm được endpoint nào có thể thực hiện open redirect.
Paying for More Attack Surface
Đôi khi việc trả tiền để mở khóa các tính năng có thể giúp mở rộng attack surface. Các tác giả đã mua membership để mở khóa tính năng upload file kỹ thuật số và cho phép chúng ta bán nó.
API lấy file tại /api/marketplace/files/[file_number] sẽ trả về một S3 pre-signed URL1 cho từng file được upload để truy cập. Tuy nhiên, chúng ta không thể traverse đến domain của S3 sử dụng CSPT.
Sau đó các tác giả tìm thấy param ?redirect=true trên endpoint /api/marketplace/files/[file_number] cho phép trigger một redirect đến S3 URL. Đây chính là điều kiện cần để hoàn thành chuỗi tấn công XSS sử dụng CSPT.
Kịch bản tấn công xảy ra như sau:
- Upload file JSON chứa XSS payload
- Tạo CSPT payload sử để traverse đến
/api/marketplace/files/[file_number]?redirect=true. Payload có dạng như sau:/categories/..%2Fmarketplace%2Ffiles%2F1234%3Fredirect%3Dtrue%23. - Gửi link đến cho user.
CORS Issues
Khi file được upload lên S3 bucket, nó có một service CloudFront phía trước dùng để caching. Sau khi file được upload, ứng dụng sẽ hiển thị một nút để download file và request tương ứng với nút này không có Origin header. Điều này khiến cho response không có header Access-Control-Allow-Origin và CloudFront sẽ cache response này. Dẫn đến, response của tất cả các cross-origin request đều bị block bởi trình duyệt.
Để giải quyết vấn đề này, ta có thể không nhấn vào nút download hoặc intercept download request và tự thêm vào Origin: anything. Tuy nhiên, cả 2 cách này đều rất khó chịu.
Self-XSS
Cần chú ý rằng file được upload lên là được dùng để bán. Dẫn đến user thông thường không thể truy cập thông qua /api/marketplace/files/1234 trừ khi họ mua nó và điều này cần rất nhiều user interaction.
Cookies and Paths
XSS chỉ có ở tài khoản của chúng ta, để khai thác ở phía nạn nhân, ta cần họ log in vào tài khoản của chúng ta hoặc ít nhất là log in vào path /api/marketplace/files/1234. Để làm được điều này, ta sẽ set cookie Session bằng token của chúng ta cho path /api/marketplace/files/1234. Do browser ưu tiên sử dụng cookie có path cụ thể hơn nên cookie của attacker sẽ được sử dụng khi victim truy cập vào /api/marketplace/files/1234.
Việc tìm thấy một gadget để set cookie cho trình duyệt của nạn nhân là hoàn hảo chẳng hạn như việc sử dụng các UTM parameters - do chúng thường được reflected thành cookie và đôi khi ta có thể escape để set cookie. Chúng ta cũng có thể sử dụng kỹ thuật Cookie Sandwich do chúng ta đã có XSS. Tuy nhiên cả 2 gadget này đều không có.
CSRF
Các bug hunter thường bỏ qua login CSRF và logout CSRF do chúng không có impact. Login CSRF sử dụng OAuth hoạt động bằng cách intercept redirect request cuối cùng để trích xuất code trước khi nó được sử dụng bởi trình duyệt. URL của request này có thể được dùng để login vào tài khoản của attacker từ bất kỳ đâu.
Hơi bực bội nhưng ta phải tạo ra các login URL mỗi lần thực hiện test CSRF.Target của các tác giả có login CSRF và kịch bản tấn công giờ đây diễn ra như sau:
- Log in vào tài khoản của chúng ta
- Redirect đến CSPT URL
- Trigger XSS
Tuy nhiên, do victim log in vào tài khoản của chúng ta, XSS không có nhiều impact. Thay vào đó, ta muốn thực hiện các action ở trên tài khoản của victim chẳng hạn như thay đổi email hay account takeover. Chúng ta cần tìm cách để chuyển victim về lại tài khoản của họ.
Cookie Bombing
Làm sao để log out victim ra khỏi tài khoản của attacker và khiến cho victim log in vào lại tài khoản của hộ. Ta có thể nghĩ đến việc sử dụng document.cookie nhưng do có attribute httpOnly nên không thể thay đổi giá trị của nó. Tuy nhiên, ta có thể sử dụng kỹ thuật cookie bombing:
for (let i = 0; i < 50000; i++) {
document.cookie = "check" + i + "=" + i + "; max-age=600;secure";
}Đoạn code trên sẽ thêm vào trình duyệt thật nhiều cookie và làm cho header Cookie có trong request gửi đến target quá lớn so với khả năng xử lý của server. Kết quả là server reject request và làm user bị log out.
Double XSS
Chuỗi tấn công cuối cùng cần 2 lần thực thi XSS. Lần đầu tiên để thực hiện cookie bombing victim và set Session cookie cho path /api/marketplace/files. XSS đầu tiên này cũng prompt user để họ log in vào tài khoản của họ một cách thủ công bằng cách mở một cửa sổ mới đến trang log in. Kể cả khi victim log in vào tài khoản của họ thì browser vẫn sẽ dùng attacker cookie cho path /api/marketplace/files.
Sau khi victim log in vào tài khoản của họ thì chúng ta sẽ redirect đến XSS thứ hai sử dụng CSPT. Cuối cùng, ta có thể gây ra impact tùy ý chẳng hạn như thay đổi nội dung hoặc tạo thêm post bằng quyền của user.
Resources
Footnotes
-
Là một URL dùng để truy cập vào một object nào đó của S3 bucket trong một khoảng thời gian được phép. Presigned URL được tạo ra bằng cách sử dụng các security credentials của owner. Xem thêm: Sharing objects with presigned URLs - Amazon Simple Storage Service ↩