跨域資源共享(CORS)安全性

背景

提起瀏覽器的同源策略，大家都很熟悉。不同域的客戶端腳本不能讀寫對(duì)方的資源。但是實(shí)踐中有一些場景需要跨域的讀寫，所以出現(xiàn)了一些hack的方式來跨域。比如在同域內(nèi)做一個(gè)代理，JSON-P等。但這些方式都存在缺陷，無法完美的實(shí)現(xiàn)跨域讀寫。所以在XMLHttpRequest v2標(biāo)準(zhǔn)下，提出了CORS(Cross Origin Resourse-Sharing)的模型，試圖提供安全方便的跨域讀寫資源。目前主流瀏覽器均支持CORS。

技術(shù)原理

CORS定義了兩種跨域請(qǐng)求，簡單跨域請(qǐng)求和非簡單跨域請(qǐng)求。當(dāng)一個(gè)跨域請(qǐng)求發(fā)送簡單跨域請(qǐng)求包括：請(qǐng)求方法為HEAD，GET，POST;請(qǐng)求頭只有4個(gè)字段，Accept，Accept-Language，Content-Language，Last-Event-ID;如果設(shè)置了Content-Type，則其值只能是application/x-www-form-urlencoded,multipart/form-data,text/plain。說起來比較別扭，簡單的意思就是設(shè)置了一個(gè)白名單，符合這個(gè)條件的才是簡單請(qǐng)求。其他不符合的都是非簡單請(qǐng)求。

之所以有這個(gè)分類是因?yàn)闉g覽器對(duì)簡單請(qǐng)求和非簡單請(qǐng)求的處理機(jī)制是不一樣的。當(dāng)我們需要發(fā)送一個(gè)跨域請(qǐng)求的時(shí)候，瀏覽器會(huì)首先檢查這個(gè)請(qǐng)求，如果它符合上面所述的簡單跨域請(qǐng)求，瀏覽器就會(huì)立刻發(fā)送這個(gè)請(qǐng)求。如果瀏覽器檢查之后發(fā)現(xiàn)這是一個(gè)非簡單請(qǐng)求，比如請(qǐng)求頭含有X-Forwarded-For字段。這時(shí)候?yàn)g覽器不會(huì)馬上發(fā)送這個(gè)請(qǐng)求，而是有一個(gè)preflight，跟服務(wù)器驗(yàn)證的過程。瀏覽器先發(fā)送一個(gè)options方法的預(yù)檢請(qǐng)求。如果預(yù)檢通過，則發(fā)送這個(gè)請(qǐng)求，否則就不拒絕發(fā)送這個(gè)跨域請(qǐng)求。

下面詳細(xì)分析一下實(shí)現(xiàn)安全跨域請(qǐng)求的控制方式。先看一下非簡單請(qǐng)求的預(yù)檢過程。

非簡單請(qǐng)求

瀏覽器先發(fā)送一個(gè)options方法的請(qǐng)求。帶有如下字段：

- Origin:?普通的HTTP請(qǐng)求也會(huì)帶有，在CORS中專門作為Origin信息供后端比對(duì),表明來源域。
-?Access-Control-Request-Method:?接下來請(qǐng)求的方法，例如PUT,?DELETE等等
-?Access-Control-Request-Headers:?自定義的頭部，所有用setRequestHeader方法設(shè)置的頭部都將會(huì)以逗號(hào)隔開的形式包含在這個(gè)頭中

服務(wù)器收到"預(yù)檢"請(qǐng)求以后，檢查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后，確認(rèn)允許跨源請(qǐng)求，就可以做出回應(yīng)。

會(huì)返回對(duì)應(yīng)對(duì)的字段

• Access-Control-Allow-Origin:
• Access-Control-Allow-Methods:該字段必需，它的值是逗號(hào)分隔的一個(gè)字符串，表明服務(wù)器支持的所有跨域請(qǐng)求的方法。注意，返回的是所有支持的方法，而不單是瀏覽器請(qǐng)求的那個(gè)方法。這是為了避免多次“預(yù)檢”請(qǐng)求。
• Access-Control-Allow-Headers:

如果服務(wù)器否定了"預(yù)檢"請(qǐng)求，會(huì)返回一個(gè)正常的HTTP回應(yīng)，但是沒有任何CORS相關(guān)的頭信息字段。這時(shí)，瀏覽器就會(huì)認(rèn)定，服務(wù)器不同意預(yù)檢請(qǐng)求，因此觸發(fā)一個(gè)錯(cuò)誤，被XMLHttpRequest對(duì)象的onerror回調(diào)函數(shù)捕獲

一旦服務(wù)器通過了"預(yù)檢"請(qǐng)求，以后每次瀏覽器正常的CORS請(qǐng)求，就都跟簡單請(qǐng)求一樣，會(huì)有一個(gè)Origin頭信息字段。服務(wù)器的回應(yīng)，也都會(huì)有一個(gè)Access-Control-Allow-Origin頭信息字段。

為什么要預(yù)檢？

這是為了防止這些新增的請(qǐng)求，對(duì)傳統(tǒng)的沒有 CORS 支持的服務(wù)器形成壓力，給服務(wù)器一個(gè)提前拒絕的機(jī)會(huì)，這樣可以防止服務(wù)器大量收到DELETE和PUT請(qǐng)求，這些傳統(tǒng)的表單不可能跨域發(fā)出的請(qǐng)求。

簡單請(qǐng)求

簡單請(qǐng)求前面講過是直接發(fā)送，只是多加一個(gè)origin字段表明跨域請(qǐng)求的來源。

