CORS - Động lực đằng sau việc giới thiệu các yêu cầu preflight là gì?

Chia sẻ tài nguyên nguồn gốc chéo là một cơ chế cho phép một trang web tạo XMLHttpRequests sang một tên miền khác (từ wikipedia ).

Tôi đã đấu tranh với CORS trong vài ngày qua và tôi nghĩ rằng tôi hiểu khá rõ về cách mọi thứ hoạt động.

Vì vậy, câu hỏi của tôi không phải là về cách CORS / preflight hoạt động, mà là về lý do đằng sau việc đưa ra các preflights như một loại yêu cầu mới . Tôi không thấy lý do nào khiến máy chủ A cần gửi preflight (PR) đến máy chủ B chỉ để tìm hiểu xem yêu cầu thực sự (RR) có được chấp nhận hay không - chắc chắn B có thể chấp nhận / từ chối RR mà không cần bất kỳ PR trước.

Sau khi tìm kiếm khá nhiều, tôi tìm thấy mẩu thông tin này tại www.w3.org (7.1.5):

Để bảo vệ tài nguyên khỏi các yêu cầu có nguồn gốc chéo không thể bắt nguồn từ các tác nhân người dùng nhất định trước khi thông số kỹ thuật này tồn tại, yêu cầu preflight được thực hiện để đảm bảo rằng tài nguyên nhận thức được thông số kỹ thuật này.

Tôi thấy đây là câu khó hiểu nhất từ ​​trước đến nay. Giải thích của tôi (tốt hơn nên gọi là 'dự đoán tốt nhất') là về việc bảo vệ máy chủ B chống lại các yêu cầu từ máy chủ C không biết về thông số kỹ thuật.

Ai đó có thể vui lòng giải thích một kịch bản / hiển thị một vấn đề mà PR + RR giải quyết tốt hơn RR không?

Tôi đã dành một chút thời gian để bối rối về mục đích của yêu cầu preflight nhưng tôi nghĩ rằng tôi đã nhận được nó ngay bây giờ.

Cái nhìn sâu sắc quan trọng là các yêu cầu preflight không phải là một điều bảo mật . Thay vào đó, chúng là một thứ không thay đổi theo quy tắc .

Các yêu cầu chiếu trước không liên quan gì đến bảo mật và chúng không có liên quan đến các ứng dụng đang được phát triển, với nhận thức về CORS. Thay vào đó, cơ chế preflight có lợi cho các máy chủ được phát triển mà không có có nhận thức về CORS và nó có chức năng kiểm tra sự tỉnh táo giữa máy khách và máy chủ mà cả hai đều biết về CORS. Các nhà phát triển của CORS cảm thấy rằng có đủ máy chủ ngoài đó dựa vào giả định rằng họ sẽ không bao giờ nhận được, ví dụ như yêu cầu XÓA tên miền chéo mà họ đã phát minh ra cơ chế preflight để cho phép cả hai bên chọn tham gia. Họ cảm thấy rằng giải pháp thay thế, vốn chỉ đơn giản là kích hoạt các cuộc gọi tên miền chéo, sẽ phá vỡ quá nhiều ứng dụng hiện có.

Có ba kịch bản ở đây:

1. Các máy chủ cũ, không còn được phát triển và được phát triển trước CORS. Các máy chủ này có thể đưa ra các giả định rằng họ sẽ không bao giờ nhận được, ví dụ như yêu cầu XÓA tên miền chéo. Kịch bản này là người thụ hưởng chính của cơ chế preflight. Có, các dịch vụ này có thể đã bị lạm dụng bởi một tác nhân người dùng độc hại hoặc không tuân thủ (và CORS không có gì thay đổi điều này), nhưng trong một thế giới với CORS, cơ chế preflight cung cấp thêm 'kiểm tra độ tỉnh táo' để khách hàng và máy chủ không phá vỡ vì các quy tắc cơ bản của web đã thay đổi.

