CSRF （跨站點(diǎn)請求偽造）問題的示例分析

今天就跟大家聊聊有關(guān) CSRF （跨站點(diǎn)請求偽造）問題的示例分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

SameSite Cookies

要了解CSRF的問題以及SameSite Cookies提供的解決方案，您應(yīng)該首先閱讀我的原始博客 Cross-Site Request Forgery已經(jīng)死了！。如果您想了解有關(guān)cookie保護(hù)的更多詳細(xì)信息，您還應(yīng)閱讀Tough Cookies。您應(yīng)該采取強(qiáng)有力的保護(hù)措施來保護(hù)您的用戶/訪問者，所以必須開啟 SameSite cookie，不過它是可選特性。在實際的環(huán)境中，您可以通過在 cookie 中添加SameSite=Lax來啟用SameSite ，就像Secure或HttpOnly標(biāo)記一樣。

如下所示：

Set-Cookie: __Host-session=123; path=/; Secure; HttpOnly; SameSite=Lax

可實際情況并沒有多少網(wǎng)站將SameSite=Lax標(biāo)志添加到他們的cookie中。

默認(rèn)啟用 SameSite

當(dāng) SameSite 首次問世時，沒有人想讓它成為默認(rèn)設(shè)置。因為它會破壞原有事物，改變預(yù)期（遺留）功能，這會導(dǎo)致開發(fā)人員對此有所顧慮。所以 SameSite 設(shè)置是一個可選項，但這種情況正在發(fā)生變化。

上圖中的 Mike 在 Chrome 上工作。我很高興看到他提到的 SameSite 將作為 cookie 的默認(rèn)設(shè)置啟用。你可以檢查 Chrome 平臺的 默認(rèn)設(shè)置SameSite = Lax，并且你將可以在 Chrome 76（已經(jīng)發(fā)布）以及后面的版本看到這一點(diǎn)，并且將很快登陸Chrome 78（很快）。默認(rèn)情況下，網(wǎng)站運(yùn)營商無需為SameSite提供強(qiáng)大的保護(hù)，但他們可能希望現(xiàn)在使用了 Chrome 這一測試特性后，一切仍然按預(yù)期工作：chrome://flags/#same-site-by-default-cookie

更安全

如上面的鏈接所述，如果需要或想要，網(wǎng)站可以選擇退出SameSite保護(hù)。為此，網(wǎng)站可以設(shè)置SameSite=None其Cookie，Chrome會尊重設(shè)置，但有一項要求。cookie 必須設(shè)置Secure標(biāo)志！您可以跟蹤 Chrome 的 Reject insecure SameSite=None cookies 狀態(tài)，但它可以在 Chrome 76（現(xiàn)在）中顯示，并且看起來將在今年晚些時候登陸Chrome 80。這里面的邏輯是有道理的，其目的是保護(hù)跨網(wǎng)站請求中發(fā)送的cookie，這些cookie可以在網(wǎng)絡(luò)上跟蹤和查看，而不是通過HTTP等不安全的通道發(fā)送。同樣，網(wǎng)站運(yùn)營商可以使用該標(biāo)志測試是否會產(chǎn)生任何影響：chrome://flags/#cookies-without-same-site-must-be-secure

看完上述內(nèi)容，你們對 CSRF （跨站點(diǎn)請求偽造）問題的示例分析有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。