Làm thế nào để các máy chủ web thực thi chính sách cùng nguồn gốc?

Tôi đang đi sâu hơn vào việc phát triển API RESTful và cho đến nay đã làm việc với một vài khung công tác khác nhau để đạt được điều này. Tất nhiên tôi đã chạy theo chính sách cùng nguồn gốc và bây giờ tôi đang tự hỏi làm thế nào các máy chủ web (chứ không phải trình duyệt web) thi hành nó. Theo những gì tôi hiểu, một số thực thi dường như xảy ra ở cuối trình duyệt (ví dụ: tôn vinh tiêu đề Access-Control-Allow-Origin nhận được từ máy chủ). Nhưng còn máy chủ thì sao?

Ví dụ: giả sử một máy chủ web đang lưu trữ ứng dụng web Javascript truy cập API, cũng được lưu trữ trên máy chủ đó. Tôi giả định rằng máy chủ sẽ thực thi chính sách cùng nguồn gốc --- để chỉ javascript được lưu trữ trên máy chủ đó mới được phép truy cập API. Điều này sẽ ngăn người khác viết một ứng dụng khách javascript cho API đó và lưu trữ nó trên một trang web khác, phải không? Vậy làm thế nào để một máy chủ web có thể ngăn chặn một máy khách độc hại cố gắng thực hiện các yêu cầu AJAX đến các điểm cuối API của nó trong khi tuyên bố đang chạy javascript có nguồn gốc từ cùng một máy chủ web đó? Cách các máy chủ phổ biến nhất (Apache, nginx) bảo vệ chống lại loại tấn công này là gì? Hoặc là sự hiểu biết của tôi về điều này bằng cách nào đó không đúng?

Hoặc chính sách nguồn gốc chéo chỉ được thi hành ở cuối máy khách?

Chính sách nguồn gốc tương tự là một hạn chế hoàn toàn dựa trên khách hàng và chủ yếu được thiết kế để bảo vệ người dùng , không phải dịch vụ . Tất cả hoặc hầu hết các trình duyệt bao gồm một công tắc dòng lệnh hoặc tùy chọn cấu hình để tắt nó. SOP giống như dây an toàn trong xe hơi: chúng bảo vệ người lái trong xe, nhưng bất kỳ ai cũng có thể tự do lựa chọn không sử dụng chúng. Chắc chắn đừng mong đợi dây an toàn của một người sẽ ngăn họ ra khỏi xe của họ và tấn công bạn (hoặc truy cập dịch vụ Web của bạn).

Giả sử tôi viết một chương trình truy cập dịch vụ Web của bạn. Đây chỉ là một chương trình gửi tin nhắn TCP bao gồm các yêu cầu HTTP. Bạn đang yêu cầu cơ chế phía máy chủ để phân biệt giữa các yêu cầu được tạo bởi chương trình của tôi (có thể gửi bất cứ thứ gì) và các yêu cầu được tạo bởi trình duyệt có trang được tải từ nguồn gốc được phép. Nó chỉ đơn giản là không thể được thực hiện; chương trình của tôi luôn có thể gửi yêu cầu giống hệt với yêu cầu được hình thành bởi một trang Web.

Chính sách cùng nguồn gốc đã được phát minh vì nó ngăn mã từ một trang web truy cập nội dung bị giới hạn thông tin xác thực trên một trang web khác. Các yêu cầu Ajax theo mặc định được gửi với bất kỳ cookie xác thực nào được cấp bởi trang đích. Ví dụ: giả sử tôi vô tình tải http://evil.com/, sẽ gửi yêu cầu http://mail.google.com/. Nếu không có sẵn SOP và tôi đã đăng nhập vào Gmail, tập lệnh tại evil.comcó thể thấy hộp thư đến của tôi. Nếu trang web tại evil.commuốn tải mail.google.commà không có cookie của tôi, nó chỉ có thể sử dụng máy chủ proxy; nội dung công khai mail.google.comkhông phải là một bí mật (nhưng nội dung mail.google.comkhi được truy cập bằng cookie của tôi là một bí mật).

Chính sách cùng nguồn gốc được thi hành ở phía khách hàng. Nếu trình duyệt hỗ trợ CORS , máy chủ có thể gửi lại các tiêu đề cho trình duyệt biết ngoại lệ cho chính sách cùng nguồn gốc. Ví dụ: gửi tiêu đề

 Access-Control-Allow-Origin: www.example.com

sẽ yêu cầu trình duyệt cho phép các yêu cầu xuất xứ chéo từ www.example.com.

 Access-Control-Allow-Origin: *

báo cho trình duyệt cho phép tất cả các yêu cầu nguồn gốc chéo đến tài nguyên đó.