2. Các máy chủ vẫn đang được phát triển, nhưng chứa rất nhiều mã cũ và không khả thi / mong muốn kiểm toán tất cả các mã cũ để đảm bảo rằng nó hoạt động chính xác trong một thế giới tên miền chéo. Kịch bản này cho phép các máy chủ chọn liên tục vào CORS, ví dụ: bằng cách nói "Bây giờ tôi sẽ cho phép tiêu đề cụ thể này", "Bây giờ tôi sẽ cho phép động từ HTTP cụ thể này", "Bây giờ tôi sẽ cho phép thông tin cookie / auth được đã gửi ", vv Kịch bản này được hưởng lợi từ cơ chế preflight.

3. Các máy chủ mới được viết với nhận thức về CORS. Theo thông lệ bảo mật tiêu chuẩn, máy chủ phải bảo vệ tài nguyên của mình trước mọi yêu cầu đến - máy chủ không thể tin tưởng khách hàng không làm những việc độc hại. Kịch bản này không được hưởng lợi từ cơ chế preflight : cơ chế preflight không mang lại bảo mật bổ sung cho máy chủ đã bảo vệ đúng tài nguyên của nó.

Động lực đằng sau việc giới thiệu các yêu cầu preflight là gì?

Các yêu cầu chiếu trước được giới thiệu để trình duyệt có thể chắc chắn rằng nó đang xử lý một máy chủ nhận biết CORS trước khi gửi một số yêu cầu nhất định. Những yêu cầu đó được xác định là những yêu cầu có khả năng gây nguy hiểm (thay đổi trạng thái) và mới (không thể thực hiện trước CORS do Chính sách xuất xứ tương tự ). Sử dụng các yêu cầu preflight có nghĩa là các máy chủ phải chọn tham gia (bằng cách phản hồi đúng với đèn chiếu trước) với các loại yêu cầu mới, có khả năng nguy hiểm mà CORS đưa ra.

Đó là ý nghĩa của phần này của đặc tả : "Để bảo vệ tài nguyên khỏi các yêu cầu nguồn gốc chéo không thể bắt nguồn từ các tác nhân người dùng nhất định trước khi thông số kỹ thuật này tồn tại một yêu cầu preflight được thực hiện để đảm bảo rằng tài nguyên nhận thức được thông số kỹ thuật này."

Bạn có thể cho tôi một ví dụ?

Hãy tưởng tượng rằng một người dùng trình duyệt đã đăng nhập vào trang web ngân hàng của họ tại A.com. Khi họ điều hướng đến phần độc hại B.com, trang đó bao gồm một số Javascript cố gửi DELETEyêu cầu A.com/account. Vì người dùng đã đăng nhập A.com, yêu cầu đó, nếu được gửi, sẽ bao gồm các cookie xác định người dùng.

Trước CORS, Chính sách nguồn gốc tương tự của trình duyệt sẽ chặn nó gửi yêu cầu này. Nhưng vì mục đích của CORS là làm cho loại giao tiếp có nguồn gốc này trở nên khả thi, điều đó không còn phù hợp nữa.

Trình duyệt có thể chỉ cần gửi DELETEvà để máy chủ quyết định cách xử lý. Nhưng nếu A.comkhông biết về giao thức CORS thì sao? Nó có thể đi trước và thực hiện nguy hiểm DELETE. Có thể giả định rằng, do Chính sách nguồn gốc tương tự của trình duyệt, nó không bao giờ có thể nhận được yêu cầu như vậy, và do đó, nó có thể chưa bao giờ được củng cố trước một cuộc tấn công như vậy.

Sau đó, để bảo vệ các máy chủ không nhận biết CORS như vậy, giao thức yêu cầu trình duyệt trước tiên phải gửi yêu cầu preflight . Loại yêu cầu mới này là thứ mà chỉ các máy chủ nhận biết CORS mới có thể đáp ứng đúng, cho phép trình duyệt biết liệu có an toàn để gửi thực tế hay không DELETE.

Tại sao tất cả những điều ồn ào về trình duyệt này, kẻ tấn công không thể gửi DELETEyêu cầu từ máy tính của họ?

