CORS là gì? Giải thích truy cập chéo nguồn của trình duyệt

CORS là gì?

Chia sẻ Tài nguyên Chéo Nguồn, hay CORS, là một cơ chế tiêu đề HTTP cho phép máy chủ cho trình duyệt biết các nguồn khác nào có thể đọc một phản hồi qua các yêu cầu điều khiển bằng kịch bản. Một nguồn được xác định bởi sơ đồ, máy chủ và cổng. CORS nới lỏng chính sách cùng nguồn của trình duyệt cho các phản hồi được phê duyệt; nó không xác thực người dùng, ủy quyền cho các hành động kinh doanh, hoặc ngăn chặn các khách hàng không phải trình duyệt gửi yêu cầu HTTP.

Định nghĩa hữu ích bao gồm cả cơ chế và ranh giới của nó. CORS ảnh hưởng đến một phần cụ thể của một cuộc trao đổi, trong khi các trách nhiệm kề bên vẫn được giữ lại với HTTP, trình duyệt, giao thông đã chọn, ứng dụng, hoặc mô hình dữ liệu của máy chủ. Giữ cho các lớp đó tách biệt giúp báo cáo lỗi có thể tái tạo và ngăn chặn việc thay đổi cấu hình bị nhầm là quyết định kiểm soát truy cập.

Đối với các nhà phát triển API, câu hỏi đầu tiên là ai tạo ra giá trị hoặc hành vi. Câu hỏi tiếp theo là ai diễn giải nó. Câu hỏi cuối cùng là kết quả quan sát nào chứng minh rằng việc diễn giải đã hoạt động. Ba câu trả lời đó biến một thuật ngữ từ điển thành một hợp đồng giao diện có thể kiểm tra.

Cách mà trình duyệt đưa ra quyết định CORS

Kịch bản trang gọi fetch hoặc XMLHttpRequest cho một URL mà nguồn gốc khác với nguồn gốc của trang. Trình duyệt thêm một trường Nguồn gốc xác định nguồn gốc của người gọi. Đối với một số yêu cầu, nó gửi yêu cầu thực tế trực tiếp; đối với những yêu cầu khác, nó trước tiên gửi một yêu cầu OPTIONS mô phỏng mô tả phương thức dự kiến và các trường không nằm trong danh sách an toàn.

Máy chủ đánh giá nguồn gốc và trả về các trường phản hồi kiểm soát truy cập. Access-Control-Allow-Origin đặt tên nguồn gốc mà kịch bản có thể đọc phản hồi, hoặc sử dụng một ký tự đại diện trong các trường hợp không yêu cầu xác thực đủ điều kiện.

Trình duyệt so sánh phản hồi với bối cảnh yêu cầu. Nếu chính sách không khớp, kịch bản bị chặn không được đọc phản hồi được bảo vệ mặc dù máy chủ có thể đã xử lý yêu cầu HTTP. Sự phân biệt này giải thích tại sao một bảng điều khiển hiển thị lỗi CORS trong khi nhật ký máy chủ hiển thị một yêu cầu đến.

Các yêu cầu có xác thực có quy tắc chặt chẽ hơn. Một nguồn gốc ký tự đại diện không thể được sử dụng với các chứng thực của trình duyệt, và máy chủ phải phép rõ ràng chứng thực. Các quy tắc Cookie SameSite và ủy quyền ứng dụng vẫn áp dụng độc lập.

Các Trường CORS Định nghĩa Quyền truy cập

Các thuật ngữ sau đây phân tách các thành phần thường được gộp thành một nhãn. Đọc chúng như các giao diện giữa các bên tham gia hơn là như trang trí trong một bản theo dõi mạng.

Tại sao CORS quan trọng trong thu thập dữ liệu web

CORS có thể thay đổi các byte nào đến, cách các byte đó được diễn giải, hoặc liệu mã trình duyệt có thể quan sát kết quả hay không. Một quy trình thu thập nên xác định hiệu ứng đó trước khi thay đổi công cụ. Ghi lại URL đã yêu cầu, URL cuối, trạng thái phản hồi, loại đại diện, các trường giao thức liên quan, và một dấu hiệu nội dung mong đợi. Bản ghi ngắn gọn đó phân biệt một trang đúng đắn khỏi một thông điệp truy cập, màn hình đồng ý, mục tiêu chuyển hướng, vỏ ứng dụng trống, hoặc mã hóa không tương thích.

HTTP trực tiếp là con đường thu thập đơn giản nhất khi dữ liệu cần thiết tồn tại trong phản hồi được máy chủ tạo ra mở. Một trình duyệt trở nên liên quan khi nội dung được phê duyệt phụ thuộc vào việc thực thi JavaScript, trạng thái do trình duyệt quản lý, điều hướng, hoặc chính sách bảo mật của trình duyệt. Hai con đường không nên bị ép phải nhìn giống nhau: trình duyệt quản lý cookie, nén, chuyển hướng, CORS, và lưu trữ theo quy tắc nền tảng, trong khi một khách hàng trực tiếp phơi bày một tập hợp khác của các mặc định.

