概述

本文主要涉及三個關鍵詞：

同源策略（Same-origin policy，簡稱 SOP） 跨站請求偽造（Cross-site request forgery，簡稱 CSRF） 跨域資源共享（Cross-Origin Resource Sharing，簡稱 CORS）同源策略 SOP同源

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

url 同源 https://niconico.com 基準 https://niconico.com/spirit o https://sub.niconico.com/spirit x http://niconico.com/spirit x https://niconico.com:8080/spirit x 限制

你之所以會遇到跨域問題，正是因為 SOP 的各種限制。但是具體來說限制了什么呢？

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

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

其實SOP 不是單一的定義，而是在不同情況下有不同的解釋：

限制 cookies、DOM 和JavaScript的命名區(qū)域 限制 iframe、圖片等各種資源的內(nèi)容操作 限制 ajax 請求，準確來說是限制操作 ajax 響應結(jié)果，本質(zhì)上跟上一條是一樣的

下面是 3 個在實際應用中會遇到的例子：

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

如果沒有了 SOP：

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

SOP 帶來安全，同時也會帶來一定程度的麻煩，因為有時候就是有跨域的需求。繞過跨域的方案由于篇幅所限，并且網(wǎng)上也很多相關文章，所以不在這里展開解決跨域的方案，只給出幾個關鍵詞：

對于 ajax

使用jsONP 后端進行 CORS 配置 后端反向代理

對于 iframe

使用 location.hash 或 window.name 進行信息交流 使用 postMessage跨站請求偽造 CSRF簡述

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

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

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

對于 GET 請求，直接放到<img>就能神不知鬼不覺地請求跨域接口。

對于 POST 請求，很多例子都使用 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>

歸根到底，這兩個方法不報跨域是因為請求由html控制，你無法用 js 直接操作獲得的結(jié)果。

SOP 與 ajax

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

所以再強調(diào)一次，同源策略不能作為防范 CSRF 的方法。

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

CSRF 對策

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

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

所以應對 CSRF 有這樣的思路：同時把一個 token 寫到 cookie 里，在發(fā)起請求時再通過 query、body 或者 header 帶上這個 token。請求到達服務器，核對這個 token，如果正確，那一定是能看到 cookie 的本域發(fā)送的請求，CSRF 則做不到這一點。（這個方法用于前后端分離，后端渲染則可以直接寫入到 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

跨域是瀏覽器限制，但是如果服務器設置了 CORS 相關配置，在返回服務器的信息頭部會加上Access-Control-Allow-Origin，瀏覽器看到這個字段的值與當前的源匹配，就會解鎖跨域限制。

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

對于 CORS，請求分兩種。

簡單請求 請求方法使用 GET、POST 或 HEAD Content-Type 設為 application/x-www-form-urlencoded、multipart/form-data 或 text/plain

符合上面兩個條件的都為 CORS 簡單請求。簡單請求都會直接發(fā)到服務器，會造成 CSRF。

預檢請求

不符合簡單請求要求的請求都需要先發(fā)送預檢請求（Preflight Request）。瀏覽器會在真正請求前發(fā)送 OPTION 方法的請求向服務器詢問當前源是否符合 CORS 目標，驗證通過后才會發(fā)送正式請求。

例如使用 application/json 傳參的 POST 請求就是非簡單請求，會在預檢中被攔截。

再例如使用 PUT 方法請求，也會發(fā)送預檢請求。

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

CORS 與 cookie

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

這就是為什么在進行 CORS 請求時 axios 需要設置withCredentials: true。

下面是 node.js 的后臺 koa框架的 CORS 設置：

/** * 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的詳細內(nèi)容，更多關于JS同源策略和CSRF的資料請關注好吧啦網(wǎng)其它相關文章！