如果Origin指定的源，不在許可范圍內(nèi)，服務(wù)器會(huì)返回一個(gè)正常的HTTP回應(yīng)。瀏覽器發(fā)現(xiàn)，這個(gè)回應(yīng)的頭信息沒有包含Access-Control-Allow-Origin字段(詳見下文)，就知道出錯(cuò)了，從而拋出一個(gè)錯(cuò)誤，被XMLHttpRequest的onerror回調(diào)函數(shù)捕獲。注意，這種錯(cuò)誤無法通過狀態(tài)碼識(shí)別，因?yàn)镠TTP回應(yīng)的狀態(tài)碼有可能是200。

如果Origin指定的域名在許可范圍內(nèi)，服務(wù)器返回的響應(yīng)，會(huì)多出幾個(gè)頭信息字段。

• Access-Control-Allow-Origin: 允許跨域訪問的域，可以是一個(gè)域的列表，也可以是通配符"*"。這里要注意Origin規(guī)則只對(duì)域名有效，并不會(huì)對(duì)子目錄有效。即http://foo.example/subdir/ 是無效的。但是不同子域名需要分開設(shè)置，這里的規(guī)則可以參照同源策略
• Access-Control-Allow-Credentials: 是否允許請(qǐng)求帶有驗(yàn)證信息，這部分將會(huì)在下面詳細(xì)解釋
• Access-Control-Expose-Headers: 允許腳本訪問的返回頭，請(qǐng)求成功后，腳本可以在XMLHttpRequest中訪問這些頭的信息(貌似webkit沒有實(shí)現(xiàn)這個(gè))
• Access-Control-Max-Age: 緩存此次請(qǐng)求的秒數(shù)。在這個(gè)時(shí)間范圍內(nèi)，所有同類型的請(qǐng)求都將不再發(fā)送預(yù)檢請(qǐng)求而是直接使用此次返回的頭作為判斷依據(jù)，非常有用，大幅優(yōu)化請(qǐng)求次數(shù)
• Access-Control-Allow-Methods: 允許使用的請(qǐng)求方法，以逗號(hào)隔開
• Access-Control-Allow-Headers: 允許自定義的頭部，以逗號(hào)隔開，大小寫不敏感

然后瀏覽器通過返回結(jié)果的這些控制字段來決定是將結(jié)果開放給客戶端腳本讀取還是屏蔽掉。如果服務(wù)器沒有配置cors，返回結(jié)果沒有控制字段，瀏覽器會(huì)屏蔽腳本對(duì)返回信息的讀取。

withCredentials

withCredentials是什么？

withCredentials是XMLHttpRequest的一個(gè)屬性，表示跨域請(qǐng)求是否提供憑據(jù)信息(cookie、HTTP認(rèn)證及客戶端SSL證明等)

實(shí)際中用途就是跨域請(qǐng)求是要不要攜帶cookie

在需要跨域攜帶cookie時(shí)，要把withCredentials設(shè)置為true，比如

var?xhr?=?new?XMLHttpRequest()
xhr.withCredentials?=?true
xhr.open('GET',?'http://localhost:8888/',?true)
xhr.send(null)

服務(wù)端的設(shè)置

只有客戶端設(shè)置當(dāng)然不夠了，服務(wù)端還需要設(shè)置兩點(diǎn)

比如你頁面所在的域名為http://www.abc.com，服務(wù)端的Access-Control-Allow-Origin，必須是http://www.abc.com

Access-Control-Allow-Credentials

在響應(yīng)頭中，Access-Control-Allow-Credentials這個(gè)值也要設(shè)置為true，根據(jù)mdn上的說法，只有設(shè)置為true的時(shí)候，瀏覽器才會(huì)把響應(yīng)結(jié)果暴露給你的js代碼

Access-Control-Allow-Origin

既然是跨域請(qǐng)求，服務(wù)端要設(shè)置Access-Control-Allow-Origin，告訴瀏覽器允許跨域，而且這個(gè)值必須指定域名，不能設(shè)置為*

盡管瀏覽器可以支持通配符，但是不能同時(shí)將憑證標(biāo)志設(shè)置成true。

就像下面這種頭部配置：

Access-Control-Allow-Origin:?*
Access-Control-Allow-Credentials:?true

這樣配置瀏覽器將會(huì)報(bào)錯(cuò)，因?yàn)樵陧憫?yīng)具有憑據(jù)的請(qǐng)求時(shí)，服務(wù)器必須指定單個(gè)域，所不能使用通配符。簡單的使用通配符將有效的禁用“Access-Control-Allow-Credentials”這個(gè)字段。這些限制和行為的結(jié)果就是許多CORS的實(shí)現(xiàn)方式是根據(jù)“Origin”這個(gè)頭部字段的值來生成“AccessControl-Allow-Origin”的值

為什么不能兩者共存?

默認(rèn)情況下，如果沒有設(shè)置“Access-Control-Allow-Credentials”這個(gè)頭的話，瀏覽器發(fā)送的請(qǐng)求就不會(huì)帶有用戶的身份數(shù)據(jù)(cookie或者HTTP身份數(shù)據(jù))，所以就不會(huì)泄露用戶隱私信息。下面這個(gè)圖展示一個(gè)簡單的CORS請(qǐng)求流：

其實(shí)圖片所展示的就是經(jīng)典的CSRF攻擊。而Origin的限制，是為了明確是哪個(gè)站點(diǎn)發(fā)送的請(qǐng)求，根據(jù)Origin就可以發(fā)現(xiàn)是釣魚網(wǎng)站發(fā)起的請(qǐng)求。從而避免cookie的泄露。

參考文獻(xiàn)：

CORS通信

跨域資源共享(CORS)安全性淺析

【web前端】withCredentials有什么作用

cors安全完全指南

總結(jié)

以上是生活随笔為你收集整理的xmlhttprequest 跨域_跨域资源共享(CORS)安全性的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。