Tiếng Việt

Video và phụ đề · Direct Media Downloader

Lịch sử ngắn gọn về chính sách cùng nguồn gốc và CORS trong trình duyệt web

· Lý lịch

cors web-history bảo vệ

Nguồn gốc trình duyệt ban đầu phát triển thành quyền truy cập HTTP nhiều nguồn gốc được kiểm soát
Hình minh họa vector ToolAcre gốc

Quy tắc ngăn công cụ trình duyệt tự do đọc các tệp của trang web khác có từ các trình duyệt tập lệnh sớm nhất. Bài đăng này theo dõi chính sách cùng nguồn gốc, XMLHttpRequest và tiêu chuẩn CORS mà cuối cùng đã giúp cho việc tìm nạp giữa các trang web được kiểm soát có thể thực hiện được.

Tại sao trình duyệt từ chối trao tab của riêng bạn số byte mà nó vừa nhận được - hậu quả hàng ngày của một quy tắc đã tồn tại hàng thập kỷ

Trình duyệt có thể hiển thị tệp từ xa nhưng từ chối cung cấp nội dung phản hồi đó cho trang JavaScript. Sự mâu thuẫn rõ ràng là sự tách biệt về mặt bảo mật giữa điều hướng và đọc chéo nguồn gốc theo chương trình.

Direct Media Downloader gặp phải quy tắc này vì nó phải đọc các đoạn vào Blob. Liên kết Lưu gốc có thể hoạt động khi Tìm nạp không thành công vì nó đi theo một đường dẫn trình duyệt khác. Việc từ chối bảo vệ cookie và tài nguyên mạng nội bộ ở những nơi khác trong trình duyệt, ngay cả khi trình tải xuống cụ thể này cố tình bỏ qua thông tin xác thực khỏi lệnh gọi của chính nó. Ranh giới bảo vệ các cookie và trang mạng nội bộ không liên quan trong cùng một trình duyệt ngay cả khi yêu cầu cụ thể này bỏ qua thông tin xác thực.

Netscape, JavaScript và quy tắc gốc đầu tiên — vấn đề bảo mật đã thúc đẩy chính sách cùng nguồn gốc

Kịch bản web ban đầu khiến việc ngăn một trang web đọc các trang nhạy cảm của trang khác thông qua quyền truy cập xung quanh của khách truy cập là cần thiết. Các trình duyệt đã tổ chức ranh giới đó xung quanh nguồn gốc.

Các chi tiết lịch sử khác nhau trong quá trình triển khai, do đó, tính kế thừa thực tế quan trọng nhất: lược đồ, máy chủ và cổng xác định ngăn tin cậy cho các tài nguyên có thể đọc được tập lệnh. Việc coi nguồn gốc là một đơn vị là một ranh giới kỹ thuật có thể được thực thi nhất quán trên các tài liệu, tập lệnh và API mạng. Nhóm nguồn gốc cung cấp một đơn vị có thể thực thi được mà các công cụ trình duyệt có thể áp dụng trên các tài liệu, tập lệnh, bộ lưu trữ và phản hồi mạng. Mô hình này không hoàn hảo nhưng cung cấp cho các nhà phát triển một giá trị mặc định có thể dự đoán được thay vì quyền hạn không hạn chế xung quanh.

XMLHttpRequest và trang web có tường ngăn — các yêu cầu theo kịch bản kế thừa quy tắc như thế nào và tại sao các ứng dụng kết hợp lại gặp khó khăn

Nền đã bật XMLHttpRequest HTTP hoạt động nhưng vẫn giữ lại các hạn chế về nguồn gốc. Điều đó làm cho các ứng dụng cùng một trang trở nên hữu ích trong khi các ứng dụng kết hợp giữa các trang web yêu cầu sự hợp tác hoặc máy chủ trung gian.

Ghi đè máy khách phổ quát sẽ phá hủy sự bảo vệ. Máy chủ sở hữu mục tiêu cần một cách để thể hiện nguồn gốc bên ngoài nào có thể đọc các phản hồi đã chọn. Chuyển tiếp máy chủ đã trở thành giải pháp phổ biến nhưng chúng đã chuyển rủi ro về độ tin cậy, băng thông và giả mạo yêu cầu sang cơ sở hạ tầng bên ngoài hộp cát của trình duyệt. Các giải pháp chuyển tiếp đã chuyển băng thông, độ tin cậy và rủi ro giả mạo yêu cầu phía máy chủ ra ngoài hộp cát máy khách thay vì loại bỏ chính sách. Những bên trung gian đó cần có các biện pháp kiểm soát bảo mật, quyền riêng tư và lạm dụng riêng khi chúng được triển khai có chủ ý.

Tiêu chuẩn CORS — cách tiêu đề Access-Control cho phép máy chủ chọn tham gia đọc nhiều nguồn gốc mà không nới lỏng mặc định