Chắc chắn, nhưng một yêu cầu như vậy sẽ không bao gồm cookie của người dùng. Cuộc tấn công mà điều này được thiết kế để ngăn chặn sự thật là trình duyệt sẽ gửi cookie (đặc biệt là thông tin xác thực cho người dùng) cho tên miền khác cùng với yêu cầu.

Nghe có vẻ như Cross-Site Request Giả mạo , nơi một mẫu trên trang web B.comlon POSTđể A.comvới cookie của người dùng và làm thiệt hại.

Đúng rồi. Một cách khác để đặt điều này là các yêu cầu preflight đã được tạo để không làm tăng bề mặt tấn công CSRF cho các máy chủ không nhận biết CORS.

Nhưng nhìn vào các yêu cầu cho "đơn giản" không yêu cầu tiền, tôi thấy điều đó POSTvẫn được cho phép. Điều đó có thể thay đổi trạng thái và xóa dữ liệu giống như a DELETE!

Đúng! CORS không bảo vệ trang web của bạn khỏi các cuộc tấn công CSRF. Sau đó, một lần nữa, không có CORS, bạn cũng không được bảo vệ khỏi các cuộc tấn công CSRF. Mục đích của các yêu cầu preflight chỉ là để hạn chế tiếp xúc CSRF của bạn với những gì đã tồn tại trong thế giới tiền CORS.

Thở dài. OK, tôi miễn cưỡng chấp nhận sự cần thiết của các yêu cầu preflight. Nhưng tại sao chúng ta phải làm điều đó cho mọi tài nguyên (URL) trên máy chủ? Máy chủ xử lý CORS hoặc không.

Bạn có chắc chắn về điều đó không? Không có gì lạ khi nhiều máy chủ xử lý các yêu cầu cho một tên miền. Ví dụ, đó có thể là trường hợp các yêu cầu A.com/url1được xử lý bởi một loại máy chủ và các yêu cầu A.com/url2được xử lý bởi một loại máy chủ khác. Nói chung, không phải trường hợp máy chủ xử lý một tài nguyên có thể đảm bảo an ninh cho tất cả các tài nguyên trên miền đó.

Khỏe. Hãy thỏa hiệp. Hãy tạo một tiêu đề CORS mới cho phép máy chủ nêu chính xác tài nguyên mà nó có thể sử dụng để có thể tránh được các yêu cầu preflight bổ sung cho các URL đó.

Ý tưởng tốt! Trong thực tế, tiêu đề Access-Control-Policy-Pathđã được đề xuất cho mục đích này. Cuối cùng, mặc dù, nó đã bị loại ra khỏi đặc điểm kỹ thuật, rõ ràng do một số máy chủ đã triển khai không chính xác đặc tả URI theo cách yêu cầu các đường dẫn có vẻ an toàn cho trình duyệt trên thực tế sẽ không an toàn trên các máy chủ bị hỏng.

Đây có phải là một quyết định thận trọng ưu tiên bảo mật hơn hiệu năng, cho phép các trình duyệt thực hiện ngay lập tức đặc tả CORS mà không khiến máy chủ hiện tại gặp rủi ro? Hoặc là nó đã thiển cận để làm hỏng internet để lãng phí băng thông và tăng gấp đôi độ trễ chỉ để chứa các lỗi trong một máy chủ cụ thể tại một thời điểm cụ thể?

Ý kiến ​​khác nhau.

Chà, ít nhất các trình duyệt sẽ lưu bộ đệm trước cho một URL?

Đúng. Mặc dù có lẽ không lâu lắm. Trong trình duyệt WebKit, thời gian bộ đệm trước tối đa hiện tại là 10 phút .

Thở dài. Chà, nếu tôi biết rằng các máy chủ của tôi nhận thức được CORS, và do đó không cần sự bảo vệ được cung cấp bởi các yêu cầu preflight, có cách nào để tôi tránh chúng không?

Tùy chọn thực sự duy nhất của bạn là đảm bảo rằng bạn đáp ứng các yêu cầu cho các yêu cầu "đơn giản". Điều đó có thể có nghĩa là loại bỏ các tiêu đề tùy chỉnh mà bạn sẽ bao gồm (như X-Requested-With), nói dối về Content-Type, hoặc hơn thế nữa.

