概述

本文主要涉及三個(gè)關(guān)鍵詞：

同源策略（Same-origin policy，簡(jiǎn)稱(chēng) SOP） 跨站請(qǐng)求偽造（Cross-site request forgery，簡(jiǎn)稱(chēng) CSRF） 跨域資源共享（Cross-Origin Resource Sharing，簡(jiǎn)稱(chēng) CORS）同源策略 SOP同源

先解釋何為同源：協(xié)議、域名、端口都一樣，就是同源。

url 同源 https://niconico.com 基準(zhǔn) https://niconico.com/spirit o https://sub.niconico.com/spirit x http://niconico.com/spirit x https://niconico.com:8080/spirit x 限制

你之所以會(huì)遇到跨域問(wèn)題，正是因?yàn)?SOP 的各種限制。但是具體來(lái)說(shuō)限制了什么呢？

如果你說(shuō) SOP 就是“限制非同源資源的獲取”，這不對(duì)，最簡(jiǎn)單的例子是引用圖片、css、js文件等資源的時(shí)候就允許跨域。

如果你說(shuō) SOP 就是“禁止跨域請(qǐng)求”，這也不對(duì)，本質(zhì)上 SOP 并不是禁止跨域請(qǐng)求，而是在請(qǐng)求后攔截了請(qǐng)求的回應(yīng)。這就就會(huì)引起后面說(shuō)到的 CSRF

其實(shí)SOP 不是單一的定義，而是在不同情況下有不同的解釋?zhuān)?/p> 限制 cookies、DOM 和JavaScript的命名區(qū)域 限制 iframe、圖片等各種資源的內(nèi)容操作 限制 ajax 請(qǐng)求，準(zhǔn)確來(lái)說(shuō)是限制操作 ajax 響應(yīng)結(jié)果，本質(zhì)上跟上一條是一樣的

下面是 3 個(gè)在實(shí)際應(yīng)用中會(huì)遇到的例子：

使用 ajax 請(qǐng)求其他跨域 API，最常見(jiàn)的情況，前端新手噩夢(mèng) iframe 與父頁(yè)面交流，出現(xiàn)率比較低，而且解決方法也好懂 對(duì)跨域圖片（例如來(lái)源于<img>）進(jìn)行操作，在 canvas 操作圖片的時(shí)候會(huì)遇到這個(gè)問(wèn)題

如果沒(méi)有了 SOP：

一個(gè)瀏覽器打開(kāi)幾個(gè) tab，數(shù)據(jù)就泄露了 你用 iframe 打開(kāi)一個(gè)銀行網(wǎng)站，你可以肆意讀取網(wǎng)站的內(nèi)容，就能獲取用戶(hù)輸入的內(nèi)容 更加肆意地進(jìn)行 CSRF繞過(guò)跨域

SOP 帶來(lái)安全，同時(shí)也會(huì)帶來(lái)一定程度的麻煩，因?yàn)橛袝r(shí)候就是有跨域的需求。繞過(guò)跨域的方案由于篇幅所限，并且網(wǎng)上也很多相關(guān)文章，所以不在這里展開(kāi)解決跨域的方案，只給出幾個(gè)關(guān)鍵詞：

對(duì)于 ajax

使用jsONP 后端進(jìn)行 CORS 配置 后端反向代理

對(duì)于 iframe

使用 location.hash 或 window.name 進(jìn)行信息交流 使用 postMessage跨站請(qǐng)求偽造 CSRF簡(jiǎn)述

CSRF（Cross-site request forgery）跨站請(qǐng)求偽造，是一種常見(jiàn)的攻擊方式。是指 A 網(wǎng)站正常登陸后，cookie 正常保存，其他網(wǎng)站 B 通過(guò)某種方式調(diào)用 A 網(wǎng)站接口進(jìn)行操作，A 的接口在請(qǐng)求時(shí)會(huì)自動(dòng)帶上 cookie。

上面說(shuō)了，SOP 可以通過(guò)htmltag 加載資源，而且 SOP 不阻止接口請(qǐng)求而是攔截請(qǐng)求結(jié)果，CSRF 恰恰占了這兩個(gè)便宜。

所以 SOP 不能作為防范 CSRF 的方法。

對(duì)于 GET 請(qǐng)求，直接放到<img>就能神不知鬼不覺(jué)地請(qǐng)求跨域接口。

對(duì)于 POST 請(qǐng)求，很多例子都使用 form 提交：

<form action='<nowiki>http://bank.com/transfer.do</nowiki>' method='POST'> <input type='hidden' name='acct' value='MARIA' /> <input type='hidden' name='amount' value='100000' /> <input type='submit' value='View my pictures' /></form>

歸根到底，這兩個(gè)方法不報(bào)跨域是因?yàn)檎?qǐng)求由html控制，你無(wú)法用 js 直接操作獲得的結(jié)果。

SOP 與 ajax

對(duì)于 ajax 請(qǐng)求，在獲得數(shù)據(jù)之后你能肆意進(jìn)行 js 操作。這時(shí)候雖然同源策略會(huì)阻止響應(yīng)，但依然會(huì)發(fā)出請(qǐng)求。因?yàn)閳?zhí)行響應(yīng)攔截的是瀏覽器而不是后端程序。事實(shí)上你的請(qǐng)求已經(jīng)發(fā)到服務(wù)器并返回了結(jié)果，但是迫于安全策略，瀏覽器不允許你繼續(xù)進(jìn)行 js 操作，所以報(bào)出你熟悉的blocked by CORS policy: No ’Access-Control-Allow-Origin’ header is present on the requested resource.。

