CORS là gì? Cách ngăn chặn tấn công dựa trên CORS

Bạn đang tìm hiểu về Cross-Origin Resource Sharing (CORS), các cuộc tấn công phổ biến dựa vào các lỗ hỏng của CORS, cũng như tìm hiểu về cách chống lại các cuộc tấn công này. Hãy cùng chúng tôi tìm hiểu qua bài viết sau.

Cross-Origin Resource Sharing (CORS) là gì?

CORS là một cơ chế trình duyệt cho phép truy cập có kiểm soát vào các tài nguyên nằm bên ngoài một tên miền nhất định. CORS mở rộng và thêm tính linh hoạt cho Same-Origin Policy (SOP). Dù vậy nếu CORS của trang web có cấu hình và triển khai kém cũng có thể bị tấn công giữa các domain. CORS không phải là biện pháp bảo vệ chống lại các cuộc tấn công cross-origin, chẳng hạn như Cross-Site Request Forgery (CSRF).

Same-Origin Policy (SOP) là gì?

Với chức năng hạn chế giới hạn khả năng trang web tương tác với các tài nguyên bên ngoài. Same-origin policy dùng đối phó với các tương tác giữa các domain có khả năng gây hại.

Nới lỏng same-origin policy

Các cách tiếp cận khác nhau được đưa ra để phá vỡ các hạn chế của SOP. Nhiều trang web tương tác với tên miền phụ hoặc trang web của bên thứ ba theo cách yêu cầu quyền truy cập Cross-origin đầy đủ. Bằng cách sử dụng chia sẻ tài nguyên Cross-origin (CORS) để nới lỏng có kiểm soát chính sách cùng nguồn gốc.

Giao thức CORS sử dụng một HTTP headers xác định nguồn gốc web đáng tin cậy và các thuộc tính liên quan.

Các lỗ hổng phát sinh từ các sự cố cấu hình CORS

Để cho phép truy cập từ tên miền phụ và bên thứ ba đáng tin cậy nhiều trang web hiện đại sử dụng CORS. Tuy vậy để đảm bảo rằng mọi thứ đều hoạt động nên việc triển khai CORS của họ quá dễ dãi dẫn đến các lỗ hổng có thể khai thác được.

Máy chủ tạo ACAO header từ Origin header do máy khách chỉ định

Để cung cấp quyền truy cập vào tên miền khác trong một số ứng dụng cần duy trì danh sách các miền được phép yêu cầu. Một số ứng dụng cho phép truy cập hiệu quả từ bất kỳ miền nào khác một cách dễ dàng vì không muốn lỗi xảy ra phá vỡ chức năng của ứng dụng.

Một cách để thực hiện việc này là đọc Origin header từ các yêu cầu bao gồm header phản hồi cho biết yêu cầu origin được cho phép.

Ví dụ: Nội dung nhận được từ yêu cầu:

{{EJS0}}

Nội dung phản hồi:

{{EJS1}}

Lỗi phân tích cú pháp Origin headers

Một số ứng dụng hỗ trợ sử dụng whitelist các origins được phép để truy cập từ nhiều origins. Origin được cung cấp sẽ được so sánh với whitelist khi nhận được yêu cầu CORS. Ứng dụng cấp quyền truy cập nếu xuất hiện trên danh sách trắng được phản ánh trong Access-Control-Allow-Origin tiêu đề.

Khi triển khai CORS origin whitelists xuất hiện một số lỗi. Một số tổ chức hoặc ứng dụng cho phép truy cập từ tất cả các miền phụ của họ và cả những miền chưa tồn tại. Lỗi trong quá trình triển khai dẫn đến việc cấp quyền truy cập cho các miền bên ngoài không mong muốn..

Giá trị origin null được liệt kê trong Whitelisted

Thông số kỹ thuật cho Origin header hỗ trợ giá trị null. Các trình duyệt có thể gửi giá trị null trong Origin header trong các tình huống bất thường khác nhau:

• Chuyển hướng Cross-origin.
• Yêu cầu từ dữ liệu tuần tự hóa.
• Yêu cầu sử dụng file:giao thức.
• Sandboxed yêu cầu Cross-origin.

Một số ứng dụng có thể đưa origin null vào Whitelisted để hỗ trợ phát triển ứng dụng cục bộ. Kẻ tấn công tạo yêu cầu Cross-origin có chứa giá trị null trong Origin header bằng cách sử dụng nhiều thủ thuật khác nhau. Dẫn đến truy cập tên miền chéo do đáp ứng Whitelisted.

Khai thác XSS thông qua các mối quan hệ tin cậy CORS

