【安全】899- 前端安全之同源策略、CSRF 和 CORS

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

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

同源策略 SOP

同源

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

限制

你之所以會(huì)遇到 跨域問題，正是因?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)。

其實(shí)表面上 SOP 分兩種情況：

• 可以正常引用 iframe、圖片等各種資源，但是限制對(duì)其內(nèi)容進(jìn)行操作
• 直接限制 ajax 請(qǐng)求，準(zhǔn)確來(lái)說(shuō)是限制操作 ajax 響應(yīng)結(jié)果，這會(huì)引起后面說(shuō)到的 CSRF

但是，本質(zhì)上這兩條是一樣的：總之，對(duì)于非同源的資源，瀏覽器可以“直接使用”，但是程序員和用戶不可以對(duì)這些數(shù)據(jù)進(jìn)行操作，杜絕某些居心不良的行為。這就是現(xiàn)代安全瀏覽器對(duì)用戶的保護(hù)之一。

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

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

如果沒有了 SOP：

• iframe 里的機(jī)密信息被肆意讀取
• 更加肆意地進(jìn)行 CSRF
• 接口被第三方濫用

繞過跨域

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

對(duì)于 ajax

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

對(duì)于 iframe

• 使用 location.hash 或 window.name 進(jìn)行信息交流
• 使用 postMessage

跨站請(qǐng)求偽造 CSRF

簡(jiǎn)述

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

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

對(duì)于 GET 請(qǐng)求，直接放到 <img> 就能神不知鬼不覺地請(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>

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

回顧 SOP 的限制，這兩個(gè)例子都是直接用 html 標(biāo)簽發(fā)起請(qǐng)求，而瀏覽器允許這么做，歸根到底就是因?yàn)?strong>你無(wú)法用 js 直接操作獲得的結(jié)果。

SOP 與 ajax

對(duì)于 ajax 請(qǐng)求，在獲得數(shù)據(jù)之后你能肆意進(jìn)行 js 操作。這時(shí)候雖然同源策略會(huì)阻止響應(yīng)，但依然會(huì)發(fā)出請(qǐng)求。因?yàn)?strong>執(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 的方法。

不過可以防范 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 有這樣的思路：就是前后端分離常用的鑒權(quán)方法，使用 token 鑒權(quán)，并且不把 token 存放在 cookie，請(qǐng)求時(shí)在請(qǐng)求頭上手動(dòng)加上。

另一個(gè)方法是：cookie 里的東西，在發(fā)起請(qǐng)求時(shí)通過 query、body 或者 header 帶上。請(qǐng)求到達(dá)服務(wù)器，那就不核對(duì) cookie 傳送的信息，只看自定義字段就好，如果正確，那一定是能看到 cookie 的本域發(fā)送的請(qǐng)求，CSRF 則做不到這一點(diǎn)。（這個(gè)方法用于前后端分離，后端渲染則可以直接寫入到 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

跨域是瀏覽器限制，跨域資源共享（Cross-origin resource sharing）也是服務(wù)器與瀏覽器協(xié)調(diào)的結(jié)果。

如果服務(wù)器設(shè)置了 CORS 相關(guān)配置，在返回瀏覽器的請(qǐng)求頭會(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ù)器詢問當(dāng)前源是否符合 CORS 目標(biāo)，驗(yàn)證通過后才會(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
 */

順帶一提，Access-Control-Allow-Credentials 設(shè)為 true 時(shí)，Access-Control-Allow-Origin 強(qiáng)制不能設(shè)為 *，為了安全，也是挺麻煩。

回復(fù)“加群”與大佬們一起交流學(xué)習(xí)~

點(diǎn)擊“閱讀原文”查看 100+ 篇原創(chuàng)文章