CORS 從理解到驗證

cors(cross-origin resource sharing跨源資源共享) 是一種認證機制，是w3c(全球資訊網聯盟) 推薦的一種用於跨域資源訪問的安全策略。

源與同源策略

cors 中的源指的是某個url中的協議、網域名稱和埠，由這三個元素標識乙個唯一的源，如http://localhost:8080和https://localhost:8000是不同的源，因為它們的協議和埠都不同。

源也可以寬泛地理解為乙個 web站點，通常我們訪問乙個**的時候，載入的靜態資源通常都是站內的。比如下圖的例子，當我們訪問必應的首頁時，http請求中的資源，也是來自必應**的。

訪問站內資源一般不會有限制，這裡也可以引申出乙個安全機制叫同源策略 (same-origin policy)。

當我們訪問網頁時，網頁中的不同靜態資源，比如、js指令碼等可以通過url的方式載入進來，在同源策略的安全機制下，這些url只能屬於同乙個源。而cors允許網頁從網際網路上的其他web站點載入靜態資源。

cors根據請求型別可以分為靜態和動態兩種：

靜態的cors的常見例子就是 html 中的 img 標籤，src欄位設定為其他 web站點的 url，這就是一次靜態的cors例子

動態的cors請求就是在ajax請求中訪問跨域資源，處於安全考慮，瀏覽器限制從指令碼中發起的跨域http請求，接下來也主要討論這類cors請求

跟實現cors相關的幾個header

cors實現

瀏覽器要支援在發起跨域請求時附加origin頭，並在響應返回時檢查access-control-allow-origin等頭部，判斷服務端是否支援或允許該跨域請求。現代的瀏覽器基本都支援cors。

服務端要在響應中設定access-control-allow-origin等響應頭，表示自己支援cors，並宣告自己的安全策略

因為要驗證多個源之間的資源訪問，所以要啟動兩個web服務，這裡使用 gin 框架啟動兩個web服務：

webserver a（服務端支援cors）

type corsoptions struct 
// 參考 
func cors(options corsoptions) gin.handlerfunc 
c.writer.header().set("access-control-max-age","86400")
c.writer.header().set("access-control-allow-methods","post, get, options, put, delete, update")
c.writer.header().set("access-control-allow-headers", "origin, content-type, content-length, accept-encoding, x-csrf-token, authorization, x-auth-token, x-auth-uuid, x-auth-openid, referrer, authorization, x-client-id, x-client-version, x-client-type")
c.writer.header().set("access-control-expose-headers", "content-length")
c.writer.header().set("access-control-allow-credentials", "true")
if c.request.method == "options"  else 	}}
func main() ))
// 設定靜態資源的訪問路由，目錄下包含乙個檔案
//  載入用於驗證cors的網頁
r.loadhtmlglob("template/home/*.tmpl")
r.get ("/cors",func(c *gin.context) )
r.run(":8081")
}

webserver b（服務端不支援cors）

func main() )
r.run(":8082")
}

用於驗證的網頁模板

驗證結果

從例子中也可以看到，瀏覽器對靜態cors請求的資源不會做驗證，只對js指令碼中發起的ajax跨域請求應用cors驗證，這大概是因為跨域資源訪問帶來的安全風險大多是由惡意指令碼發起的跨域請求引起的。

正如文章開頭說的那樣，通常web伺服器的靜態檔案資源只提供給同源的**載入。當業務系統中由多個web應用時，可能需要共享某些靜態資源，這時我們會把access-control-allow-origin設定為"*"，方便資源共享，但是這也意味著網際網路上其他站點也可以訪問你的靜態資源，尤其access-control-allow-methods包含 put, post, delete 等可以操作靜態資源的方法時，可能就會被惡意利用和篡改。

比如 csrf 攻擊，就是誘導使用者訪問web a，然後竊取使用者的cookie資訊並執行惡意指令碼訪問使用者之前訪問的 web b，由於黑客已經獲取了使用者的認證資訊(cookie)以及web b服務端支援cors，所以就可以在跨域請求中以使用者的名義執行惡意**。

因此，服務端在考慮是否支援cors和跨域請求的安全策略時，一定要結合業務場景和安全需求，謹慎設定access-control-allow-origin和access-control-allow-methods等響應頭

cors——跨域請求那些事兒

mdn web 文件 —— cors

CORS 從理解到驗證

快速排序從理解到掌握

動態規劃，從例子到理解

反向傳播理解從抽象到具體

CORS 從理解到驗證

快速排序 從理解到掌握

動態規劃，從例子到理解

反向傳播理解 從抽象到具體

相關推薦

快速排序從理解到掌握

反向傳播理解從抽象到具體