Các máy chủ web thường ngăn chặn các cuộc tấn công loại này bằng cách kiểm tra dòng (sai chính tả) Referertrong tiêu đề HTTP, để đảm bảo rằng yêu cầu đến từ một trang trên trang web của riêng họ. Không có cách nào tốt để bảo vệ chống lại một khách hàng độc hại, nhưng đó không phải là cách các cuộc tấn công XSRF hoạt động.

Máy khách không độc hại; nói chung, đó là một người dùng bình thường đã bị một bên thứ ba độc hại lừa mở một tài liệu mà âm thầm thực hiện một yêu cầu HTTP bằng cách sử dụng cookie được lưu trữ của khách hàng. Vì vậy, nếu máy chủ có thể xác minh thông qua Refereryêu cầu HTTP đến từ gmail.com chứ không phải MyAw đũaWebsite.com, nó có thể tắt cuộc tấn công.

Làm thế nào để các máy chủ web thực thi chính sách cùng nguồn gốc?

Nói tóm lại, họ không làm như apsillers và Dirk đã chỉ ra.
Một lý do quan trọng là tiêu đề ACAO bảo vệ chính các máy chủ khỏi các cuộc tấn công DDOS tràn lan, - Các cuộc tấn công từ chối dịch vụ phân tán .

Người nào:

ACAO dưới dạng tiêu đề phản hồi HTTP có nghĩa là để máy khách web được giải thích, hoạt động theo giả định rằng phần lớn người dùng internet của con người đang duyệt web thông qua các nhà cung cấp trình duyệt lớn tuân thủ và thực hiện dự thảo được đề xuất W3C . Cuối cùng, họ nên được hưởng lợi từ một mạng internet nhanh, dễ truy cập.

Làm sao:

Nếu không, bất cứ ai cũng có thể sao chép và dán một vài dòng mã javascript vào một trang web độc hại chạy một vòng lặp đơn giản, điều này khiến cho yêu cầu của Ajax GET hoặc POST trở thành một tên miền nước ngoài. Không có sự tương tác của người dùng và khả năng đa luồng.

Đó là lý do tại sao bạn phải chọn tham gia để truy cập một trang web có nguồn gốc chéo, thông qua tiêu đề HTTP ACAO . Bạn, người dùng, có thể truy cập trang web nói bất cứ lúc nào thông qua tương tác nhận biết người dùng, tức là liên kết internet. Giống như bạn có thể nhận biết người dùng sao chép hoặc dán nội dung từ hoặc vào bảng tạm của mình, nhưng không phải cách nào khác - bổ sung sang một bên.

Tương lai:

Tại thời điểm đó, hãy chú ý đến hướng của nhà sản xuất trình duyệt web:

• loại bỏ plugin mặc định , như một bước tiến tới một môi trường đầy đủ hộp cát và
• xóa tùy chọn người dùng để tắt javascript

Hạn chế bảo mật có thể được thiết lập bằng cách sử dụng kết hợp TSL 2/3, ID phiên mạnh, TAN, xác thực hai yếu tố, v.v.

'Google' có điều này để hiển thị và nói về DDOS

Cuối cùng, bất kỳ ai cũng có thể ủy quyền bất kỳ nội dung web nào và thêm tiêu đề ACAO mong muốn để truy cập nội dung trang web được ủy quyền. Tương tự, proxy này sau đó được mở cho một cuộc tấn công DDOS, vì cài đặt ACAO cho phép nó được thực hiện. Tôi thực sự không biết về một dịch vụ công cộng miễn phí duy nhất. Xin hãy sửa tôi nếu tôi sai.

Như những người khác nói, nó phụ thuộc vào khách hàng. Nhưng máy chủ có thể cần phải xử lý XSS, mà bỏ qua SOP.

Supopse máy chủ của bạn cho phép người dùng tải lên nội dung, được hiển thị khi người dùng khác duyệt trang web của bạn. Trang này là một ví dụ hay - tôi vừa tải lên nội dung và nó được hiển thị cho bạn.
Nếu nội dung của tôi chứa <script>thẻ và máy chủ chỉ sao chép nó vào HTML mà nó tạo ra, thì tập lệnh tôi đã tải lên sẽ chạy.
Vì tập lệnh được tìm thấy trong HTML từ tệp của bạn, nên nó có tất cả các quyền của tập lệnh của trang web của bạn. Nó có thể, ví dụ, upvote câu trả lời này. Và đây là lý do tại sao câu trả lời này có rất nhiều upvote.

Một máy chủ web tốt (như, than ôi, một StackExchange sử dụng), sẽ không để điều này xảy ra. Nó có thể xóa <script>thẻ hoặc thoát nó, vì vậy nó sẽ được nhìn thấy nhưng không được thực thi (cảnh báo - câu trả lời này nằm xa một công thức đáng tin cậy để ngăn XSS).

Vì vậy, phía khách hàng thực thi SOP, nhưng trong một số trường hợp, máy chủ nên hoạt động để tránh bỏ qua nó.