CORS là gì?

Trước đây, khi công nghệ Internet vẫn còn mới, các vấn đề về giả mạo yêu cầu liên trang web (CSRF) đã xảy ra. Những vấn đề này diễn ra bằng cách gửi các yêu cầu máy khách giả mạo từ trình duyệt của nạn nhân đến một ứng dụng khác.

Ví dụ: nạn nhân đăng nhập vào ứng dụng ngân hàng của họ. Sau đó, họ bị lừa tải một trang web bên ngoài trên một tab trình duyệt mới. Tiếp theo, trang web bên ngoài sử dụng thông tin chứng thực cookie của nạn nhân và chuyển tiếp dữ liệu đến ứng dụng ngân hàng trong khi giả vờ là nạn nhân. Người dùng trái phép sau đó có quyền truy cập ngoài ý muốn vào ứng dụng ngân hàng.

Để ngăn chặn các vấn đề CSRF như vậy, tất cả các trình duyệt ngày nay triển khai chính sách cùng nguồn gốc.

Chính sách cùng nguồn gốc

Ngày nay, các trình duyệt buộc máy khách chỉ có thể gửi các yêu cầu đến một tài nguyên có cùng nguồn gốc với URL của khách hàng. Giao thức, cổng và tên máy chủ của URL máy khách phải khớp với máy chủ mà nó yêu cầu.

Ví dụ: hãy xem xét sự so sánh nguồn gốc giữa các URL dưới đây với URL máy khách http://store.aws.com/dir/page.html.

URL	Kết quả	Lý do
http://store.aws.com/dir2/new.html	Cùng nguồn gốc	Chỉ khác đường dẫn
http://store.aws.com/dir/inner/other.html	Cùng nguồn gốc	Chỉ khác đường dẫn
https://store.aws.com/page.html	Nguồn gốc khác	Giao thức khác
http://store.aws.com:81/dir/page.html	Nguồn gốc khác	Cổng khác (http:// là cổng 80 theo mặc định)
http://news.aws.com/dir/page.html	Nguồn gốc khác	Máy chủ khác

Vì vậy, chính sách cùng nguồn gốc có tính bảo mật cao nhưng lại thiếu linh hoạt trong các trường hợp sử dụng thực tế.

Chia sẻ tài nguyên giữa các nguồn gốc khác nhau (CORS) là phần mở rộng của chính sách cùng nguồn gốc. Bạn cần cơ chế này để ủy quyền chia sẻ tài nguyên với bên thứ ba bên ngoài. Ví dụ: bạn cần CORS khi muốn kéo dữ liệu từ các API bên ngoài được ủy quyền hoặc công khai. Bạn cũng cần CORS nếu muốn cho phép bên thứ ba được ủy quyền truy cập vào tài nguyên máy chủ của riêng bạn.

Trong HTTP, phương thức yêu cầu là các thao tác dữ liệu mà máy khách muốn máy chủ thực hiện. Các phương thức HTTP phổ biến bao gồm GET, POST, PUT và DELETE.

Trong tương tác chia sẻ tài nguyên giữa các nguồn gốc khác nhau (CORS) thông thường, trình duyệt sẽ gửi cùng lúc yêu cầu và các tiêu đề kiểm soát truy cập. Đây thường là yêu cầu dữ liệu GET và được coi là có mức độ rủi ro thấp.

Tuy nhiên, một số yêu cầu HTTP được coi là phức tạp và cần được máy chủ xác nhận trước khi gửi đi yêu cầu thực tế. Quá trình phê duyệt trước được gọi là yêu cầu trước khi gửi đi.

Yêu cầu giữa các nguồn gốc khác nhau phức tạp

Yêu cầu giữa các nguồn gốc khác nhau sẽ phức tạp nếu chúng sử dụng bất kỳ yếu tố nào sau đây:

• Phương thức khác ngoài GET, POST, hoặc HEAD
• Tiêu đề khác ngoài Accept-Language, Accept hoặc Content-Language
• Tiêu đề Content-Type khác ngoài multipart/form-data, application/x-www-form-urlencoded hoặc text/plain

Do vậy, ví dụ như các yêu cầu xóa hoặc sửa đổi dữ liệu hiện có được coi là phức tạp.

Cách thức hoạt động của yêu cầu trước khi gửi đi

Trình duyệt tạo các yêu cầu trước khi gửi đi nếu cần thiết. Đây là một yêu cầu OPTIONS giống như sau.

OPTIONS /data HTTP/1.1 Nguồn gốc: https://example.com Access-Control-Request-Method: DELETE

Trình duyệt sẽ gửi yêu cầu trước khi gửi đi trước thông báo về yêu cầu thực tế. Máy chủ phải phản hồi yêu cầu trước khi gửi đi với thông tin về những yêu cầu giữa các nguồn gốc khác nhau mà máy chủ sẵn sàng chấp nhận từ URL máy khách. Tiêu đề phản hồi của máy chủ phải bao gồm những yếu tố sau:

• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Origin

Dưới đây là một ví dụ về phản hồi của máy chủ.

HTTP/1.1 200 OK Access-Control-Allow-Headers: Content-Type Access-Control-Allow-Origin: https://news.example.com Access-Control-Allow-Methods: GET, DELETE, HEAD, OPTIONS

Phản hồi đối với yêu cầu trước khi gửi đi đôi khi bao gồm thêm tiêu đề Access-Control-Max-Age. Chỉ số này xác định thời lượng (tính bằng giây) cho trình duyệt để lưu kết quả của yêu cầu trước khi gửi đi vào bộ nhớ đệm trong trình duyệt. Lưu bộ nhớ đệm cho phép trình duyệt gửi nhiều yêu cầu phức tạp giữa các yêu cầu trước khi gửi đi. Trình duyệt không phải gửi một yêu cầu trước khi gửi đi khác cho đến khi thời gian được chỉ định bởi max-age kết thúc.

 

Bạn nên lưu ý những điều sau khi cấu hình chia sẻ tài nguyên giữa các nguồn gốc khác nhau (CORS) trên máy chủ của bạn.

Xác định danh sách truy cập thích hợp

Tốt nhất là luôn cấp quyền truy cập cho các miền riêng lẻ bằng cách sử dụng danh sách phân tách bằng dấu phẩy. Tránh sử dụng ký tự đại diện trừ khi bạn muốn công khai API. Nếu không, việc sử dụng ký tự đại diện và biểu thức chính quy có thể tạo ra các lỗ hổng bảo mật.

Ví dụ: giả sử bạn viết một biểu thức chính quy cấp quyền truy cập vào tất cả các trang web có hậu tố permitted-website.com. Chỉ với một biểu thức, bạn cấp quyền truy cập vào api.permitted-website.com và news.permitted-website.com. Nhưng bạn cũng vô tình cấp quyền truy cập vào các trang web trái phép có thể sử dụng các miền như maliciouspermitted-website.com.

Tránh sử dụng nguồn gốc có giá trị null trong danh sách của bạn

Một số trình duyệt gửi giá trị null trong tiêu đề yêu cầu cho một số tình huống như yêu cầu tệp hoặc yêu cầu từ máy chủ cục bộ.

Tuy nhiên, bạn không nên bao gồm giá trị null trong danh sách truy cập của mình. Điều này cũng gây ra các rủi ro bảo mật vì những yêu cầu trái phép chứa các tiêu đề null có thể được cấp quyền truy cập.