Tính liên tục phiên rất quan trọng bất cứ khi nào một phản hồi thiết lập trạng thái cho yêu cầu tiếp theo. Giữ một chuỗi được ủy quyền bên trong một ngữ cảnh khách hàng cục bộ, bảo tồn địa điểm và nguồn gốc mạng cần thiết, và tránh trộn lẫn trạng thái từ các công việc không liên quan. Một proxy thay đổi nguồn gốc mạng; nó không tái tạo tiêu đề, giải mã đại diện, thực thi kịch bản, hoặc cấp quyền truy cập vào nội dung bị hạn chế.

Phân tích chỉ bắt đầu sau khi xác thực đại diện. Xác nhận máy chủ cuối cùng, danh tính chuẩn xác nếu có, loại phương tiện, trạng thái giải mã và dấu hiệu kinh doanh cần thiết trước khi trích xuất các trường. Thứ tự này ngăn chặn bộ phân tích quy đổi tài liệu lỗi thành các bản ghi trống mà dường như thành công về mặt kỹ thuật.

Các trung gian xứng đáng được chú ý rõ ràng. Một mạng lưới phân phối nội dung có thể chọn một biến thể đã mã hóa, một cổng có thể trả lời OPTIONS, một bộ nhớ đệm có thể sử dụng lại phản hồi đã thương lượng, và một máy chủ ứng dụng có thể đặt cookie hoặc các trường ủy quyền. So sánh chỉ mã ứng dụng với đầu ra trang cuối cùng bỏ qua lớp có thể đã đưa ra quyết định.

API Thu thập Công khai không rác là liên quan khi một nhóm cần việc thu thập quản lý nội dung công khai được phép, bao gồm các trang được render bằng JavaScript. Hợp đồng thu mua vẫn nên xác định mục tiêu, các trường được phép, đại diện mong đợi, dấu hiệu chấp nhận và các điều kiện dừng. Khả năng sản phẩm không thay thế các điều khoản nguồn, đánh giá quyền riêng tư, hoặc xác thực cấp ứng dụng.

Cấu hình CORS phù hợp với sản phẩm thực

CORS có vị trí trong một kiến trúc khi nó thay đổi hành vi sản phẩm cụ thể, yêu cầu tương thích, hoặc quyết định chẩn đoán. Những trường hợp sử dụng này mô tả công việc trước tiên và tính năng giao thức thứ hai.

CORS, Chính sách cùng nguồn, CSRF và Xác thực

CORS thuộc về một lớp HTTP và không nên nhầm lẫn với các lớp liền kề. Một triển khai hợp lý xác định thành phần nào chọn giá trị, thành phần nào có thể thay đổi nó, và bằng chứng gì chứng minh rằng đại diện cuối cùng là chính xác.

Một so sánh chỉ hữu ích nếu nó giữ nguyên ranh giới lớp. Hai cơ chế có thể đồng hành trong một yêu cầu, và việc thay thế một không tự động thay thế cái kia. Tài liệu hành vi đã chọn dưới dạng đầu vào, đầu ra quan sát được, trạng thái thất bại, và quyền sở hữu.

Các cấu hình CORS sai và các sửa chữa giả tạo

• Phản ánh mọi Gốc. Phản hồi đầu vào không được xác thực có thể cấp quyền truy cập đọc cho gốc của kẻ tấn công.
• Sử dụng ký tự đại diện với xác thực. Các yêu cầu trình duyệt có xác thực yêu cầu một nguồn cho phép rõ ràng thay vì quyền cho phép ký tự đại diện.
• Xem CORS như xác thực. CORS chi phối quyền truy cập phản hồi của trình duyệt; máy chủ vẫn phải xác thực và ủy quyền cho mỗi hoạt động.
• Thêm tiêu đề chỉ cho các phản hồi thành công. Các lỗi và phản hồi preflight cũng cần các trường chính sách cần thiết để trình duyệt có thể hiển thị các chẩn đoán hữu ích.
• Sử dụng no-cors để giải quyết truy cập. Phản hồi mờ không phải là phản hồi API đọc được bình thường và không cấp quyền cho máy chủ bị thiếu.
• Quên biến thể bộ nhớ đệm. Các phản hồi nguồn động nên tính toán cho Origin trong hành vi bộ nhớ đệm để quyền của một thuê bao không được phục vụ cho người khác.

Hầu hết các lỗi trở nên dễ chẩn đoán hơn sau khi loại bỏ các giả định về những gì một thư viện hoặc trình duyệt đã làm tự động. Ghi lại một dấu vết tối thiểu, chỉnh sửa bí mật, và thay đổi một biến điều khiển tại một thời điểm. Mục tiêu là có một giải thích ổn định về đại diện được trả về, không phải là một tập hợp các điều chỉnh tiêu đề không liên quan.

Chẩn đoán CORS Từ Trang đến Nguồn gốc

