同源策略

NO IMAGE

同源策略(Same-origin policy,簡稱 SOP)

同源

何為同源?

協議、域名、端口都一樣,就是同源

限制

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

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

如果你說 SOP 就是“禁止跨域請求”,這也不對,本質上 SOP 並不是禁止跨域請求,而是在請求後攔截了請求的迴應。這就會引起後面說到的 CSRF

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

  • 限制 cookies、DOM 和 Javascript 的命名區域
  • 限制 iframe、圖片等各種資源的內容操作
  • 限制 ajax 請求,準確來說是限制操作 ajax 響應結果,本質上跟上一條是一樣的

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

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

如果沒有了 SOP:

  • 一個瀏覽器打開幾個 tab,數據就洩露了
  • 你用 iframe 打開一個銀行網站,你可以肆意讀取網站的內容,就能獲取用戶輸入的內容
  • 更加肆意地進行 CSRF

解決跨域的辦法就不說了,網上一查一大把

跨站請求偽造 CSRF

CSRF(Cross-site request forgery)跨站請求偽造,是一種常見的攻擊方式。

設想這樣一種情況:A網站是一家銀行,用戶登錄以後,又去瀏覽其他的網站,如果其他網站可以讀取A網站的Cookie,會發生什麼?很顯然,如果Cookie包含隱私(比如存款總額),這些信息就會洩漏。更可怕的是Cookie往往用來保存用於的登錄狀態,如果用戶沒有退出登錄,其他網站就可以冒充用戶為所欲為,因為瀏覽器同時還規定,提交表單不受同源策略的限制。

補充一下,cookie一般做身份認證,cookie是客戶端向服務端發請求時自帶的,而在你進入惡意網站的一瞬間,惡意網站的js腳本就會執行,那他可以通過<img>來向A網站服務器發送一個請求,A網站服務器就誤以為是用戶的操作,或者通過<form>發送一個post請求,效果是一樣的,試想如果惡意網站發送的請求是轉賬10萬,後果可想而知

上面說了,SOP 可以通過 html tag 加載資源,而且 SOP 不阻止接口請求而是攔截請求結果,CSRF 恰恰佔了這兩個便宜。

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

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

  • 對於 POST 請求,很多例子都使用 form 提交

歸根到底,這兩個方法不報跨域是因為請求由 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 寫到 cookie 裡,在發起請求時再通過 query、body 或者 header 帶上這個 token。請求到達服務器,核對這個 token,如果正確,那一定是能看到 cookie 的本域發送的請求,CSRF 則做不到這一點。(這個方法用於前後端分離,後端渲染則可以直接寫入到 dom 中)

跨域資源共享 CORS

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

Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Age: 0
Connection: keep-alive
Content-Length: 73
Content-Type: application/json;charset=UTF-8
Date: Fri, 14 Feb 2020 08:49:14 GMT
Set-Cookie: aliyungf_tc=AQAAAOqu0AYWRAsAh470eGjRMNY7tVXP; Path=/; HttpOnly
Via: 1.1 varnish
X-Cache: 10.0.0.4MISS120.244.142.135, 47.111.193.22, 100.97.58.25,10.0.0.29
X-Varnish: 223066077

對於 CORS,請求分兩種。

簡單請求

  1. 請求方法使用 GET、POST 或 HEAD

  2. 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。

順帶一提,Access-Control-Allow-Credentials設為true時,Access-Control-Allow-Origin 強制不能設為 *,為了安全

相關文章

Promise源碼

手寫new

手寫call、apply、bind

ES6模塊和CommonJS模塊