據說該sameSite屬性可以保護用戶免受資訊泄露。
但我仍然不完全清楚。例如：
- 一些用戶訪問一些沒有“sameSite 保護”的站點。
- 該網站正在加載，包括位于此處的廣告橫幅。加載此橫幅時，會向廣告站點的服務器發出 HTTP 請求。
幾乎不可能有任何 cookie 被盜。我的意思是，任何 cookie 都有自己的domain屬性path。因此，看起來只有來自位于用戶設備上的廣告站點的 cookie 可以在此 HTTP 請求期間加載。
所以，我的問題是：在另一個站點上收集有關其自己站點的資訊有什么用？我的意思是，這個網站還可以“在家”收集關于自己的統計資料。
uj5u.com熱心網友回復：
這有點誤解，同站cookies的目的不是防止資訊泄露給廣告商。
samesite 屬性緩解的安全問題是 csrf，跨站點請求偽造。
此處不贅述，問題的根本原因是來自瀏覽器的請求（任何請求）默認情況下將包含目標域的 cookie，而不管用戶正在查看的頁面如何。因此，假設您已登錄到您的銀行網站并要轉賬，需要使用適當的引數向 /transfer 發出 post 請求。這些引數不是秘密，所有用戶都將發送相同型別的請求，但在他們自己的會話中。現在，如果您出于某種原因訪問attacker.com，是什么阻止了攻擊者創建一個表單（在一個最幼稚的示例中），當您在attacker.com 上提交時，該表單將發布到您的銀行/transfer 正確的引數，因此攻擊者將收到你的錢？您的銀行會話 cookie 中的會話令牌將被發送，
（您可能會爭辯說，防止這種情況發生的是同源策略，但在這個簡化的示例中沒有，如果涉及 ajax 也不是。）
有多種策略可以通過雙重提交等方式從同步器令牌中緩解這種情況。所有體面的網站都有針對 csrf 的緩解措施。過去幾年出現的另一種策略是同站點屬性。
如果 cookie（通常是應用程式的會話 cookie）被標記為相同站點，如果瀏覽器中的可見源（url）與請求的目標 url 不同，它將不會與請求一起發送。這意味著attacker.com 上的攻擊者站點將無法向您的銀行發帖。（實際上它可以發布，但不會包含同站點會話cookie，因此請求將無效）。
默認情況下，這僅適用于非獲取請求（samesite=lax），但也可以用于獲取請求（samesite=strict），以提高安全性，但代價是用戶體驗更差。
請注意，雖然我將會話 cookie 作為最普遍的示例進行了討論，但這適用于當另一個站點是請求的來源時您在應用程式中不想接收的任何 cookie。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/422463.html
標籤：