659
5.Khai thác XSS thông qua các mối quan hệ tin cậy CORS
Ngay cả CORS được định cấu hình “chính xác” cũng thiết lập mối quan hệ tin cậy giữa hai nguồn gốc. Nếu một trang web tin cậy một nguồn gốc dễ bị tấn công bởi tập lệnh chéo trang ( XSS ), thì kẻ tấn công có thể khai thác XSS để tiêm một số JavaScript sử dụng CORS để truy xuất thông tin nhạy cảm từ trang web tin cậy ứng dụng dễ bị tấn công.
Đưa ra yêu cầu sau:
GET /api/requestApiKey HTTP/1.1
Host: vulnerable-website.com
Origin: https://subdomain.vulnerable-website.com
Cookie: sessionid=...
Nếu máy chủ phản hồi với:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://subdomain.vulnerable-website.com
Access-Control-Allow-Credentials: true
Sau đó, kẻ tấn công tìm thấy lỗ hổng XSS
subdomain.vulnerable-website.com có thể sử dụng lỗ hổng đó để lấy khóa API bằng URL như:
https://subdomain.vulnerable-website.com/?xss=<script>cors-stuff-here</script>
GET /api/requestApiKey HTTP/1.1
Host: vulnerable-website.com
Origin: http://trusted-subdomain.vulnerable-website.com
Cookie: sessionid=...
Ứng dụng phản hồi với:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://trusted-subdomain.vulnerable-website.com
Access-Control-Allow-Credentials: true
Trong trường hợp này, kẻ tấn công có khả năng chặn lưu lượng truy cập của người dùng nạn nhân có thể khai thác cấu hình CORS để xâm phạm sự tương tác của nạn nhân với ứng dụng. Cuộc tấn công này bao gồm các bước sau:
- Người dùng nạn nhân thực hiện bất kỳ yêu cầu HTTP đơn giản nào.
- Kẻ tấn công đưa một chuyển hướng tới:
http://trusted-subdomain.vulnerable-website.com - Trình duyệt của nạn nhân tuân theo chuyển hướng.
- Kẻ tấn công chặn yêu cầu HTTP đơn giản và trả về phản hồi giả mạo chứa yêu cầu CORS tới:
https://vulnerable-website.com - Trình duyệt của nạn nhân đưa ra yêu cầu CORS, bao gồm cả nguồn gốc:
http://trusted-subdomain.vulnerable-website.com - Ứng dụng cho phép yêu cầu vì đây là nguồn gốc được đưa vào danh sách trắng . Dữ liệu nhạy cảm được yêu cầu sẽ được trả về trong phản hồi
- Trang giả mạo của kẻ tấn công có thể đọc dữ liệu nhạy cảm và truyền nó đến bất kỳ miền nào dưới sự kiểm soát của kẻ tấn công.
Cuộc tấn công này có hiệu quả ngay cả khi trang web dễ bị tấn công sử dụng HTTPS mạnh mẽ, không có điểm cuối HTTP và tất cả các cookie được gắn cờ là an toàn.
7.Mạng nội bộ và CORS không có thông tin xác thực
Hầu hết các cuộc tấn công CORS đều dựa vào sự hiện diện của tiêu đề phản hồi:
Access-Control-Allow-Credentials: trueNếu không có tiêu đề đó, trình duyệt của người dùng nạn nhân sẽ từ chối gửi cookie của họ, nghĩa là kẻ tấn công sẽ chỉ có quyền truy cập vào nội dung chưa được xác thực mà họ có thể dễ dàng truy cập bằng cách duyệt trực tiếp đến trang web mục tiêu.
Tuy nhiên, có một tình huống phổ biến mà kẻ tấn công không thể truy cập trực tiếp vào trang web: khi trang web đó là một phần của mạng nội bộ của tổ chức và nằm trong không gian địa chỉ IP riêng tư. Các trang web nội bộ thường được áp dụng tiêu chuẩn bảo mật thấp hơn so với các trang web bên ngoài, cho phép kẻ tấn công tìm ra lỗ hổng và giành được quyền truy cập sâu hơn. Ví dụ: một yêu cầu có nguồn gốc chéo trong mạng riêng có thể như sau:
GET /reader?url=example.pdf
Host: intranet.normal-website.com
Origin: https://normal-website.com
Và máy chủ phản hồi với:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Máy chủ ứng dụng đang tin cậy các yêu cầu tài nguyên từ bất kỳ nguồn nào mà không có thông tin xác thực. Nếu người dùng trong không gian địa chỉ IP riêng truy cập internet công cộng thì một cuộc tấn công dựa trên CORS có thể được thực hiện từ trang web bên ngoài sử dụng trình duyệt của nạn nhân làm proxy để truy cập tài nguyên mạng nội bộ.