所以再?gòu)?qiáng)調(diào)一次，同源策略不能作為防范 CSRF 的方法。

不過(guò)可以防范 CSRF 的例外還是有的，瀏覽器并不是讓所有請(qǐng)求都發(fā)送成功，上述情況僅限于簡(jiǎn)單請(qǐng)求，相關(guān)知識(shí)會(huì)在下面 CORS 一節(jié)詳細(xì)解釋。

CSRF 對(duì)策

SOP 被 CSRF 占了便宜，那真的是一無(wú)是處嗎？

不是！是否記得 SOP 限制了 cookie 的命名區(qū)域，雖然請(qǐng)求會(huì)自動(dòng)帶上 cookies，但是攻擊者無(wú)論如何還是無(wú)法獲取 cookie 的內(nèi)容本身。

所以應(yīng)對(duì) CSRF 有這樣的思路：同時(shí)把一個(gè) token 寫(xiě)到 cookie 里，在發(fā)起請(qǐng)求時(shí)再通過(guò) query、body 或者 header 帶上這個(gè) token。請(qǐng)求到達(dá)服務(wù)器，核對(duì)這個(gè) token，如果正確，那一定是能看到 cookie 的本域發(fā)送的請(qǐng)求，CSRF 則做不到這一點(diǎn)。（這個(gè)方法用于前后端分離，后端渲染則可以直接寫(xiě)入到 dom 中）

示例代碼如下：

var csrftoken = Cookies.get(’csrfToken’)function csrfSafeMethod(method) { // these HTTP methods do not require CSRF protection return /^(GET|HEAD|OPTIONS|TRACE)$/.test(method)}$.ajaxSetup({ beforeSend: function(xhr, settings) { if (!csrfSafeMethod(settings.type) && !this.crossDomain) { xhr.setRequestHeader(’x-csrf-token’, csrftoken) } },})跨域資源共享 CORS

跨域是瀏覽器限制，但是如果服務(wù)器設(shè)置了 CORS 相關(guān)配置，在返回服務(wù)器的信息頭部會(huì)加上Access-Control-Allow-Origin，瀏覽器看到這個(gè)字段的值與當(dāng)前的源匹配，就會(huì)解鎖跨域限制。

HTTP/1.1 200 OK

Date: Sun, 24 Apr 2016 12:43:39 GMT

Server: Apache

Access-Control-Allow-Origin: http://www.acceptmeplease.com

Keep-Alive: timeout=2, max=100

Connection: Keep-Alive

Content-Type: application/xml

Content-Length: 423

對(duì)于 CORS，請(qǐng)求分兩種。

簡(jiǎn)單請(qǐng)求 請(qǐng)求方法使用 GET、POST 或 HEAD Content-Type 設(shè)為 application/x-www-form-urlencoded、multipart/form-data 或 text/plain

符合上面兩個(gè)條件的都為 CORS 簡(jiǎn)單請(qǐng)求。簡(jiǎn)單請(qǐng)求都會(huì)直接發(fā)到服務(wù)器，會(huì)造成 CSRF。

預(yù)檢請(qǐng)求

不符合簡(jiǎn)單請(qǐng)求要求的請(qǐng)求都需要先發(fā)送預(yù)檢請(qǐng)求（Preflight Request）。瀏覽器會(huì)在真正請(qǐng)求前發(fā)送 OPTION 方法的請(qǐng)求向服務(wù)器詢(xún)問(wèn)當(dāng)前源是否符合 CORS 目標(biāo)，驗(yàn)證通過(guò)后才會(huì)發(fā)送正式請(qǐng)求。

例如使用 application/json 傳參的 POST 請(qǐng)求就是非簡(jiǎn)單請(qǐng)求，會(huì)在預(yù)檢中被攔截。

再例如使用 PUT 方法請(qǐng)求，也會(huì)發(fā)送預(yù)檢請(qǐng)求。

上面提到的可以防范 CSRF 的例外，就是指預(yù)檢請(qǐng)求。即使跨域成功請(qǐng)求預(yù)檢，但真正請(qǐng)求并不能發(fā)出去，這就保證了 CSRF 無(wú)法成功。

CORS 與 cookie

與同域不同，用于跨域的 CORS 請(qǐng)求默認(rèn)不發(fā)送 Cookie 和 HTTP 認(rèn)證信息，前后端都要在配置中設(shè)定請(qǐng)求時(shí)帶上 cookie。

這就是為什么在進(jìn)行 CORS 請(qǐng)求時(shí) axios 需要設(shè)置withCredentials: true。

下面是 node.js 的后臺(tái) koa框架的 CORS 設(shè)置：

/** * CORS middleware * * @param {Object} [options] * - {String|Function(ctx)} origin `Access-Control-Allow-Origin`, default is request Origin header * - {String|Array} allowMethods `Access-Control-Allow-Methods`, default is ’GET,HEAD,PUT,POST,DELETE,PATCH’ * - {String|Array} exposeHeaders `Access-Control-Expose-Headers` * - {String|Array} allowHeaders `Access-Control-Allow-Headers` * - {String|Number} maxAge `Access-Control-Max-Age` in seconds * - {Boolean} credentials `Access-Control-Allow-Credentials` * - {Boolean} keepHeadersOnError Add set headers to `err.header` if an error is thrown * @return {Function} cors middleware * @api public */

以上就是詳解JS同源策略和CSRF的詳細(xì)內(nèi)容，更多關(guān)于JS同源策略和CSRF的資料請(qǐng)關(guān)注好吧啦網(wǎng)其它相關(guān)文章！