問題描述

我試圖理解為什么不允許沒有憑據的跨域請求(默認情況下，沒有設置服務器來返回 Access-Control-Allow-Origin 標頭).當請求具有憑據時，一切都非常簡單 - 如果您已登錄，則可以代表您在其他網站上執行一些惡意操作，例如在 Facebook 上.

I'm trying to understand why cross-domain requests without credentials are not allowed (by default, without setting up a server to return the Access-Control-Allow-Origin header). When a request has credentials all is pretty straightforward - one can fulfill some malicious actions on your behalf on other sites, for example on Facebook, if you have logged in on it.

例如請求

xhr = new XMLHttpRequest();
xhr.open('GET', 'http://www.google.com');
xhr.send();

產生錯誤(我從這個站點在 Chrome 的控制臺中執行它):

produces the error (I executed it in Chrome's console from this site):

XMLHttpRequest 無法加載 http://www.google.com/.不請求中存在Access-Control-Allow-Origin"標頭資源.因此，來源 'http://stackoverflow.com' 是不允許的訪問.

XMLHttpRequest cannot load http://www.google.com/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://stackoverflow.com' is therefore not allowed access.

因此，服務器必須發送適當的標頭(例如 Access-Control-Allow-Origin: * )才能使該請求起作用.

So, the server must send an appropriate header (e.g Access-Control-Allow-Origin: * ) to this request can work.

這只是一個簡單的請求，不會發送任何 cookie.這種限制的原因是什么?如果允許此類 CORS，可能會出現哪些安全問題?

This is just a simple request and no cookies are sent. What's the reason for such a restriction? What security issues might take place if such CORS will be allowed?

沒有憑據 - 沒有 cookie:XMLHTTPRequest 的默認設置是 withCredentials = false，因此請求中不會發送任何 cookie - 鏈接.

without credentials - without cookies: default settings for XMLHTTPRequest is withCredentials = false, so no cookies are sent in the request - link.

推薦答案

我會繼續從 Security.SE 的 為什么需要 Access-Control-Allow-Origin 標頭?

I'll go ahead and liberally steal from Security.SE's Why is the Access-Control-Allow-Origin header necessary?

這里主要關注的是基于網絡拓撲的訪問控制.假設您在家庭網絡上運行 HTTP 服務(事實上，如果您的路由器本身具有 Web 界面，您幾乎肯定會這樣做).我們將此服務稱為 R，只有連接到家庭路由器的機器才能訪問該服務.

The main concern here is access control based on network topology. Suppose you run a HTTP service on your home network (in fact, you almost certainly do, if your router itself has a Web interface). We'll call this service R, and the only machines connected to your home router can get to the service.

當您的瀏覽器訪問 evil.example.com 時，該站點會為您的瀏覽器提供一個腳本，告訴它獲取 R 的內容并將其發送回 evil.example.com.即使沒有憑據，這也可能很糟糕，因為它違反了本地網絡之外的任何人都無法查看本地網絡內運行的服務的假設.同源策略阻止了這種情況的發生.如果同源策略僅在涉及憑據時發揮作用，則可能會繞過基于拓撲的保護.

When your browser visits evil.example.com, that site serves your browser a script, telling it to fetch the contents of R and send it back to evil.example.com. This is potentially bad, even without credentials, because it's a violation of the assumption that no one outside your local network can view the services running inside your local network. The same-origin policy stops this from happening. If the same-origin policy only came into play when credentials were involved, it would opens up the possibility of bypassing topology-based protections.

還要考慮一些公共服務允許基于 IP 地址的訪問:

Consider also that some public services allow access based on IP address:

• 牛津英語詞典將其在線條目的訪問權限限制為來自訂閱大學的 IP 地址
• 英國將 BBC 內容的訪問權限限制在國內的 IP 地址內

在此處列出的所有情況下，瀏覽器都可能被用作任何為其提供腳本的網站的不知情代理.

In all of the cases listed here, a browser could be used as an unwitting proxy for any site that serves it a script.

這篇關于為什么禁止沒有憑據的 CORS?的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！