Dù bạn làm gì, bạn phải đảm bảo rằng bạn có các biện pháp bảo vệ CSRF thích hợp vì đặc điểm kỹ thuật của CORS không giải quyết từ chối các yêu cầu "đơn giản", bao gồm cả không an toàn POST. Như đặc điểm kỹ thuật đặt ra : "tài nguyên mà các yêu cầu đơn giản có ý nghĩa khác với truy xuất phải tự bảo vệ khỏi Giả mạo yêu cầu chéo trang web".

Hãy xem xét thế giới của các yêu cầu tên miền chéo trước CORS. Bạn có thể thực hiện POST mẫu tiêu chuẩn hoặc sử dụng thẻ scripthoặc imagethẻ để đưa ra yêu cầu GET. Bạn không thể thực hiện bất kỳ loại yêu cầu nào khác ngoài GET / POST và bạn không thể đưa ra bất kỳ tiêu đề tùy chỉnh nào cho các yêu cầu này.

Với sự ra đời của CORS, các tác giả đặc tả đã phải đối mặt với thách thức giới thiệu một cơ chế tên miền chéo mới mà không phá vỡ ngữ nghĩa hiện có của web. Họ đã chọn làm điều này bằng cách cho các máy chủ một cách để chọn tham gia bất kỳ loại yêu cầu mới nào. Chọn tham gia này là yêu cầu preflight.

Vì vậy, các yêu cầu GET / POST mà không có bất kỳ tiêu đề tùy chỉnh nào không cần đèn chiếu trước, vì các yêu cầu này đã có thể thực hiện trước CORS. Nhưng bất kỳ yêu cầu nào với các tiêu đề tùy chỉnh hoặc các yêu cầu PUT / DELETE đều cần có đèn chiếu trước, vì đây là những yêu cầu mới đối với thông số CORS. Nếu máy chủ không biết gì về CORS, nó sẽ trả lời mà không có bất kỳ tiêu đề cụ thể nào của CORS và yêu cầu thực tế sẽ không được thực hiện.

Nếu không có yêu cầu preflight, các máy chủ có thể bắt đầu thấy các yêu cầu không mong muốn từ các trình duyệt. Điều này có thể dẫn đến một vấn đề bảo mật nếu các máy chủ không chuẩn bị cho các loại yêu cầu này. Prelight CORS cho phép các yêu cầu tên miền chéo được đưa vào web một cách an toàn.

CORS cho phép bạn chỉ định nhiều tiêu đề và loại phương thức hơn trước đây có thể có nguồn gốc chéo <img src>hoặc <form action>.

Một số máy chủ có thể được bảo vệ (kém) với giả định rằng trình duyệt không thể thực hiện, ví dụ: DELETEyêu cầu xuất xứ chéo hoặc yêu cầu xuất xứ chéo với X-Requested-Withtiêu đề, vì vậy các yêu cầu đó là "đáng tin cậy".

Để đảm bảo rằng máy chủ thực sự thực sự hỗ trợ CORS và không chỉ đáp ứng các yêu cầu ngẫu nhiên, preflight được thực thi.

Đây là một cách khác để xem xét nó, sử dụng mã:

<!-- hypothetical exploit on evil.com -->
<!-- Targeting banking-website.example.com, which authenticates with a cookie -->
<script>
jQuery.ajax({
  method: "POST",
  url: "https://banking-website.example.com",
  data: JSON.stringify({
    sendMoneyTo: "Dr Evil",
    amount: 1000000
  }),
  contentType: "application/json",
  dataType: "json"
});
</script>

Pre-CORS, nỗ lực khai thác ở trên sẽ thất bại vì nó vi phạm chính sách cùng nguồn gốc. Một API được thiết kế theo cách này không cần bảo vệ XSRF, vì nó được bảo vệ bởi mô hình bảo mật gốc của trình duyệt. Trình duyệt tiền CORS không thể tạo ra JSON POST có nguồn gốc chéo.

