Chrome默認對Cookie添加SameSite,對安全和業務有什麼影響?

2021-02-15 焦點安全應急響應中心
FSRC經驗分享系列介紹

新年新氣象,我們會在FSRC公眾號發出焦點科技信息安全部工作過程中總結的經驗。分享內容不僅是漏洞分析,也包括運營、sdl、等保、自研工具等。只要與安全相關,我們都會整理並分享給大家,歡迎各位安全從業者關注。

Chrome 51 開始,瀏覽器的 Cookie 新增加了一個SameSite屬性,用來防止 CSRF 攻擊和用戶追蹤。

未來Chrome瀏覽器會默認為Cookie添加SameSite屬性,在跨站請求的情況下不允許跨站攜帶Cookie給後端,導致所有跨站場景下使用Cookie進行鑑權的服務會受到影響。

本文分析了一旦該屬性默認對所有升級到相應版本的用戶生效,可能對安全和業務產生的影響。

閱讀本文,你可以獲取如下信息:

SameSite的目的就是為了防止CSRF攻擊,在此稍微介紹下CSRF攻擊步驟便於理解:

1.假設有個bank.com的銀行轉帳接口

POST /tans_money

Host: bank.com

cookie: secret=1ead41da1;

 

money={金額}&receiver={收款人}

攻擊者hack擁有一個域名hack.com,並構造hack.com/csrf.html,包含如下內容

<html>

...

<form action="https://bank.com/tans_money">

<input name="money" value="1000">

<input name="receiver" value="mkdd">

</form>

 

<script>document.forms[0].submit();</script>

...

</html>

此時如果受害者已經登錄了bank.com,然後被誘騙訪問了https://hack.com/csrf.html,就會附帶著Cookie發起一個給hack轉帳1000元的請求。

POST /tans_money

Host: balabalabank.com

cookie: secret=1ead41da1;

 

money=1000&receiver=mkdd

上面假設的案例便是一個典型的CSRF漏洞,利用方式是構造表單,將action值設置為存在漏洞的接口,然後誘導受害者訪問被植入表單的網頁,偷偷發起非受害者意願的請求。CSRF漏洞可用的構造方式如下:

表1 構造CSRF的方式

form標籤的action屬性GET/POST請求AJAXGET/POST請求img標籤的src屬性GET請求iframe標籤的src屬性GET請求a標籤的href屬性GET請求link標籤的href屬性GET請求
簡單來說,SameSite是Cookie的一個屬性,用於限制網站通過上表的方式引入跨站請求時Cookie被附帶的行為,進而避免用戶遭受CSRF攻擊。

SameSite的值可以設置為3種:

其中Strict最為嚴格,如果設置為Strict,上表的方式均無法附帶Cookie。Lax稍微寬鬆點,設置為Lax,會限制部分請求。當設置為None的時候表示關閉不啟用SameSite防護。3個可選值的影響羅列如下:

表2 SameSite值對請求方式的反饋