Chuỗi này hoạt động như một đánh giá thiết kế trước khi ra mắt và như một chẩn đoán sản xuất sau khi thay đổi hành vi. Nó giữ bằng chứng giao thức liên kết với kết quả ứng dụng.

1. Ghi lại nguồn gốc trang và nguồn gốc mục tiêu dưới dạng sơ đồ, máy chủ và cổng.
2. Kiểm tra bảng mạng của trình duyệt để xác định xem giao dịch thất bại là preflight hay yêu cầu thực tế.
3. Kiểm tra trường yêu cầu Origin và giá trị Access-Control-Allow-Origin chính xác trong phản hồi.
4. Đối với preflight, so sánh phương thức yêu cầu và tên trường với danh sách được phép của máy chủ.
5. Đối với thông tin xác thực, xác minh quyền truy cập nguyên gốc rõ ràng, quyền thông tin xác thực, quy tắc cookie và ủy quyền ứng dụng một cách riêng biệt.
6. Kiểm tra chuyển hướng và phản hồi cổng vì một lớp khác có thể bỏ qua các trường cần thiết.
7. Xác thực với ngữ cảnh trình duyệt thực; một thành công trên dòng lệnh không chứng minh rằng chính sách trình duyệt được thông qua.

Hoàn thành đánh giá bằng cách lưu một mẫu chấp nhận nhỏ và một mẫu bị từ chối với cùng quy tắc chỉnh sửa. Các thay đổi trong tương lai có thể được so sánh với danh tính trang đã biết, các trường mong đợi và nội dung đã giải mã chứ không chỉ là bộ nhớ hoặc ảnh chụp màn hình.

Bảo mật và Quan sát cho CORS

CORS tham gia vào một đường dẫn yêu cầu có thể vượt qua các trình duyệt, cổng, bộ nhớ đệm và máy chủ nguồn gốc. Mỗi bước nhảy nên chỉ chấp nhận các giá trị mà nó hiểu, bảo tồn các trường mà phải sống sót và tránh sao chép thông tin xác thực hoặc dữ liệu cá nhân vào nhật ký. Cú pháp giao thức không phải là ủy quyền.

Hồ sơ hoạt động nên ghi lại URL yêu cầu, URL cuối cùng, trạng thái, loại đại diện, tên trường liên quan và một dấu hiệu nội dung giới hạn. Các thân đầy đủ và giá trị thông tin xác thực hiếm khi cần cho chẩn đoán thông thường và có thể tạo ra rủi ro giữ lại không cần thiết.

Hành vi trình duyệt và hành vi HTTP trực tiếp là những bề mặt thử nghiệm khác nhau. CORS, lưu trữ cookie, giải nén tự động và xử lý chuyển hướng có thể được thực hiện bởi trình duyệt hoặc thư viện trước khi mã ứng dụng nhìn thấy một kết quả. Ghi lại khách hàng và các mặc định của nó khi so sánh các thiết lập.

Các Tiêu chuẩn Định nghĩa CORS

chuẩn CORS Fetch định nghĩa quy trình CORS trình duyệt hiện tại. Nguồn chính này sửa chữa từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi triển khai vẫn cần được quan sát trong khách hàng và việc triển khai đã chọn.

Hướng dẫn CORS của MDN giải thích các trao đổi đơn giản và preflight. Nguồn chính này sửa chữa từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi triển khai vẫn cần được quan sát trong khách hàng và việc triển khai đã chọn.

đặc tả nguồn gốc web định nghĩa khái niệm nguồn gốc được sử dụng bởi bảo mật web. Nguồn chính này sửa chữa từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi triển khai vẫn cần được quan sát trong khách hàng và việc triển khai đã chọn.

Hướng dẫn chính sách cùng nguồn gốc của MDN mô tả ranh giới trình duyệt mà CORS có thể nới lỏng. Nguồn chính này sửa chữa từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi triển khai vẫn cần được quan sát trong khách hàng và việc triển khai đã chọn.

Mô Hình Tâm Lý CORS Chính Xác

CORS là quyền đọc phản hồi do trình duyệt thực thi được kiểm soát bởi các trường máy chủ; nó bổ sung vào xác thực, ủy quyền, chính sách cookie và các biện pháp bảo vệ chống lại yêu cầu giả mạo thay vì thay thế chúng.

Đưa quy tắc đó vào một bài kiểm tra chấp nhận. Nêu rõ ai là người tham gia gửi tín hiệu, ai là người tham gia giải thích, những trung gian nào có thể thay đổi đường đi, và dấu hiệu nội dung nào chứng minh thành công. Điều này làm cho CORS trở thành một phần của hệ thống có thể quan sát chứ không chỉ là một nhãn đính kèm sau một thất bại.

Tài liệu tham khảo

• Tài liệu API Ghi lại toàn cầu của Scrapeless
• Tổng quan sản phẩm API Ghi lại toàn cầu của Scrapeless
• Hướng dẫn Scrapeless về tiêu đề, cookie, phiên làm việc và xác thực đại diện
• Scrapeless trên GitHub