![背景圖片來源/<a href="https://unsplash.com/@sandrokatalina?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Sandro Katalina</a> on <a href="https://unsplash.com/photos/purple-and-black-pyramid-wallpaper-k1bO_VTiZSs?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>](https://s4.itho.me/sites/default/files/styles/picture_size_large/public/field/image/0913-chrome-back-photo_by_sandro_katalina_on_unsplash-960_0.jpg?itok=kYNQA3rw)
背景圖片來源/Sandro Katalina on Unsplash
Google現在於Chrome Beta版本測試一個稱為DBSC(Device Bound Session Credentials)的功能,藉由在工作階段(Session)以及裝置上綁定金鑰,使得即便使用者的身分驗證Cookie遭竊,攻擊者也無法在遠端濫用這些Cookie登入使用者帳戶,保護Google帳戶使用者不受Cookie劫持攻擊。
網站會透過建立Cookie來保存使用者的瀏覽資訊,使得網站可以執行諸如保持登入,和記憶偏好設定等功能,以提供使用者良好的體驗,但因為Cookie具有強大的實用性,也就容易受到攻擊。
攻擊者會透過各種手段傳播Cookie竊取惡意軟體,這類軟體可以從受害者裝置上的瀏覽器,擷取出身分驗證Cookie,並將其轉移到遠端伺服器中,使得攻擊者能夠濫用甚至銷售遭入侵的帳戶。而由於這種竊取行為發生在用戶登入之後,因此攻擊者也就能夠繞過雙因素驗證或是任何登入時的檢查,而且即便惡意軟體被偵測並移除之後,遭竊的Cookie仍然可以繼續使用,因此防毒軟體對於緩解這個問題的能力有限。
Google還指出,由於Cookie與作業系統的互動方式,特別是在桌面作業系統,Chrome與其他瀏覽器,皆無法保護Cookie不受與瀏覽器具有相同存取權限的惡意軟體入侵。也就是當惡意軟體獲得了與瀏覽器相同的系統權限,便可以自由地存取瀏覽器儲存的Cookie,就算瀏覽器本身擁有諸多安全功能,也無法阻擋擁有相同甚至更高系統權限的惡意軟體存取Cookie。
為了解決這個問題Google設計了DBSC新網頁功能,DBSC會將身分驗證工作階段(Session)綁定到裝置上,使得洩漏的Cookie不再具有價值,攻擊者要使用該憑證,便會需要在本地裝置上操作,而這便會使裝置上的偵測和清除手段更為有效。
簡單來說,當網站試圖在用戶裝置上起始一個新工作階段,瀏覽器便會在本地創建一對公鑰與私鑰,公鑰可安全地與網站共享,而私鑰則會儲存在裝置上,使用受信任平臺模組(TPM)硬體或是軟體隔離等難以匯出的方式進行保護。
透過將用戶工作階段與公鑰進行關聯,便可以強化目前的Cookie功能,而且網站伺服器也可以透過在工作階段期間驗證私鑰所有權(Key Possession),確保操作來自於使用者的裝置。每個工作階段都擁有獨特的金鑰,DBSC不允許網站跨不同工作階段,在同一裝置上關聯金鑰,確保網站無法藉由DBSC追蹤用戶,並且讓用戶可以隨時刪除金鑰。
除了瀏覽器會向伺服器表明有能力使用的安全儲存類型之外,DBSC不會洩漏其他具體的裝置資訊,而DBSC發送給伺服器的唯一資訊是每個工作階段的公鑰,供伺服器在稍候作為驗證私鑰所有權之用。
Google最初會視用戶的硬體能力,先對約一半的Chrome桌面使用者啟用DBSC,不過DBSC的開發規範,承諾不會被用來對用戶分群,因此未來可能對所有用戶支援軟體金鑰方法。Google還提到,DBSC會配合Chrome中第三方Cookie的汰除計畫,確保在禁用第三方Cookie之後,DBSC不會成為新的追蹤向量。
Google的目標是建立一個實用的技術解決方案,供網站維護者可以簡單地部署,促進DBSC受到廣泛採用最終成為開放網路標準。目前DBSC專案已經在GitHub上開源。
熱門新聞
2024-08-28
2024-08-26
2024-08-30
2024-08-26
2024-08-27
2024-08-24