Bây giờ CORS xuất hiện - nếu không chọn tham gia CORS qua chuyến bay trước, đột nhiên trang web này sẽ có một lỗ hổng lớn, không có lỗi của riêng họ.

Để giải thích tại sao một số yêu cầu được phép bỏ qua chuyến bay trước, điều này được trả lời bởi thông số:

Một yêu cầu nguồn gốc chéo đơn giản đã được xác định là phù hợp với những yêu cầu có thể được tạo bởi các tác nhân người dùng hiện đang triển khai không phù hợp với đặc điểm kỹ thuật này.

Để gỡ rối điều đó, GET không được bay trước vì đây là "phương pháp đơn giản" như được định nghĩa trong 7.1.5. (Các tiêu đề cũng phải "đơn giản" để tránh chuyến bay trước). Lý do cho điều này là yêu cầu GET có nguồn gốc chéo "đơn giản" có thể đã được thực hiện bằng ví dụ <script src="">(đây là cách JSONP hoạt động). Vì bất kỳ yếu tố nào có srcthuộc tính đều có thể kích hoạt GET có nguồn gốc chéo, không có chuyến bay trước, nên sẽ không có lợi ích bảo mật nào khi yêu cầu chiến đấu trước trên các XHR "đơn giản".

Tôi cảm thấy rằng các câu trả lời khác không tập trung vào lý do trước khi chiến đấu tăng cường bảo mật.

Kịch bản:

1) Với chuyến bay trước . Kẻ tấn công giả mạo yêu cầu từ trang web dummy-forums.com trong khi người dùng được xác thực với safe-bank.com
Nếu Máy chủ không kiểm tra nguồn gốc và bằng cách nào đó có lỗi, trình duyệt sẽ đưa ra yêu cầu trước chuyến bay, TÙY CHỌN phương pháp. Máy chủ không biết CORS nào mà trình duyệt đang mong đợi như một phản hồi nên trình duyệt sẽ không tiếp tục (không gây hại gì)

2) Nếu không có chuyến bay trước . Kẻ tấn công giả mạo yêu cầu theo cùng một kịch bản như trên, trình duyệt sẽ đưa ra yêu cầu POST hoặc PUT ngay lập tức, máy chủ chấp nhận nó và có thể xử lý nó, điều này có khả năng gây ra một số tác hại.

Nếu kẻ tấn công gửi yêu cầu trực tiếp, nguồn gốc chéo, từ một số máy chủ ngẫu nhiên, rất có thể người ta đang nghĩ về một yêu cầu không có xác thực. Đó là một yêu cầu giả mạo, nhưng không phải là một yêu cầu xsrf. Vì vậy, máy chủ sẽ kiểm tra thông tin đăng nhập và thất bại. CORS không cố gắng ngăn chặn kẻ tấn công có thông tin xác thực để đưa ra yêu cầu, mặc dù danh sách trắng có thể giúp giảm vectơ tấn công này.

Cơ chế trước chuyến bay bổ sung sự an toàn và nhất quán giữa khách hàng và máy chủ. Tôi không biết điều này có đáng để bắt tay thêm cho mọi yêu cầu hay không vì bộ nhớ đệm khó sử dụng ở đó, nhưng đó là cách nó hoạt động.

Ngoài ra, đối với các phương thức yêu cầu HTTP có thể gây ra tác dụng phụ đối với dữ liệu người dùng (cụ thể là đối với các phương thức HTTP khác với GET hoặc đối với việc sử dụng POST với các loại MIME nhất định), đặc tả bắt buộc các trình duyệt "chiếu trước" yêu cầu

Nguồn

Yêu cầu trước chuyến bay là cần thiết cho các yêu cầu có thể thay đổi trạng thái trên máy chủ. Có 2 loại yêu cầu -

1) Các cuộc gọi không thể thay đổi trạng thái trên máy chủ (như GET) - Người dùng có thể nhận được phản hồi cho yêu cầu (nếu máy chủ không kiểm tra nguồn gốc) nhưng nếu miền yêu cầu không được thêm vào tiêu đề phản hồi Access-Control- Cho phép - Xuất xứ, trình duyệt không hiển thị dữ liệu cho người dùng, nghĩa là yêu cầu được gửi từ trình duyệt nhưng người dùng không thể xem / sử dụng phản hồi.