Thiết lập mối quan hệ tin cậy giữa hai nguồn gốc dù CORS được định cấu hình “chính xác”. Kẻ tấn công 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 bởi tệp lệnh chéo trang (XSS) bằng cách thêm một số JavaScript..

Đưa ra yêu cầu sau:

{{EJS2}}

Nếu máy chủ phản hồi với:

{{EJS3}}

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 đó để truy xuất khóa API, sử dụng URL như:

{{EJS4}}

Phá vỡ TLS với CORS được cấu hình kém

Giả sử một ứng dụng sử dụng HTTPS nghiêm ngặt đưa vào danh sách trắng một tên miền phụ đang sử dụng HTTP đơn giản. Ví dụ: khi ứng dụng nhận được yêu cầu sau:

{{EJS5}}

Ứng dụng trả lời với:

{{EJS6}}

Ở vị trí chặn lưu lượng truy cập của người dùng, những kẻ tấn công có thể khai thác cấu hình CORS nhằm xâm phạm sự tương tác của người dùng với ứng dụng. Quá trình này thực hiện qua các bước sau:

• Người dùng thực hiện bất kỳ yêu cầu HTTP đơn giản nào.
• Kẻ tấn công chèn một chuyển hướng đến:
  http://trusted-subdomain.vulnerable-website.com
• Trình duyệt của nạn nhân đi 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 có 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 origin:
  http://trusted-subdomain.vulnerable-website.com
• Vì đây là origin có trong Whitelisted nên ứng dụng cho phép yêu cầu. Trong phản hồi dữ liệu nhạy cảm đã yêu cầu được trả về.
• Dưới sự kiểm soát của kẻ tấn công, trang giả mạo truyền đến bất kỳ miền nào những dữ liệu nhạy cảm. Cuộc tấn công này có hiệu quả ngay cả khi trang web dễ bị tấn công mạnh mẽ trong việc sử dụng HTTPS, không có điểm cuối HTTP và tất cả các cookie được gắn cờ là an toàn.

Mạng nội bộ và CORS không có thông tin xác thực

Các cuộc tấn công CORS hầu như dựa trên sự hiện diện của header phản hồi:

{{EJS7}}

Trình duyệt của người dùng sẽ từ chối gửi cookie của họ nếu không có header phản hồi. 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. Vì các trang web này có tiêu chuẩn bảo mật thấp nên tạo cơ hội cho kẻ tấn công tìm ra các lỗ hổng và có thêm quyền truy cập. Ví dụ: yêu cầu Cross-origin trong mạng riêng có thể như sau:

{{EJS8}}

Và máy chủ phản hồi với:

{{EJS9}}

Máy chủ ứng dụng đang tin tưởng các yêu cầu tài nguyên từ bất kỳ origin nào mà không có thông tin xác thực. Kẻ tấn công có thể dựa trên CORS 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ộ khi người dùng trong không gian địa chỉ IP riêng truy cập internet công cộng.

Cách ngăn chặn các cuộc tấn công dựa trên CORS

Các lỗ hổng CORS phát sinh chủ yếu do cấu hình sai. Một số biện pháp phòng thủ hiệu quả chống lại các cuộc tấn công CORS như sau:

Cấu hình chính xác cross-origin requests

Origin phải được chỉ định chính xác trong Access-Control-Allow-Origin header nếu tài nguyên web chứa thông tin nhạy cảm.

Chỉ cho phép các trang web đáng tin cậy

Nguồn gốc được chỉ định trong Access-Control-Allow-Origin header chỉ nên là các trang web đáng tin cậy. Vì kẻ tấn công có thể khai thác khi phản ánh các origins từ các yêu cầu cross-origin mà không cần xác thực.

Tránh danh sách trắng null

Tránh sử dụng header Access-Control-Allow-Origin: null. Các lệnh gọi tài nguyên có Cross-origin từ các tài liệu nội bộ và các yêu cầu có thể chỉ định null origins. Các tiêu đề CORS phải được xác định đúng đối với origins đáng tin cậy cho các máy chủ riêng và công cộng.

Tránh sử dụng ký tự đại diện trong mạng nội bộ

Do trình duyệt nội bộ có thể truy cập các miền bên ngoài không đáng tin cậy nên cấu hình mạng để bảo vệ tài nguyên nội bộ là không đủ.

CORS không thay thế cho các chính sách bảo mật phía máy chủ

Ngoài cấu hình CORS đúng cách. Các máy chủ web nên dùng các biện pháp bảo vệ đối với dữ liệu nhạy cảm. Ví dụ xác thực và quản lý phiên vì kẻ tấn công có thể trực tiếp giả mạo yêu cầu từ bất kỳ Origin đáng tin cậy nào.

Tổng kết về CORS