【譯】Cookie的SameSite屬性

時間 2019-11-05

原文原文鏈接

17年的文章，是對 CSRF 很好的防護手段
理解了這個屬性也能避免不少開發上的麻煩，例如 iFrame 中的 Cookie 處理

介紹

過去十年，我教個人學生五個 cookie 屬性:「path, domain, expire, HttpOnly, Secure」。可是如今咱們有了一個新屬性 -SameSite。你知道新引入的 SameSite cookie 屬性的細節嗎？一種新的防止跨站點請求僞造（cross site request forgery）的 http 安全特性。該值能夠設置爲 Strict 或 Lax。php

SameSite示例: Set-Cookie: jsessionid=oIZEL75SLnw; HttpOnly; Secure; SameSite=Stricthtml

下面會有 DEMO 演示，請確保您使用 FireFox 或 Chrome 等瀏覽器進行演示、比較結果。使用開發人員工具來觀察網絡堆棧。java

OWASP 的定義

SameSite 阻止瀏覽器將 cookie 與跨站點請求一塊兒發送。主要目標是下降跨來源信息泄露的風險。它還提供了一些針對跨站點請求僞造攻擊的保護。該標誌的可能值爲 Lax 或 Strict。瀏覽器

用例說明

假設您有一個電子銀行網站，而且交易表單容易出現跨站點請求僞造漏洞。假設電子銀行客戶(受害者)已經經過身份驗證(cookie)，攻擊者讓受害者點擊 xsrf 連接，這將在建立非法交易。這種 xsrf 連接能夠經過電子郵件、Twitter、Facebook、公共博客或任何其餘基於超文本標記語言的系統進行傳播。現代安全的電子銀行解決方案可使用隨機 xsrf token 來抵禦這種類型的攻擊。可是爲了這篇文章，讓咱們假設電子銀行是脆弱的，而且不包含這樣一個隨機的xsrf令牌。安全

在 SameSite 以前，通過身份驗證的受害者點擊準備好的 xsrf 頁面，而後進行交易。這是由於瀏覽器具備與電子銀行的會話 cookie，所以會將會話 cookie 添加到電子銀行交易請求中。可是若是瀏覽器不添加會話 cookie 呢？這正是 SameSite 所作的。若是連接來自外部站點，瀏覽器不會將cookie 添加到已經過身份驗證的網站。在 SameSite=Strict 的狀況下，瀏覽器通常不會添加 cookie。若是 SameSite=Lax，則若是用戶單擊頂級網址，瀏覽器將發送 cookie。作下面的演示，瞭解 Strict 和 Lax 的區別。cookie

Demo 頁面

翻了牆也沒法訪問，網站已經壞掉了網絡

爲了 SameSite cookie 屬性，我建立了一個簡短的演示頁面。它由兩個網站組成。第一頁是設置一些 cookies，第二頁是從第一個站點請求一個網址。所以，您如今能夠用 Firefox、Chrome 或者 Safari 測試 cookies 是否被髮送到第一頁。session

Chrome 測試

訪問 demo1 頁面

首先，您須要加載第一個演示頁面，它設置了四個不一樣的 cookies。dom

請檢查 cookies 是否已在 Chrome 中設置。使用「Application」選項卡中的內置開發工具。請看下圖。

Cookie MyBamBut 沒有設置 SameSite 屬性 (過去 10 年前的設置) Cookie MyBamButNone 設置 SameSite=None Cookie MyBamButStrict 設置 SameSite=Strict Cookie MyBamButLax 設置 SameSite=Lax

Chrome 接受了四個 cookies 中的三個。SameSite 設置爲「無」的 cookie 被拒絕。

查看第二個演示頁面的 HTML

如您所見，第二頁有一個頂級網址(href)，並從第一頁的域名加載一個 <img src>。

訪問第二個演示頁面

使用與第 1 步和第 2 步相同的 Chrome 瀏覽器訪問第二個演示頁面。打開開發工具，點擊「Network 」並從新加載頁面。點擊「printheaders.php」，檢查哪些 cookies 是由 Chrome 發送的。分析請求標題。

正如您在上面的圖片中看到的，Chrome 只是添加了沒有設置 SameSite 屬性的 cookie。SameSite=Strict 和 SameSite=Lax 未發送到第一個演示頁面。Cool — 這就是你想要的，一個很酷的 xsrf 防護手段。

訪問第二個演示頁面中的連接

如今讓咱們來看看若是你點擊頂級連接，Chrome 是如何表現的。請點擊第二個演示頁面上的 PrintHeaders 連接，並按照步驟 3 再次分析請求頭。

在下圖中，您能夠看到點擊頂級網址時，第一個演示頁面發送了哪些 Cookies。

Chrome 將 MyBamButLax 添加到第一個演示頁面的 HTTP 請求中。可是 MyBamButStrict 從未被髮送到第一個演示頁面。所以，設置SameSite=Strict 其實是拒絕 xsrf 攻擊。

結論

SameSite cookie 屬性對於防止跨站點請求僞造是一個很大的幫助。若是連接來自與源站點不一樣的地方，該值設置爲「Strict」將阻止(較新的)瀏覽器添加 cookie，這在電子銀行環境中很是酷。
此外，SameSite 屬性還沒有在全部主要瀏覽器版本中實現。截至 2017 年 11 月，相同的站點屬性在 Chrome、Firefox 中實現

補充

原做者還漏了一種場景，在 iFrame 中使用的坑，把以下 b.com 頁面當成 iFrame 嵌入 a.com 頁面

<body>
  <script> // 狀況一：不設置 document.cookie="b-cookie=b;domain=.b.com;path=/" document.cookie="b-cookie1=b1;domain=.b.com;path=/" console.log(document.cookie); // b-cookie=b;b-cookie1=b1; // 狀況二：設置 SameSite document.cookie="b-cookie=b;domain=.b.com;path=/;SameSite=lax" document.cookie="b-cookie1=b1;domain=.b.com;path=/" console.log(document.cookie); // b-cookie1=b1; </script>
</body>
複製代碼

博客引流

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。