2) Các cuộc gọi có thể thay đổi trạng thái trên máy chủ (như POST, DELETE) - Kể từ trong 1), chúng tôi thấy rằng trình duyệt không chặn yêu cầu nhưng phản hồi, các cuộc gọi thay đổi trạng thái không được phép thực hiện mà không cần kiểm tra trước . Các cuộc gọi như vậy có thể thực hiện thay đổi đối với máy chủ tin cậy không kiểm tra nguồn gốc của các cuộc gọi (được gọi là Giả mạo yêu cầu trang web chéo), mặc dù phản hồi cho trình duyệt có thể là một thất bại. Vì lý do này, chúng tôi có khái niệm về các yêu cầu trước chuyến bay thực hiện cuộc gọi TÙY CHỌN trước khi bất kỳ cuộc gọi thay đổi trạng thái nào có thể được gửi đến máy chủ.

Không phải là các yêu cầu được đề cập trước về Hiệu suất ? Với các yêu cầu được chiếu trước, khách hàng có thể nhanh chóng biết liệu thao tác có được phép hay không trước khi gửi một lượng lớn dữ liệu, ví dụ: trong JSON với phương thức PUT. Hoặc trước khi di chuyển dữ liệu nhạy cảm trong các tiêu đề xác thực qua dây.

Thực tế của PUT, DELETE và các phương thức khác, ngoài các tiêu đề tùy chỉnh, không được phép theo mặc định (Chúng cần có sự cho phép rõ ràng với "Phương thức kiểm soát truy cập-yêu cầu-yêu cầu" và "Tiêu đề kiểm soát truy cập yêu cầu"), âm thanh đó giống như kiểm tra hai lần, bởi vì các thao tác này có thể có nhiều ý nghĩa hơn đối với dữ liệu người dùng, thay vào đó là các yêu cầu GET. Vì vậy, nó có vẻ như:

"Tôi thấy rằng bạn cho phép các yêu cầu trên nhiều trang web từ http: //foo.example , NHƯNG bạn có cho phép các yêu cầu XÓA không? Bạn có xem xét các tác động mà các yêu cầu này có thể gây ra trong dữ liệu người dùng không?"

Tôi không hiểu mối tương quan được trích dẫn giữa các yêu cầu được đề cập trước và các lợi ích của máy chủ cũ. Dịch vụ web được triển khai trước CORS hoặc không có nhận thức về CORS sẽ không bao giờ nhận được BẤT K request yêu cầu nào, bởi vì trước tiên, phản hồi của họ sẽ không có tiêu đề "Kiểm soát truy cập-cho phép xuất xứ".

Trong trình duyệt hỗ trợ CORS, các yêu cầu đọc (như GET) đã được bảo vệ bởi chính sách cùng nguồn gốc: Một trang web độc hại cố gắng thực hiện một yêu cầu tên miền chéo được xác thực (ví dụ: trang web ngân hàng của nạn nhân hoặc giao diện cấu hình của bộ định tuyến) sẽ không có thể đọc dữ liệu trả về vì ngân hàng hoặc bộ định tuyến không đặtAccess-Control-Allow-Origin tiêu đề.

Tuy nhiên, với các yêu cầu bằng văn bản (như POST), thiệt hại được thực hiện khi yêu cầu đến máy chủ web. * Một máy chủ web có thể kiểm tra Origintiêu đề để xác định xem yêu cầu có hợp pháp không, nhưng kiểm tra này thường không được thực hiện vì máy chủ web không có nhu cầu đối với CORS hoặc máy chủ web cũ hơn CORS và do đó, giả sử rằng các POST tên miền chéo bị cấm hoàn toàn bởi chính sách cùng nguồn gốc.

Đó là lý do tại sao các máy chủ web được trao cơ hội chọn tham gia nhận các yêu cầu ghi tên miền chéo .

_{* Về cơ bản là phiên bản AJAX của CSRF.}