當前位置：首頁 > 人文社科 > 生活经验 >内容正文

生活经验

不同版本浏览器前端标准兼容性对照表以及CORS解决跨域和CSRF安全问题解决方案

發布時間：2023/11/27 生活经验 50 豆豆

生活随笔收集整理的這篇文章主要介紹了不同版本浏览器前端标准兼容性对照表以及CORS解决跨域和CSRF安全问题解决方案小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

CORS也已經成為主流的跨域解決方案，不過CORF也會引發CSRF，本文先分享第三方的一個前端工具箱全面展示那些瀏覽器版本支持CORS，由于各家瀏覽器廠商因為各自原因在不同的版本里支持的標準不同，這個工具小而美，可以清晰的比較不同版本瀏覽器前端技術兼容性對照表。

先看圖下面這個網站可以很方便的查看不同版本瀏覽器對CORS的支持力度，IE10，IE11，Chrome，Firefox，Safari太多了一個都少不了，基本涵蓋常見或者不常見的瀏覽器了，話說做前端真不容易啊。

https://caniuse.com/#search=cors

?如圖所示，這個圖表不是單純的顯示支持與不支持，還做了一些細分：

1 Does not support CORS for images in?<canvas>

2 Supported somewhat in IE8 and IE9 using the XDomainRequest object (but has?limitations)

3 Does not support CORS for?<video>?in?<canvas>: https://bugs.webkit.org/show_bug.cgi?id=135379

4 Does not support CORS for resources which redirect: https://bugzilla.mozilla.org/show_bug.cgi?id=1346749

CORS 跨域實現思路及相關解決方案? ?寫的很好

其他例如CSS Grid Layout (level 1)

CSS Flexible Box Layout Module

ECMAScript 2015 (ES6)

也可以按不同的瀏覽器版本直接對比對不同技術規范的支持，比如H5選擇最新版本的IE11，Chrome，Firefox，Safari比較：

分至少部分支持和混合支持：

如果你遇到跨域問題還沒有使用CORS那么趕緊往下看。

同源政策

維基百科上關于同源策略的定義http://en.wikipedia.org/wiki/Same_origin_policy
同源策略是Web應用程序安全模型中的一個重要概念。根據該策略，Web瀏覽器允許第一個Web頁面中包含的腳本訪問第二個Web頁面中的數據，但前提是兩個Web頁面具有相同的源。原點定義為URI方案，主機名和端口號的組合。此策略可防止一個頁面上的惡意腳本通過該頁面的文檔對象模型訪問另一個網頁上的敏感數據。

放寬同源政策（跨域解決方案）

在某些情況下，同源策略限制性太強，對使用多個子域的大型網站造成問題。首先，使用諸如使用片段標識符或window.name屬性的許多變通方法來在駐留在不同域中的文檔之間傳遞數據。現代瀏覽器支持多種技術，以受控方式放寬同源策略：

1.document.domain屬性
如果兩個窗口（或框架）包含將域設置為相同值的腳本，則這兩個窗口將放寬同源策略，并且每個窗口可以與另一個窗口交互。例如，從orders.example.com和catalog.example.com加載的文檔中的協作腳本可能會將其document.domain屬性設置為“example.com”，從而使文檔看起來具有相同的來源并使每個文檔都能夠讀取另一個的屬性。設置此屬性會隱式將端口設置為null，大多數瀏覽器將從端口80或甚至未指定的端口進行不同的解釋。要確保瀏覽器允許訪問，請設置兩個頁面的document.domain屬性。

2.跨源資源共享(CORS)
另一種放寬同源策略的技術是以跨源資源共享的名義標準化的。此標準使用新的Origin請求標頭和新的Access-Control-Allow-Origin響應標頭擴展HTTP。它允許服務器使用標頭明確列出可能請求文件或使用通配符的起源，并允許任何站點請求文件。諸如Firefox 3.5，Safari 4和Internet Explorer 10之類的瀏覽器使用此標頭來允許具有XMLHttpRequest的跨源HTTP請求，否則這些請求將被同源策略禁止。

3.跨文檔消息
另一種技術是跨文檔消息傳遞，允許來自一個頁面的腳本將文本消息傳遞到另一頁面上的腳本，而不管腳本來源如何。在Window對象上異步調用postMessage()方法會在該窗口中觸發“onmessage”事件，從而觸發任何用戶定義的事件處理程序。一個頁面中的腳本仍然無法直接訪問另一個頁面中的方法或變量，但它們可以通過此消息傳遞技術安全地進行通信。

4.JSONP?
由于允許HTML<script>元素從其他域檢索和執行內容，因此頁面可以繞過同源策略，并通過加載返回JSONP有效負載的資源從不同的域接收JSON數據。JSONP有效負載由預定義函數調用包裝的內部JSON有效負載組成。當瀏覽器加載腳本資源時，將調用指定的回調函數來處理包裝的JSON有效負載。

5.WebSockets?
現代瀏覽器將允許腳本連接到WebSocket地址而不應用同源策略。但是，它們會在使用WebSocketURI時識別，并將Origin：標頭插入到請求中，該請求指示請求連接的腳本的來源。為確保跨站點安全性，WebSocket服務器必須將標頭數據與允許接收回復的原始白名單進行比較。

為什么CORS很重要？

JavaScript和網絡編程多年來實現了跨越式發展，但同源政策仍然存在。這可以防止JavaScript跨域邊界發出請求，并產生了各種用于發出跨域請求的黑客攻擊。

CORS引入了一種標準機制，可供所有瀏覽器用于實現跨域請求。規范定義了一組標頭，允許瀏覽器和服務器就允許（和不允許）哪些請求進行通信。CORS通過為所有人提供API訪問來延續開放網絡的精神。

