經銷商專區｜登入
〔最新消息〕2021-01-29
加強線上應用程式對Pass-the-Cookie攻擊的防範能力
最近，網路安全與基礎設施安全局（CISA）發佈了一份分析報告（AR21-013A），內容是加強安全配置以抵禦針對雲服務的攻擊者。分析報告認為，參與雲服務攻擊的網路威脅行為者使用了多種戰術和技術，包括網路釣魚、蠻力登錄攻擊和可能的 "傳遞cookie "攻擊。
CISA報告說，他們驗證了威脅行為者通過適當的多因素認證（MFA）成功登錄了一個用戶的帳戶，在這種情況下，CISA認為威脅行為者可能使用了瀏覽器cookie，以 "傳遞-cookie "攻擊來擊敗MFA（使用備用認證材料：Web會話cookie[T1550.004]）。這一部分提出了一些關於多因素認證(MFA)的有效性以及MFA是否仍然適合使用的問題。
Web應用是典型的離線應用，這意味著應用的用戶端只要需要更新，就會聯繫伺服器端或服務，除非用戶端有在本地對存儲在用戶端的事件或資料進行操作，比如邏輯漸進式Web應用（PWA）就是如此。
什麼是漸進式網路應用？
PWA是一種通過網路交付的應用軟體，使用HTML、CSS和JavaScript等常見的網路技術構建。它可以在任何使用符合標準的瀏覽器的平臺上運行，包括桌面和移動設備。
PWA是一個單頁的Web應用程式，可以安裝在任何具有相容瀏覽器的設備上，並可以離線運行。該應用程式可以訪問本機存放區、移動設備感測器，提供對推送通知的支援等。PWA很像一個線上應用程式，線上時提供來自其Web服務的即時資訊，但離線時可以使用本地緩存資訊，它的外觀和行為就像一個本地應用程式。
PWA不需要專有的應用商店來交付和安裝，安裝只需通過網路瀏覽器完成。它可以運行在任何有相容瀏覽器的平臺上，並使用瀏覽器的執行時間，這意味著它可以運行在Windows、macOS、Chrome、iOS、iPadOS、Android、Linux等。
PWA廣泛地依賴於瀏覽器的JavaScript引擎，過去完全用JavaScript編寫。並不是每個人都喜歡JavaScript，這就導致了JavaScript移植器的出現，使開發人員可以用Scala、Dart、CoffeeScript、Groovy、Lua等編寫複雜的用戶端應用程式。不需要交叉編譯或重建應用程式；在移植應用程式的情況下，需要一個翻譯步驟，但該應用程式將在所有平臺上使用符合標準的瀏覽器原生運行。
WebAssembly
最近，在2017年3月，WebAssembly或Wasm作為一個開放標準被引入。Wasm為基於堆疊的虛擬機器定義了一種可移植的二進位碼格式。Wasm被設計為程式設計語言的可移植編譯目標，使用戶端和伺服器應用程式能夠部署在網路上。我們可以把Wasm比作Java運行時。Java應用程式被編譯成位元組碼，可以在任何支援Java運行時的平臺上執行。Java運行時和Wasm之間的區別是，Wasm是開放的標準，並在W3C社區組開發，包括所有主要瀏覽器的代表，導致Wasm被支援在每一個符合標準的瀏覽器和平臺上，就像Javascript一樣。由於Wasm依賴於編譯後的代碼，就像Java位元組碼一樣，它的執行速度要快得多，而且與由網路引擎解釋的JavaScript的轉碼應用程式相比，開銷也少得多。
Wasm使Go、Rust和dotNet C#等語言能夠被編譯並以二進位碼的形式在互聯網上傳輸，並在用戶端瀏覽器引擎的上下文中有效地執行，這可能是一個瀏覽器內的應用程式或本地應用程式。Wasm重新定義了PWA的開發方式，允許開發人員用C#、Rust、Go或任何40種支援WebAssembly的高級程式設計語言，如C和C++、Python、Java和PHP來編寫線上應用程式和PWA。
線上應用程式中的狀態管理
即使在開發方面取得了這麼大的進步，線上應用中伺服器和用戶端之間的狀態管理方式與80年代的方式相比，還是有很大的變化。
無論你是在編寫一個網路應用、一個漸進式網路應用，還是一個網路服務，應用框架都需要管理用戶端和伺服器應用之間的狀態。即使HTTP被認為是一個有狀態的協定，用戶端應用和伺服器應用之間的上下文仍然是非常無狀態的。在應用程式的生命週期中，用戶端與Web或HTTP伺服器之間的通信電路是為每一個源自用戶端的新請求而重建和銷毀的。我忽略了持久性的HTTP連接，因為這些僅僅是一種性能的提升，並沒有改變用戶端應用和服務之間的狀態管理方式。
為了使用戶端應用和其服務之間的交互是有狀態的，Web應用和Web API一直在使用存儲在用戶端並傳輸到伺服器的令牌來識別用戶的 "會話"。
傳遞-Cookie攻擊
現在應該很清楚，為了授權使用者的請求，用戶端應用程式或瀏覽器需要以秘密令牌的形式向網路服務（伺服器端）提供一些上下文，作為請求的參數或cookie傳輸。
在使用者被授權之前，需要對他進行認證，在認證用戶的過程中，伺服器會生成一個唯一的令牌來識別該用戶和他的會話，並使用它來授權任何後續的請求。一旦通過認證，不管認證過程有多複雜，也不管是否涉及到MFA，通信的安全性只依賴於用戶端和服務之間交換的token。誰知道令牌，誰就可以向伺服器提交請求，而伺服器不會知道請求者的身份。
因此，從用戶和伺服器之間的會話中竊取令牌，將允許攻擊者代表該用戶在該用戶的範圍內執行任何操作。該令牌將一直有效，直到伺服器在其伺服器端存儲或緩存中的令牌失效，而這通常只發生在用戶端應用程式在使用者明確退出Web應用程式時請求該令牌時。
如果用戶沒有明確註銷，而是關閉了瀏覽器視窗，token不會立即失效，但可能會根據會話的超時或用戶會話的總允許壽命而失效。超時是伺服器應用端實現的，取決於應用的作者。如果使用者沒有明確地通過點擊按鈕從他的Web應用中註銷，瀏覽器向伺服器發送請求，攻擊者可以非常使用竊取的令牌保持會話的生命力，並繼續在用戶的上下文中進行請求，直到他決定他已經造成了足夠的損害，或者伺服器決定超時結束會話。
這個漏洞適用於所有在用戶端和伺服器應用之間實現狀態的應用，並不限於Web應用。原生移動應用、原生用戶端/伺服器應用和Web API利用非常類似的方式來創建上下文。只不過，在移動應用和機器對機器的Web API的情況下，Cookie並不存在，因為它們是一種瀏覽器服務。所以，後者需要實現自己的令牌，這就是API令牌的作用。很多API仍然使用靜態令牌，這些令牌只生成一次，可以使用很長時間，有的甚至是無限期的。
基於Web的協力廠商認證框架，如SAML和OATH採用了類似的使用令牌的模式，只是現在的令牌是與額外的協力廠商服務進行交換和授權，而不是直接在用戶端和伺服器之間交換。這些認證框架允許對伺服器端應用進行授權。一個組織可以在自己的身份伺服器中管理身份和授權，而伺服器端應用將通過該身份伺服器對用戶進行身份認證，並根據來自同一身份伺服器的授權進行授權訪問。此外，同樣的令牌和漏洞，以及由此產生的傳遞cookie攻擊，也適用於這些認證實現。
如何緩解通過Cookie的攻擊
有幾種方法可以抵制cookie傳遞攻擊，但都有其自身的缺點：
如果MFA仍然適合目的？
無論使用何種認證方式（MFA、SAML、OAUTH、電子身份證、偽亂數產生器等），"傳遞cookie "攻擊仍然具有很大的現實意義，不能因為認證方式的強弱而被挫敗。
身份驗證方法的強弱決定了它在識別該人並防止其他人冒充該人時的準確性。MFA仍然非常相關且適合目標，但與往常一樣，該鏈條與其最薄弱的環節一樣牢固。強大的身份驗證與較弱的令牌實現結合在一起將為惡意行為者提供機會，與強大的身份驗證與較弱的通信實現相結合，將使其容易受到憑據填充和暴力破解的侵害。
令牌中的一些隨機性可以減少攻擊者的機會視窗，但只有用戶端和伺服器之間的額外和持續的識別才會有幫助，這可以通過用戶端證書或瀏覽器識別方法的形式來實現--後者可能沒有證書那麼安全。
原文連結
CISA報告說，他們驗證了威脅行為者通過適當的多因素認證（MFA）成功登錄了一個用戶的帳戶，在這種情況下，CISA認為威脅行為者可能使用了瀏覽器cookie，以 "傳遞-cookie "攻擊來擊敗MFA（使用備用認證材料：Web會話cookie[T1550.004]）。這一部分提出了一些關於多因素認證(MFA)的有效性以及MFA是否仍然適合使用的問題。
Web應用是典型的離線應用，這意味著應用的用戶端只要需要更新，就會聯繫伺服器端或服務，除非用戶端有在本地對存儲在用戶端的事件或資料進行操作，比如邏輯漸進式Web應用（PWA）就是如此。
什麼是漸進式網路應用？
PWA是一種通過網路交付的應用軟體，使用HTML、CSS和JavaScript等常見的網路技術構建。它可以在任何使用符合標準的瀏覽器的平臺上運行，包括桌面和移動設備。
PWA是一個單頁的Web應用程式，可以安裝在任何具有相容瀏覽器的設備上，並可以離線運行。該應用程式可以訪問本機存放區、移動設備感測器，提供對推送通知的支援等。PWA很像一個線上應用程式，線上時提供來自其Web服務的即時資訊，但離線時可以使用本地緩存資訊，它的外觀和行為就像一個本地應用程式。
PWA不需要專有的應用商店來交付和安裝，安裝只需通過網路瀏覽器完成。它可以運行在任何有相容瀏覽器的平臺上，並使用瀏覽器的執行時間，這意味著它可以運行在Windows、macOS、Chrome、iOS、iPadOS、Android、Linux等。
PWA廣泛地依賴於瀏覽器的JavaScript引擎，過去完全用JavaScript編寫。並不是每個人都喜歡JavaScript，這就導致了JavaScript移植器的出現，使開發人員可以用Scala、Dart、CoffeeScript、Groovy、Lua等編寫複雜的用戶端應用程式。不需要交叉編譯或重建應用程式；在移植應用程式的情況下，需要一個翻譯步驟，但該應用程式將在所有平臺上使用符合標準的瀏覽器原生運行。
WebAssembly
最近，在2017年3月，WebAssembly或Wasm作為一個開放標準被引入。Wasm為基於堆疊的虛擬機器定義了一種可移植的二進位碼格式。Wasm被設計為程式設計語言的可移植編譯目標，使用戶端和伺服器應用程式能夠部署在網路上。我們可以把Wasm比作Java運行時。Java應用程式被編譯成位元組碼，可以在任何支援Java運行時的平臺上執行。Java運行時和Wasm之間的區別是，Wasm是開放的標準，並在W3C社區組開發，包括所有主要瀏覽器的代表，導致Wasm被支援在每一個符合標準的瀏覽器和平臺上，就像Javascript一樣。由於Wasm依賴於編譯後的代碼，就像Java位元組碼一樣，它的執行速度要快得多，而且與由網路引擎解釋的JavaScript的轉碼應用程式相比，開銷也少得多。
Wasm使Go、Rust和dotNet C#等語言能夠被編譯並以二進位碼的形式在互聯網上傳輸，並在用戶端瀏覽器引擎的上下文中有效地執行，這可能是一個瀏覽器內的應用程式或本地應用程式。Wasm重新定義了PWA的開發方式，允許開發人員用C#、Rust、Go或任何40種支援WebAssembly的高級程式設計語言，如C和C++、Python、Java和PHP來編寫線上應用程式和PWA。
線上應用程式中的狀態管理
即使在開發方面取得了這麼大的進步，線上應用中伺服器和用戶端之間的狀態管理方式與80年代的方式相比，還是有很大的變化。
無論你是在編寫一個網路應用、一個漸進式網路應用，還是一個網路服務，應用框架都需要管理用戶端和伺服器應用之間的狀態。即使HTTP被認為是一個有狀態的協定，用戶端應用和伺服器應用之間的上下文仍然是非常無狀態的。在應用程式的生命週期中，用戶端與Web或HTTP伺服器之間的通信電路是為每一個源自用戶端的新請求而重建和銷毀的。我忽略了持久性的HTTP連接，因為這些僅僅是一種性能的提升，並沒有改變用戶端應用和服務之間的狀態管理方式。
為了使用戶端應用和其服務之間的交互是有狀態的，Web應用和Web API一直在使用存儲在用戶端並傳輸到伺服器的令牌來識別用戶的 "會話"。
傳遞-Cookie攻擊
現在應該很清楚，為了授權使用者的請求，用戶端應用程式或瀏覽器需要以秘密令牌的形式向網路服務（伺服器端）提供一些上下文，作為請求的參數或cookie傳輸。
在使用者被授權之前，需要對他進行認證，在認證用戶的過程中，伺服器會生成一個唯一的令牌來識別該用戶和他的會話，並使用它來授權任何後續的請求。一旦通過認證，不管認證過程有多複雜，也不管是否涉及到MFA，通信的安全性只依賴於用戶端和服務之間交換的token。誰知道令牌，誰就可以向伺服器提交請求，而伺服器不會知道請求者的身份。
因此，從用戶和伺服器之間的會話中竊取令牌，將允許攻擊者代表該用戶在該用戶的範圍內執行任何操作。該令牌將一直有效，直到伺服器在其伺服器端存儲或緩存中的令牌失效，而這通常只發生在用戶端應用程式在使用者明確退出Web應用程式時請求該令牌時。
如果用戶沒有明確註銷，而是關閉了瀏覽器視窗，token不會立即失效，但可能會根據會話的超時或用戶會話的總允許壽命而失效。超時是伺服器應用端實現的，取決於應用的作者。如果使用者沒有明確地通過點擊按鈕從他的Web應用中註銷，瀏覽器向伺服器發送請求，攻擊者可以非常使用竊取的令牌保持會話的生命力，並繼續在用戶的上下文中進行請求，直到他決定他已經造成了足夠的損害，或者伺服器決定超時結束會話。
這個漏洞適用於所有在用戶端和伺服器應用之間實現狀態的應用，並不限於Web應用。原生移動應用、原生用戶端/伺服器應用和Web API利用非常類似的方式來創建上下文。只不過，在移動應用和機器對機器的Web API的情況下，Cookie並不存在，因為它們是一種瀏覽器服務。所以，後者需要實現自己的令牌，這就是API令牌的作用。很多API仍然使用靜態令牌，這些令牌只生成一次，可以使用很長時間，有的甚至是無限期的。
基於Web的協力廠商認證框架，如SAML和OATH採用了類似的使用令牌的模式，只是現在的令牌是與額外的協力廠商服務進行交換和授權，而不是直接在用戶端和伺服器之間交換。這些認證框架允許對伺服器端應用進行授權。一個組織可以在自己的身份伺服器中管理身份和授權，而伺服器端應用將通過該身份伺服器對用戶進行身份認證，並根據來自同一身份伺服器的授權進行授權訪問。此外，同樣的令牌和漏洞，以及由此產生的傳遞cookie攻擊，也適用於這些認證實現。
如何緩解通過Cookie的攻擊
有幾種方法可以抵制cookie傳遞攻擊，但都有其自身的缺點：
- 使用用戶端證書 給用戶一個持久性的令牌，可以安全地存儲在他的系統上，並在每次連接伺服器時使用--這可以使用存儲在作業系統上使用者設定檔中的用戶端認證來實現。雖然是最安全的選擇，但物流使其更難推出，因此，通常只用於需要從一組有限的使用者訪問的應用程式。例如，需要訪問B2B或內部線上應用程式的業務合作夥伴或員工。然而，對於電子商務網站來說，我們星球上的每個人都是潛在用戶，這並不能擴展。
- 使用動態令牌，每隔幾秒或幾分鐘改變一次，就像IPSEC VPN實現重鑰超時一樣。這將減少攻擊的機會視窗。如果攻擊者沒有足夠快的速度利用令牌，當他使用令牌時，他竊取的令牌將無效。然而，它並不能完全減輕攻擊，只是減少了機會之窗。
- 除了令牌之外，還要添加更多的上下文來識別請求的來源。例如，這可以是使用請求的源IP位址。使用者側的代理和互聯網負載均衡會造成問題，如果攻擊者在同一個公共場所（如咖啡館、機場等）或組織內，兩者會使用同一個閘道的NATted IP，都會被識別為同一個合法用戶。
- 使用用戶端指紋，如瀏覽器版本、安裝的瀏覽器擴展、字體名稱等。關於指紋的爭議很多，就像Cookie一樣，它允許跟蹤用戶，但用戶不能拒絕跟蹤。Cookies可以被瀏覽器禁用或拒絕，允許匿名訪問，而指紋則不允許用戶禁用。然而，它仍然是最好和最方便的方法之一，可以在請求中添加獨特的識別背景，以確保這個人是他聲稱的人。
如果MFA仍然適合目的？
無論使用何種認證方式（MFA、SAML、OAUTH、電子身份證、偽亂數產生器等），"傳遞cookie "攻擊仍然具有很大的現實意義，不能因為認證方式的強弱而被挫敗。
身份驗證方法的強弱決定了它在識別該人並防止其他人冒充該人時的準確性。MFA仍然非常相關且適合目標，但與往常一樣，該鏈條與其最薄弱的環節一樣牢固。強大的身份驗證與較弱的令牌實現結合在一起將為惡意行為者提供機會，與強大的身份驗證與較弱的通信實現相結合，將使其容易受到憑據填充和暴力破解的侵害。
令牌中的一些隨機性可以減少攻擊者的機會視窗，但只有用戶端和伺服器之間的額外和持續的識別才會有幫助，這可以通過用戶端證書或瀏覽器識別方法的形式來實現--後者可能沒有證書那麼安全。
原文連結
