「disown-opener」內容安全策略是做什麼的？

Question

CSPv3指定一個新disown-opener政策：

將不認大開眼界指令確保了資源時，將導航到disown its opener。

鏈接的WHATWG規範是不是非常有幫助或者：

揭幕戰IDL窗口對象的屬性，在獲取時，必須返回瀏覽器上下文的WindowProxy對象從當前瀏覽器上下文（它的開啓者瀏覽上下文），如果有的話，是否仍然可用，以及如果當前的瀏覽上下文沒有拒絕其開啓者;否則，它必須返回null。在設置時，如果新值爲空，則當前瀏覽上下文必須使其開啓者失效;如果新值是其他值，那麼用戶代理必須調用Window對象的[[DefineOwnProperty]]內部方法，將屬性名稱「opener」作爲屬性鍵和屬性描述符{[[Value]]：值，[[Writable]]：true，[[Enumerable]]：true，[[Configurable]]：true}作爲屬性描述符，其中value是新值。

Answer 1

它會導致window.opener設置爲null任何新的窗口或標籤是那些獲得導航到任何文件與包含disown-opener指令CSP的首部擔任。

用例類似於rel=noopener的用例。

這兩種攻擊的目的都是爲了防止這個事實，例如當你的文檔A到文檔B（可能在另一個源）有鏈接時，文檔B中的任何腳本都可以通過window.opener訪問並控制文檔A處的窗口對象。

因此，文檔B的腳本可以將窗口文檔A的值從window.opener.location更改爲文檔C的URL，以便窗口從文檔A導航到該URL。

如果文檔C被設計成完全像文檔A - 例如包括欺騙登錄表單 - 它可能被用來欺騙用戶和網絡釣魚用戶憑證。

Mathias Bynens在About rel=noopener: What problems does it solve?中詳細討論了該問題。

設置window.opener至null關於要導航的文檔以防止出現問題。

沒有disown-opener它解決了用例，文檔的第一需要打開一個新的標籤/窗口，文檔和/或位置時，它控制，然後使用腳本來設置window.opener到null，然後讓腳本在文檔該選項卡/窗口將其導航到文檔B.

更新：我已爲raised a PR against the HTML spec添加了有關該規範的信息性註釋。