*隨著Chrome 83的最新發布以及即將發布的Mozilla Firefox 79的發布，web開發人員正在設計更強大的新安全機制，以保護其應用程序免受常見Web漏洞的侵害。在本文中，將介紹信息安全工程團隊是如何在Google內部署“受信任類型”，“ 內容安全策略”，“ 獲取元數據請求標頭”和“ 跨域開放者政策”，以幫助指導和啟發其他開發人員同樣采用這些功能來保護其應用程序。

過去

自從現代Web應用程序問世以來，例如電子郵件客戶端或可在瀏覽器中訪問的文檔編輯器，開發人員一直在處理常見的Web漏洞，這些漏洞可能使用戶數據容易受到攻擊者的攻擊。雖然Web平臺為基礎操作系統提供了強大的隔離，但是Web應用程序本身之間的隔離卻是另一回事。如問題XSS、CSRF和跨站點泄露已經成為Web開發的不幸的方面，影響到幾乎每一個網站在某個時間點。

這些漏洞是Web某些最奇妙的特性的意外后果：可組合性，開放性和易于開發。簡而言之，網絡的原始愿景是相互關聯的文檔網格無法預期會創建一個充滿活力的Web應用程序生態系統，以處理全球數十億人的私人數據。因此，旨在幫助開發人員保護其用戶數據的Web平臺的安全功能發展緩慢，并且僅提供了針對常見漏洞的部分保護。

傳統上，Web開發人員通過構建其他安全工程工具和流程來保護其應用程序免受常見漏洞的影響，從而彌補了平臺的缺點。事實證明，此類基礎架構的開發和維護成本很高。隨著Web不斷變化，為開發人員提供了更多令人印象深刻的功能，并且Web應用程序對我們的生活變得越來越重要，我們發現自己對直接內置于Web平臺的更強大，更全面的安全機制的需求日益增長。

在過去的兩年中，來自Google和其他公司的瀏覽器制造商和安全工程師已經合作設計和實施了幾種主要的安全功能，以防御常見的Web漏洞。我們在本文中重點介紹的這些機制可防止注入，并提供隔離功能，解決了網絡上兩個長期存在的不安全根源。

注入漏洞

在網絡上，應用程序代碼歷來與頁面數據交織在一起。HTML標記（例如< script>元素或事件處理程序屬性（onclick或onload））允許執行JavaScript；導航到javascript時，即使是熟悉的URL也可以攜帶代碼并導致腳本執行：鏈接。盡管有時很方便，但這種設計的結果是–除非應用程序注意保護自己，否則用于編寫HTML頁面的數據可以輕松地插入不需要的腳本并在用戶的瀏覽器中控制該應用程序。

以原則上的方式解決此問題需要允許應用程序將其數據與代碼分開；這可以通過啟用兩個新的安全功能來完成：受信任的類型和基于腳本隨機數的內容安全策略。

信任的類型

開發人員構建Web應用程序中使用JavaScript函數通常依賴于分析任意結構進行串。傳遞給通用API（例如（innerHTML）的似乎包含數據的字符串可以直接轉換為代碼。這是大多數基于DOM的XSS漏洞的根本原因。

信任類型通過限制危險的操作（例如生成HTML或創建腳本）來要求特殊對象–信任類型，從而使JavaScript代碼默認情況下安全。瀏覽器將確保僅在正確的對象提供給該函數的情況下才允許使用危險的DOM函數。只要應用程序在中央“ 受信任的類型”策略中安全地生成這些對象，它就不會包含基于DOM的XSS錯誤。

您可以通過設置以下響應標頭來啟用“受信任的類型”：

我們最近為My Google Activity的所有用戶啟動了Trusted Types，并且正在與Google的數十個產品團隊以及JavaScript框架所有者合作，以使他們的代碼支持這一重要的安全機制。

Chrome 83和其他基于Chromium的瀏覽器支持“受信任的類型” ，其他用戶代理也可以使用polyfill。

基于腳本隨機數的內容安全策略

內容安全策略（CSP）允許開發人員要求頁面上的每個< script>都包含攻擊者未知的秘密值。腳本隨機數屬性（對于每次頁面加載均設置為不可預測的數字）可確保給定腳本處于應用程序的控制之下：即使攻擊者注入了部分頁面，瀏覽器也將拒絕執行任何操作。注入的腳本無法以正確的隨機數標識自己。這樣可以減輕任何服務器端注入錯誤的影響，例如反射的XSS和存儲的XSS。

