SSShooter

SSShooter

Write like you're running out of time.
首頁封存關於Usubeni Fantasy

前端網絡安全必修 1 SOP、CSRF 和 CORS

#coding#网络安全545
AI 翻譯
這篇文章透過AI由簡體中文翻譯成繁體中文。查看原文
AI 生成的摘要
本文介紹了同源策略（SOP）、跨站請求偽造（CSRF）和跨域資源共享（CORS）的概念和限制。同源策略是指協議、域名和端口都相同的網站被視為同源，並且限制了對非同源資源的操作。跨站請求偽造是一種常見的攻擊方式，攻擊者利用已登錄的用戶的cookie發起對其他網站的請求。跨域資源共享則是通過設置CORS相關配置，解除了跨域限制。文章還提到了一些繞過跨域限制的方法，以及防範CSRF攻擊的措施。

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

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

同源策略 SOP#

同源#

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

url同源
https://niconico.com基準
https://niconico.com/spirito
https://sub.niconico.com/spiritx
http://niconico.com/spiritx
https://niconico.com:8080/spiritx

限制#

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

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

如果你說 SOP 就是 “禁止跨域請求”，這也不對，本質上 SOP 並不是禁止跨域請求，而是在請求後攔截了請求的回應。

其實表面上 SOP 分兩種情況：

  • 可以正常引用 iframe、圖片等各種資源，但是限制對其內容進行操作
  • 直接限制 ajax 請求，準確來說是限制操作 ajax 回應結果，這會引起後面說到的 CSRF

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

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

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

如果沒有了 SOP：

  • iframe 裡的機密信息被肆意讀取
  • 更加肆意地進行 CSRF
  • 接口被第三方濫用

繞過跨域#

SOP 雖然讓用戶更安全，同時也會對程序員帶來一定程度的麻煩，因為有時候業務上就是有跨域的需求。繞過跨域的方案由於篇幅所限，並且網上也很多相關文章，所以不在這裡展開解決跨域的方案，只給出幾個關鍵詞：

對於 ajax

  • 使用 JSONP
  • 後端進行 CORS 配置
  • 後端反向代理
  • 使用 WebSocket

對於 iframe

  • 使用 location.hash 或 window.name 進行信息交流
  • 使用 postMessage

跨站請求偽造 CSRF#

簡述#

CSRF（Cross-site request forgery）跨站請求偽造，是一種常見的攻擊方式。是指 A 網站正常登錄後，cookie 正常保存登錄信息，其他網站 B 通過某種方式調用 A 網站接口進行操作，A 的接口會在請求時會自動帶上 cookie。

上面說了，SOP 可以通過 html 標籤加載資源，而且 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>

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

回顧 SOP 的限制，這兩個例子都是直接用 html 標籤發起請求，而瀏覽器允許這麼做，歸根到底就是因為你無法用 js 直接操作獲得的結果。

SOP 與 ajax#

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

所以再強調一次，同源策略不能作為防範 CSRF 的方法。

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

CSRF 對策#

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

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

所以應對 CSRF 有這樣的思路：就是前後端分離常用的鑑權方法，使用 token 鑑權，並且不把 token 存放在 cookie，請求時在請求頭上手動加上。

另一個方法是：cookie 裡的東西，在發起請求時通過 query、body 或者 header 帶上。請求到達服務器，那就不核對 cookie 傳送的信息，只看自定義字段就好，如果正確，那一定是能看到 cookie 的本域發送的請求，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#

跨域是瀏覽器限制，跨域資源共享（Cross-origin resource sharing）也是服務器與瀏覽器協調的結果。

如果服務器設置了 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 簡單請求。簡單請求都會直接發到服務器，會造成 CSRF。

預檢請求#

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

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

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

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

CORS 與 cookie#

與同域不同，用於跨域的 CORS 請求默認不發送 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
 */

順帶一提，Access-Control-Allow-Credentials 設為 true 時，Access-Control-Allow-Origin 強制不能設為 *，為了安全，也是挺麻煩啊...

開坑預告#

暫時先說到這，若有疑問請在評論區提出，以後應該會講講 XSS、CSP 和 http/https 相關的主題。

原文傳送門：https://ssshooter.com/2019-11-08-csrf-n-cors/

參考#

重點推薦 Whitepaper: The Definitive Guide to Same-origin Policy

egg.js 網絡安全

CSRF owasp

跨域資源共享 CORS 詳解

瀏覽器同源政策及其規避方法

載入中......
此文章數據所有權由區塊鏈加密技術和智能合約保障僅歸創作者所有。