CORS與JSONP的使用目的相同，但是比JSONP更強大。

CORS與JSONP的比較可以看看https://stackoverflow.com/questions/12296910/so-jsonp-or-cors

為什么JSONP仍然是強制性的

為什么JSONP仍然是強制性的?

解決方案
使用JSONP是確保與舊瀏覽器的良好兼容性并處理錯誤配置的防火墻/代理問題的唯一解決方案。但是，CORS提供了正確錯誤處理的優勢，因此我們不希望將自己局限于JSONP。

在我們的JavaScript客戶端的最新版本中，我們決定使用CORS來回退JSONP。在客戶端初始化時，我們檢查瀏覽器是否支持CORS，然后執行OPTIONS查詢以檢查是否沒有阻止CORS請求的防火墻/代理。如果有任何錯誤，我們會回避JSONP。我們的JavaScript客戶端可以使用所有這些邏輯，而無需為客戶更改任何API /代碼。

擁有CORS支持以及JSONP上的自動回退是我們發現的最佳方式，可確保提供卓越的服務質量并支持所有角落情況。如果您看到其他任何方式，我們非常歡迎您的反饋。

小結：JSONP只支持GET請求，CORS支持所有類型的HTTP請求。JSONP的優勢在于支持老式瀏覽器，以及可以向不支持CORS的網站請求數據。

如何使CORS生效

為了使CORS正常生效，我們可以添加HTTP標頭，允許服務器描述允許使用Web瀏覽器讀取該信息的一組源，并且對于不同類型的請求，我們必須添加不同的標頭。該請求可以主要分為簡單請求和預檢請求。
簡單請求
請求不會觸發CORS預檢是所謂的簡單請求。一個簡單的請求應滿足以下所有條件：

對于一個簡單的請求，要使CORS正常工作，Web服務器應該設置一個HTTP頭：

Access-Control-Allow-Origin: *

設置此標頭意味著任何域都可以訪問該資源。如果我們想限制到一個特定域，我們可以將其設置為：

Access-Control-Allow-Origin: http://specific.domain.example

預檢請求
預先請求的請求首先通過該OPTIONS方法向服務器發送HTTP請求，以確定實際請求（以下請求）是否可安全發送。預檢請求應滿足以下所有條件：

對于預先發出的請求，要使CORS正常工作，Web服務器應設置一些HTTP標頭：

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 80000

CORS on Nginx

參考：https://enable-cors.org/server_nginx.html

#
# Wide-open CORS config for nginx
#
location / {if ($request_method = 'OPTIONS') {add_header 'Access-Control-Allow-Origin' '*';add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';## Custom headers and headers various browsers *should* be OK with but aren't#add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';## Tell client that this pre-flight info is valid for 20 days#add_header 'Access-Control-Max-Age' 1728000;add_header 'Content-Type' 'text/plain; charset=utf-8';add_header 'Content-Length' 0;return 204;}if ($request_method = 'POST') {add_header 'Access-Control-Allow-Origin' '*';add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';}if ($request_method = 'GET') {add_header 'Access-Control-Allow-Origin' '*';add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';}
}

防止CSRF攻擊

根據同源策略，既然允許跨源寫入，這就可能會導致安全問題引發CSRF攻擊。

要防止CSRF攻擊，請在請求中檢查不可語量的令牌。例如，在HTTP參數中有一個隨機生成的令牌，表示名稱_csrf。

https://stackoverflow.com/questions/5207160/what-is-a-csrf-token-what-is-its-importance-and-how-does-it-work

CSRF解決方案參考：https://github.com/OWASP/CheatSheetSeries

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md?

需要保護的資源不受CSRF漏洞的影響

以下列表假定您沒有違反RFC2616第9.1.1節，通過使用GET請求進行狀態更改操作。

注意：如果你違反任何理由，你也需要保護這些資源，其中大部分是使用默認實現form?tag?[GET method]，href和src屬性。

使用POST表單標簽
Ajax / XHR調用

CSRF防御建議摘要

我們建議基于令牌的CSRF防御（有狀態/無狀態）作為緩解應用程序中CSRF的主要防御。僅對于高度敏感的操作，我們還建議基于用戶交互的保護（重新認證/一次性令牌，詳見6.5節）以及基于令牌的緩解。

作為一項縱深防御措施，請考慮從“深度緩解防御”部分實施一項緩解措施（您可以根據其中提到的問題選擇適合您的生態系統的緩解措施）。建議不要使用這些縱深防御緩解技術（不使用基于令牌的緩解）來減輕應用程序中的CSRF。

初級防御技術

基于令牌的緩解

這種防御是減輕CSRF的最受歡迎和推薦的方法之一。它可以通過狀態（同步器令牌模式）或無狀態（基于加密/散列的令牌模式）來實現。請參閱第4.3節，了解如何減輕應用程序中的登錄CSRF。對于所有緩解措施，隱含的是應遵守一般安全原則

應遵循強加密/ HMAC功能。

注意：您可以根據組織需求選擇任何算法。我們建議使用AES256-GCM進行加密，使用SHA256 / 512進行HMAC。

應保持嚴格的密鑰輪換和令牌生存期策略。可以根據您的組織需求設置策略。可以在此處找到OWASP的通用密鑰管理指南。

參考：

什么是CORS（跨源資源共享）

HTTP訪問控制（CORS）

https://www.w3.org/TR/cors/

總結

以上是生活随笔為你收集整理的不同版本浏览器前端标准兼容性对照表以及CORS解决跨域和CSRF安全问题解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。