可以通過設置以下HTTP響應標頭來啟用CSP：

此標頭要求HTML模板系統中的所有腳本都包括一個nonce屬性，其值與響應標頭中的值匹配：

我們的CSP評估工具可幫助您配置強大的政策。

自Google首次推出CSP以來，我們已經針對來自應用程序的75％的出站流量部署了強大的政策，包括旗艦產品（如GMail和Google Docs＆Drive）。在過去兩年中，CSP減輕了Google對30多個高風險XSS漏洞的利用。

Chrome，Firefox，Microsoft Edge和其他基于Chromium的瀏覽器均支持基于Nonce的CSP。Safari也提供對CSP變體的部分支持。

隔離能力
攻擊者的網站利用了許多類型的Web漏洞，迫使它們與另一個Web應用程序進行不必要的交互。防止這些問題要求瀏覽器提供新的機制，以允許應用程序限制此類行為。提取元數據請求標頭可在處理傳入的HTTP請求時建立服務器端限制。在跨來源開瓶器策略是客戶端機制，保護應用程序的窗口從不需要DOM的相互作用。

獲取元數據請求標頭

的網絡安全問題的常見原因是應用程序沒有收到有關一個給定的HTTP請求的來源，因此不能夠區分良性自發起網絡來自其他網站發送的有害請求的流量。這導致諸如跨站點請求偽造（CSRF）和基于Web的信息泄漏（XS-leaks）之類的漏洞。

瀏覽器附加到傳出HTTP請求的獲取元數據標頭通過為應用程序提供有關發送到服務器的請求來源的可信信息來解決此問題：請求的源，請求的類型（例如，是導航還是請求資源）以及其他與安全性相關的元數據。

通過檢查這些新的HTTP標頭（Sec-Fetch-Site，Sec-Fetch-Mode和Sec-Fetch-Dest）的值，應用程序可以構建靈活的服務器端邏輯來拒絕不受信任的請求，類似于以下內容：

我們在web.dev/fetch-metadata 中提供了有關此邏輯和采用注意事項的詳細說明。重要的是，“獲取元數據”可以補充并促進跨域資源策略的采用，該策略提供了針對意外子資源負載的客戶端保護；此標頭在resourcepolicy.fyi中詳細描述。

在Google，我們已在一些主要產品（例如Google Photos）中使用Fetch Metadata標頭啟用了限制，并且正在跟進整個應用程序生態系統的大規模推廣。

提取元數據標頭當前由基于Chrome和Chromium的瀏覽器發送，并且在Firefox的開發版本中可用。

跨域開放者政策

在默認情況下，在網絡允許與屬于另一個應用程序的瀏覽器窗口的某些交互：任何網站可以打開一個彈出來的網頁郵件客戶端，并通過發送郵件的postMessage API，將其導航到另一個URL，或獲取有關其框架的信息。所有這些功能都可能導致信息泄漏漏洞：

跨域開放者政策（COOP）允許您鎖定應用程序以防止此類交互。要在您的應用程序中啟用COOP，請設置以下HTTP響應標頭：

如果您的應用程序將其他站點作為彈出窗口打開，則可能需要將標頭值設置為same-origin-allow-popups；

我們目前正在多個Google應用程序中測試跨源開放者政策，我們期待在未來幾個月中廣泛啟用它。

從Chrome 83和Firefox 79開始提供COOP。

未來

創建強大而充滿活力的網站要求開發人員能夠保證其用戶數據的安全性。向Web平臺添加安全機制-將其直接構建到瀏覽器中-是生態系統邁出的重要一步：瀏覽器可以幫助開發人員理解和控制影響其安全狀況的網站方面。當用戶更新到他們喜歡的瀏覽器的最新版本時，他們將獲得免受過去曾影響Web應用程序的許多安全漏洞的保護。

盡管本文中描述的安全功能不是萬能藥，但它們提供了基本的構建基塊，可幫助開發人員構建安全的Web應用程序。期待與瀏覽器制造商和Web標準社區合作在將來改進它們。