form標籤的action屬性,method為GET時不發送Cookie發送Cookie發送Cookieform標籤的action屬性,method為POST時不發送Cookie不發送Cookie發送CookieAJAX不發送Cookie不發送Cookie發送Cookieimg標籤的src屬性不發送Cookie不發送Cookie發送Cookieiframe標籤的src屬性不發送Cookie不發送Cookie發送Cookiea標籤的href屬性不發送Cookie發送Cookie發送Cookielink標籤的href屬性不發送Cookie發送Cookie發送Cookie
動手體驗下SameSite的效果,任意一個可訪問網站均可以,這裡使用焦點科技官網(https://www.focuschina.com/)1. 創建testss.html文件,內容如下

<html>

<img src="https://www.focuschina.com/_img">

</html>

2. 將testss.html放在web目錄中

本文中我把它放在localhost/testss.html下

3.瀏覽器訪問https://www.focuschina.com/ 

使用控制臺設置一個Cookie,name=mkdd,後續我們只關注這個Cookie

4. 訪問localhost/testss.html,可以看到正常通過img標籤正常攜帶了這個Cookie

5. 為name=mkdd這個Cookie設置一個Strict

6. 訪問localhost/testss.html,發現此時已經不攜帶name=mkdd這個Cookie了


7. 測試img標籤對應Lax的效果

把name=mkdd的SameSite值設置為Lax,對於img標籤也不會附帶Cookie,符合表2的情況

8.繼續測試GET型表單對應Lax效果

把name=mkdd的SameSite值設置為Lax(document.cookie="name=mkdd;SameSite=Lax;"),然後修改localhost/testss.html為如下內容

<html>

<form action="https://www.focuschina.com/_form" method="GET">

<input name="oobs" value="oobs">

</form>

<script>document.forms[0].submit()</script>

</html>

9. 訪問localhost/testss.html,發現已經攜帶了Cookie,符合表2中GET請求+Lax值為發送Cookie的情景

本文中提到的相關資源已在網絡公布,僅供研究學習使用,請遵守《網絡安全法》等相關法律法規。

chrome文檔:

https://www.chromium.org/updates/same-site

Cookie 的 SameSite 屬性(阮一峰):

http://www.ruanyifeng.com/blog/2019/09/cookie-samesite.html

FSRC,願與你共同成長焦點科技漏洞提交網址:https://security.focuschina.com

相關焦點

  • Google Chrome Samesite cookie 新策略帶來跨域問題解決
    自Chrome 80開始,谷歌對用戶實施了新的cookie政策,該政策添加了對Samesite的IETF標準的支持,並且默認將cookie的samesite級別設置為lax,這種的策略阻止了開發者對第三方cookie操作,對很多涉及到跨域的系統造成了巨大的影響。什麼是cookie的samesite屬性?
  • 星期五實驗室 | Cookie SameSite食用指南
    隨著Web安全的發展需要,瀏覽器端已經開始針對Cookie進一步防禦,而SameSite屬性正是這場防禦進化的焦點。Samesite屬性於2016年由IETF正式發布,現今出於網站穩定性的考量(理同廢除Flash),大部分瀏覽器採用支持但默認不開啟狀態(SameSite=None),但該屬性一定會隨時間緩步推進普及,並最終適用於主流瀏覽器內。
  • [譯] 理解 Cookie 的 SameSite 屬性
    添加 Cookie 的方式就是給 document.cookie 賦值。這使得 Lax 成為影響網站顯示的不錯選擇,而 Strict 則在發生與用戶相關的操作時比較有用。小心:Strict 和 Lax 都不是網站安全的完整解決方案。Cookie 是作為用戶請求的一部分發送的,你應該將它與用戶輸入一樣對待。這表示需要對輸入執行消毒(sanitizing)和驗證。
  • 為 SameSite Cookie 設置做好準備 | Google Web 變更
    https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html為新的 SameSite=None; Secure Cookie 設置做好準備去年 5 月,Chrome 宣布推出 Cookie 的默認安全模型,採用新的 Cookie 分類系統 (規範)。
  • Chrome瀏覽器設置same-site-by-default-cookies
    以下為更新內容:即 Chrome80+穩定版推出後,開始強制執行全新的默認安全 Cookie 分類系統,並將未聲明 SameSite 值的 Cookie 默認設置為SameSite=LaxTreat cookies that don't specify a SameSite attribute as if they were SameSite=
  • 【Supporter 說】如何應對 Google Chrome SameSite cookie 的變更
    目前為止,所有瀏覽器都設有隱含默認值 SameSite=None,即對跨域 cookies 不施加限制。Google 已於2020年2月17日起在 Chrome 版本80以上激活更嚴格的 cookie 處理。
  • Citrix ADC對HTTP Cookie實施安全保護
    SameSite"屬性通過限制Cookie在同站點上下文中的使用,有助於保護應用程式免受CSRF攻擊。Web應用程式通常使用HTTP Cookie來驗證用戶身份和跟蹤用戶活動。如果您的基於HTTP的應用程式使用Cookie,並且從未在跨站點上下文中進行訪問,那麼保護Cookie免受跨站點濫用至關重要。
  • 當SameSite屬性為默認值Lax時,繞過它並獲得一個CSRF
    但首先讓我們看看它到底是什麼。SameSite 是一個 cookie 屬性,可以告訴瀏覽器應該何時在跨源請求中發送特定的 cookie,它的值有 3 種類型:● SameSite None 將在所有跨源請求中發送 cookie,將被視為普通(舊)Cookie 。
  • SameSaite 那些事
    但是並不是完全的不等判斷,可以理解是否有 SSL 的區別。例如 http:// 和 https:// 跨站,但 wss:// 和 https:// 則是同站,ws:// 和 http:/ 也算是同站。Chrome 可以瀏覽器輸入 chrome://flags/#schemeful-same-site 找到配置並開啟。
  • Chrome瀏覽器設置升級後無法設置flags解決方法same-site-by-default-cookies
    以下為更新內容:即 Chrome80+穩定版推出後,開始強制執行全新的默認安全 Cookie 分類系統,並將未聲明 SameSite 值的 Cookie 默認設置為SameSite=LaxTreat cookies that don't specify a SameSite attribute as if they were SameSite=
  • 瀏覽器專題系列 —— 本地存儲:cookie,localStorage,sessionStorage,indexDB
    cookieHTTPOnly安全標誌不允許使用腳本去更改/獲取這個cookieSameSite安全標誌控制跨站請求獲取cookie✨屬性補充說明Expires:其值為默認session,即關閉瀏覽器時此cookie就過期失效Domain:指定了 Cookie 可以送達的主機名沒有指定:默認值為當前文檔訪問地址中的主機部分
  • Chrome Canary 可刪除所有第三方 cookie
    來源:OSCHINA 社區 [http://www.oschina.net]Google Chrome默認情況下會阻止跟蹤Cookie,現在更進一步,最新的Canary版本允許通過Chrome://settings/siteData頁面上的選項刪除所有第三方Cookie和網站數據。
  • 面試不再怕:史上最全的cookie知識點詳解
    cookie一般是被瀏覽器以txt的形式存儲在電腦硬碟中,供該瀏覽器進行讀、寫操作。2. cookie是如何工作的?當瀏覽器發起一個請求時,瀏覽器會自動檢查是否有相應的cookie,如果有則將cookie添加到Request Headers的Cookie欄位中(cookie欄位是很多name=value以分號分隔的字符串)。
  • chrome禁止三方cookie,網站登錄不了怎麼辦
    (80+)瀏覽器默認屏蔽所有三方cookie已經不是什麼新聞了,具體原因這裡不去深究,有大量相關文章介紹,由於目前許多網站都依賴三方cookie,因此該特性的推出還是造成了一些的影響,比如收集用戶信息的廣告商,而且主流的瀏覽器都跟進chrome的策略,已經成為了既定事實,本篇文章主要聚焦於各種解決方案,大家可以針對自身情況採用不同的解決辦法。
  • 小cookie,大智慧
    yummy_cookie=chocoSet-Cookie: X-BAT-FullTicketId=TGT-969171-******; path=/; samesite=none; httponly[page content]Cookie標頭的內容是鍵值對(鍵值對才是具業務含義的
  • 提取Chrome中Cookie工具分享
    SharpCookieMonster.exe [https://sitename.com] [chrome-debugging-port] [user data dir]可選的第一個參數分隔chrome啟動時最初連接的網站(默認為https://www.google.com)。
  • 黑客大神分享:提取Chrome中Cookie
    SharpCookieMonster.exe [https://sitename.com] [chrome-debugging-port] [user data dir]可選的第一個參數分隔chrome啟動時最初連接的網站(默認為https://www.google.com)。第二個可選參數指定用於啟動chrome調試器的埠(默認為9142)。
  • Web安全之如何防止cookie被竊取?
    在TOP 10名單中,跨站腳本攻擊(XSS)和跨站請求偽造(CSRF)是常客,攻擊者發起XSS和CSRF攻擊的重要前提是竊取到保存在瀏覽器客戶端的cookie信息。那麼,cookie信息是什麼?為什麼它在web攻擊中有重要的作用?且聽小編細細道來。
  • cross-site, cross-origin傻傻分不清
    透過現象看本質,旁邊業務還在催問什麼時候能恢復,只能硬著頭皮一步步分析著看。限制訪問Cookie通過以下方式可以確保Cookie被安全發送,不會被意外的參與者或腳本訪問:Secure屬性:標記為Secure的Cookie只能通過被HTTPS協議加密過的請求發送給服務端,可以藉此來預防中間人攻擊從 Chrome 52 和 Firefox 52 開始,不安全的站點(http:)無法使用Cookie
  • 記一次 Chrome 更新帶來的登錄 Cookie 問題
    如何寫更安全的代碼?作為程序開發人員,我們害怕,聽到開發的代碼,被測試出 bug;我們更害怕,聽到我們所開發出來的產品上線了,被新手安全研究員給反彙編逆向破解,代碼功能直接被人給盜取了。下面根據我自己的一些項目經驗,跟大家分享兩點如何能開發出相對安全的代碼。