CORS cung cấp sự hợp tác đó thông qua HTTP tiêu đề phản hồi được trình duyệt diễn giải. `Access-Control-Allow-Origin` có thể ủy quyền cho nguồn yêu cầu hoặc, trong các trường hợp không có thông tin xác thực phù hợp, đối tượng rộng hơn.

Cơ chế này không vô hiệu hóa chính sách cùng nguồn gốc trên toàn cầu. Nó cấp quyền truy cập đọc trong phạm vi các phản hồi mà máy chủ chọn hiển thị chúng theo giao thức. Kết quả preflight có thể được trình duyệt lưu vào bộ nhớ đệm theo các quy tắc giao thức, do đó quá trình kiểm tra không nên suy ra "chưa từng xảy ra kiểm tra chính sách nào" từ một dấu vết ấm. Điều này duy trì sự cô lập mặc định trong khi cho phép chủ sở hữu tài nguyên xuất bản một ngoại lệ có chủ ý cho những người gọi và phương thức đã chọn.

Kiểm tra trước, yêu cầu đơn giản và phản hồi không rõ ràng - từ vựng giải thích hầu hết các lỗi tải xuống

Một số yêu cầu có nguồn gốc chéo đủ đơn giản để không yêu cầu ánh sáng trước; những người khác trước tiên gửi OPTIONS để hỏi liệu phương thức và tiêu đề có được phép hay không. Preflight là đàm phán, không phải chuyển giao phương tiện thực tế.

Phản hồi không rõ ràng phát sinh từ chế độ không có cors và ẩn trạng thái, tiêu đề và nội dung khỏi tập lệnh. ToolAcre không chọn chế độ đó vì nội dung không thể đọc được không thể trở thành Blob có thể lưu được dự kiến. Lỗi CORS có thể cùng tồn tại với yêu cầu phía máy chủ thành công, củng cố lý do tại sao ứng dụng bị lỗi không có nghĩa là nguồn gốc không nhận được gì. Các quyết định trước chuyến bay được lưu trong bộ nhớ đệm có thể thay đổi những gì xuất hiện trong một dấu vết ấm áp, vì vậy sự vắng mặt lịch sử của OPTIONS không phải là bằng chứng cho thấy thương lượng chưa từng tồn tại.

CORS có ý nghĩa gì đối với trình tải xuống chỉ dành cho trình duyệt — máy chủ quyết định, công cụ không thể ghi đè và sự trung thực về điều đó là phản hồi đúng đắn

Đối với trình tải xuống này, máy chủ sẽ quyết định xem các phản hồi HEAD và GET có đọc được hay không. ToolAcre không thể thay mặt máy chủ đính kèm tiêu đề phản hồi cho phép nguồn gốc và nó sẽ không chuyển tiếp nội dung thông qua nguồn gốc của chính nó.

Lỗi kết hợp CORS và các khả năng của mạng do Tìm nạp cố tình giữ lại thông tin chi tiết trong một số lỗi. DevTools có thể tiết lộ cho khách truy cập nhiều hơn những gì mã ứng dụng nhận được. Người vận hành máy chủ chỉ nên ủy quyền nguồn gốc, phương thức và tiêu đề dự kiến, sau đó xác minh phản hồi sản xuất chính xác của họ thay vì dựa vào mục đích cấu hình cục bộ. Quá trình đọc bị chặn có thể cùng tồn tại với máy chủ đã nhận được yêu cầu, đó là lý do tại sao giao diện không bao giờ coi lỗi ứng dụng là do không có liên hệ.

Bài học rút ra: một quy tắc bảo vệ bạn ngay cả khi điều đó làm bạn khó chịu - cách Direct Media Downloader hoạt động bên trong nó chứ không phải xung quanh nó

Quy tắc này bảo vệ người dùng ngay cả khi nó cản trở việc truyền tệp hợp pháp. Máy chủ muốn ứng dụng trình duyệt đọc phương tiện công cộng có thể định cấu hình phản hồi CORS thích hợp; một cái không thể truy cập được thông qua đường dẫn tập lệnh này.

Direct Media Downloader hoạt động bên trong mô hình đó: xác thực cục bộ, yêu cầu công khai, giải thích từ chối và đề xuất lưu gốc khi phù hợp. Nó không biến ranh giới bảo mật của trình duyệt thành một vấn đề vượt qua. Hiểu rằng lịch sử sẽ biến lỗi từ sự thù địch tùy ý của trình duyệt thành hậu quả rõ ràng của mô hình đọc trên nhiều trang web từ chối mặc định. Chủ sở hữu nguồn gốc nên kiểm tra các tiêu đề sản xuất chính xác cho các phương pháp dự định thay vì chỉ dựa vào cấu hình trang tổng quan.