問題描述

我正在為基于瀏覽器的 Javascript Web 應用程序構建基于 JWT(JSON Web 令牌)的身份驗證機制，使用無狀態服務器(無用戶會話！)，我想一勞永逸地知道，如果使用將我的 JWT 令牌存儲在 cookie 中將保護我的令牌免受 XSS 攻擊，或者如果沒有保護，那么在我的 Javascript 應用程序中使用瀏覽器本地存儲并沒有真正的優勢.

我在 SO 和許多博客中看到過這個問題的提問和回答，但我從未見過真正讓我滿意的答案.

這個問題最初是基于它征求意見的基礎上提出的 - 并且按照我原來的措辭，正確地如此.因此，讓我在此明確說明，我不希望基于開發人員懶惰等模糊概念發表意見 - 這就是基本規則旨在消除的內容.我想要的是有證據支持的是/否的答案.要么:

• 是的，可以保護 cookie 免受 XSS 和 CSRF 的影響，方法如下" 或
• 不，通過保護您的 cookie 免受 CSRF 的影響，您總是可以將它們打開到與最初使 cookie 成為一個好主意的 XSS 攻擊相同的類型"

所以我要重述這個問題，用一些簡化的基本規則，并提前指出漏洞，以便專家們能夠糾正我.

基本規則

• 您的應用程序是一個 javascript 瀏覽器應用程序 - 它可能在 AngularJS 中，但它可能是定制的.它通過 REST 調用與服務器通信.假設，jQuery $ajax 調用.

• 服務器是無狀態的:沒有會話管理.

• 應用使用 JWT 作為主要身份驗證令牌(OAuth2 用語中的訪問令牌")，并使用秘密簽名密鑰在服務器上驗證它們

• 忽略 cookie 的其他重要優勢:瀏覽器管理、減少編碼不佳的機會等.對于這場戰斗，我想考慮絕對安全性，并假設我們可以勝任任何一種機制的編碼.

• 忽略 cookie 的其他缺點，例如非瀏覽器應用程序等.對于這場戰斗，我們只關心基于瀏覽器的 javascript 應用程序.

• 在非cookie的方式中，使用header還是request body來傳輸token并不重要；如果您使用本地存儲與會話存儲也沒關系 - 忽略那里的任何安全差異.是的，我知道從技術上講 Cookie 使用標頭，請忽略它.

簡而言之，我們只對比較 browser-handles-tokens 與 your-javascript-handles-tokens 以及比較 XSS 和 CSRF 安全風險感興趣.

參賽選手

在紅色角落，Auth0:本地存儲勝過 Cookie，因為 XSS 比 CSRF 更容易修復

在藍色角落，Stormpath:Cookies 勝過標頭，因為實際上 CSRF 比 XSS 更容易修復.

(以下兩個論點的詳細摘錄)

選擇的武器

XSS 和 CSRF(我們將交替使用 CSRF 和 XSRF:C 似乎在文檔中更受歡迎，X 在代碼中更受歡迎)

這是我對攻擊類型的超級簡化總結:

假設您的無狀態、經過 JWT 身份驗證的 javascript 瀏覽器應用程序用于在線銀行業務，而攻擊者Evil Corp"想要提交一個 AJAX REST 調用，通過冒充您的用戶將資金轉移到他們的帳戶.

XSS(跨站腳本)

(正如 Stormpath 指出的那樣，有很多攻擊向量 - 我會選擇一個)

Evil Corp 購買了用于輸入密碼的漂亮文本字段小部件的 github 帳戶權限.他們知道您的銀行網站使用它，因此當您輸入密碼并按 Enter 時，他們會更新它以提交 AJAX 請求以將資金轉移到他們的帳戶.您的構建系統愚蠢地提取更新并投入生產.

CSRF(跨站請求偽造)

Evil Corp 知道您的銀行網站在 cookie 中使用 JWT 來驗證交易，因此他們編寫了一個 Web 應用程序來提交 AJAX 請求以將資金轉移到他們的帳戶.他們將其托管在他們自己的 evil.com 網站上，并在您碰巧在另一個選項卡中登錄您的銀行網站時，通過電子郵件(網絡釣魚)或其他方式引誘您到那里.瀏覽器從 evil.com 提交請求，但附加了您的 JWT，因為它會轉到正確的站點:銀行.

標準防御

對 XSS 的防御是要非常小心您網站中的代碼，這樣您就永遠不會讓瀏覽器處理用戶輸入的內容而不對其進行清理(刪除 javascript 和 html)以及所有 3rd 方庫(Evil 的文本字段小部件)在使用前經過審查.正如 Stormpath 正確指出的那樣，這很難，幾乎是不可能的.

針對 CSRF 的防御是使用一種雙重提交 cookie 的形式.這意味著我們的服務器會創建一個令牌(安全的隨機字符串)并將其以可讀 cookie 的形式發送到我們的 Javascript 瀏覽器應用程序(按照慣例稱為XSRF-TOKEN")，然后我們的 Javascript 將其以標題或正文的形式發送回每個請求.

實際上，double-sumbit-cookie 只是對抗 CSRF 的一種防御，但其他一些需要有狀態的服務器會話，并且沒有其他(我認為！)提供更好的保護.也可以通過將令牌放入 JWT 并在服務器端將其與標頭或正文中的令牌進行比較來實現無狀態.

但這種防御的真正破壞 CSRF 的質量是同源策略意味著只有我們的應用從 我們的域 加載的 javascript 才能讀取該 cookie.因此，即使 evilcorp.com 上的 javascript 可以將我們的 cookie 連同其請求一起發送，它也無法嵌入我們的 XSRF-TOKEN，因為它一開始就無法讀取它地點.

真的簡化 CSRF:

• CSRF attacks 起作用，因為附加 cookie 的瀏覽器僅依賴于請求的 destination.
• CSRF defences 起作用，因為 Javascript 對 cookie 的訪問取決于 Javascript 的 origin.

Auth0 的論據

處理 XSS 比 XSRF 更容易 Cookie 具有以下功能:允許從服務器端設置一個 HttpOnly 標志，因此它們只能是在服務器上訪問，而不是從 JavaScript 訪問.這很有用，因為它保護該 cookie 的內容以通過注入訪問客戶端代碼 (XSS).由于令牌存儲在本地/會話中存儲或客戶端 cookie，它們容易受到 XSS 攻擊讓攻擊者訪問令牌.這是一個合理的擔憂，并且出于這個原因，你應該保持你的令牌過期時間低.

但是如果你想想 cookie 的攻擊面，主要的攻擊面之一是XSRF.現實情況是 XSRF 是最容易被誤解的一種攻擊和普通開發人員可能甚至不了解風險，因此許多應用程序缺乏抗 XSRF 機制.然而，每個人都知道注射是什么.簡單地說，如果你允許在您的網站上輸入，然后在不轉義的情況下呈現它，您對 XSS 開放.所以根據我們的經驗，更容易保護防御 XSS 而不是防御 XSRF.除此之外，anti-XSRF 是不是每個 Web 框架都內置的.另一方面，XSS 很容易通過使用大多數默認情況下可用的轉義語法來防止模板引擎.https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies#xss-xsrf

Stormpath 的論點

Stormpath 建議您將 JWT 存儲在網絡 cookie 中應用程序，因為它們提供了額外的安全性，并且使用現代 Web 框架防止 CSRF 的簡單性.HTML5 Web Storage 易受 XSS 攻擊，攻擊面較大區域，并且可以在成功攻擊時影響所有應用程序用戶.https://stormpath.com/博客/where-to-store-your-jwts-cookies-vs-html5-web-storage/

還有:

我看到很多關于 cookie 反對訪問的討論令牌.雖然我們都被存儲會話 ID 的系統所困擾在 cookie 中，該 cookie 不安全，因此被盜.那很爛，但這不是使用令牌的理由.這是一個避免的理由非安全、非 https cookie.https://stormpath.com/blog/token-auth-spa/p>

我的看法

Stormpath 支持 cookie 的論點非常有說服力，但其中有一個漏洞，我認為他們沒有清楚地解決:

雙重提交 CSRF 防御依賴于我的 CSRF 攻擊者無法訪問我的 cookie 的事實:其中包含 XSRF-TOKEN 的那個.但是，在 XSS 攻擊中，該 cookie 是否與本地存儲一樣容易受到攻擊?

XSS 漏洞利用可以在 my 域上運行 javascript，因此它可以讀取我的 javascript 可以讀取的相同 cookie.(瀏覽器不知道它不是我的Javascript)

從另一方面來看:本地存儲受到同源策略的保護，就像可讀的 cookie 一樣.如果我使用 Auth0 方法，并且 XSS 攻擊者知道如何在本地存儲中找到我的 JWT 并使用它.難道同一個攻擊者不能使用同一個 XSS 腳本來獲取我的 XSRF-TOKEN cookie 并使用它嗎?

這兩種攻擊都要求他們閱讀和理解我的 javascript 應用程序，但這在他們的瀏覽器中.

那么有什么區別呢?一個真的比另一個更安全嗎?為什么?

放棄所有希望，除非你能抵御 XSS！

或者

根據其他標準選擇適合您的方法，因為兩者同樣安全，同樣不安全.

如果您使用 cookie，則絕對應該使用雙重提交 cookie 防御或類似的東西，因為它確實可以保護您在沒有 XSS 的情況下免受 CSRF 的影響.也就是說，如果你不這樣做，你肯定會受到來自其他域的 CSRF 攻擊，這些攻擊甚至不需要 XSS 漏洞利用即可工作.

但無論哪種方式，您的源代碼都是公開可用的(瀏覽器中的 JavaScript)，因此對于有動機的黑客來說，從本地存儲中找到要提取的令牌與讀取 XSRF-TOKEN cookie 之間的努力沒有顯著差異.如果 Evil Corp 可以讓一些 JavaScript 在你的域中運行——那就是 XSS——那么你就完蛋了.

您在選擇時可能要考慮的非安全相關標準:

• Cookie 很方便，因為您不必編寫 JavaScript 代碼來管理令牌 - 只需 XSRF.

• 如果你想使用它，重定向也會變得更加自動.

• 本地存儲更容易適應非瀏覽器應用程序 - 從服務器的角度來看，因為如果你用 Java 編寫一個不想處理 cookie 的 Android 應用程序，你的服務器不會不需要區分 in 和瀏覽器，因為它不使用 cookie.

無論如何，請自行決定，但請注意您編寫的 JavaScript和您使用的第 3 方 JavaScript！

I'm building a JWT-based (JSON Web Token) authentication mechanism for an browser-based Javascript web app, working with a stateless server (no user-sessions!) and I want to know, once and for all, if using storing my JWT token in a cookie will protect my token from XSS attacks, or if there is no protection, so there's no real advantage over using browser local storage in my Javascript app.

I have seen this question asked and answered in SO and in many blogs, but I've never seen an answer that really satisfies me.

This question was originally held on the basis that it solicits opinion - and given my original wording, rightly so. So let me make it clear here and now that I don't want an opinion based on vague notions of developer laziness or such - that's what the ground rules are meant to eliminate. What I want is an evidence-backed Yes/No answer. Either:

• "Yes, cookies can be protected from XSS and CSRF and here's how" or
• "No, by protecting your cookies from CSRF, you always open them up to the same kind of XSS attack that made cookies a good idea in the first place"

So I'm going to restate the question, with some simplifying ground-rules, and point out the holes in advance, so that you, the experts, can set me straight.

Ground rules

• Your app is a javascript browser app - it might be in AngularJS, but it might be custom-built. It communicates with the server via REST calls. Let's say, jQuery $ajax calls.

• The server is stateless: there is no session management.

• The app users JWTs as the main authentication token ('access token' in OAuth2 parlance) and validates them on the server using a secret signing key

• Ignore other important advantages of cookies: browser management, less chance of coding poorly, etc. For this battle, I want to consider the absolute security, and assume we can competently code either mechanism.

• Ignore other disadvantages of cookies, such as non-browser apps, etc. For this battle we are only concerned with a browser-based javascript app.

• It doesn't matter whether you use a header or a request body to transmit tokens in the non-cookie approach; nor does it matter if you're using local storage vs session storage - ignore any security differences there. And yes I know that technically Cookies use headers, ignore that.

In a nutshell, we're only interested in comparing browser-handles-tokens vs your-javascript-handles-tokens and the comparative XSS and CSRF security risks.

The contestants

In the red corner, Auth0: Local Storage beats Cookies, because XSS is easier to fix than CSRF

In the blue corner, Stormpath: Cookies beats headers, because actually CSRF is easier to fix than XSS.

(excerpts of both arguments in detail below)

Weapons of choice

XSS and CSRF (we'll use CSRF and XSRF interchangeably: the C seems to be more popular in documentation, the X in code)

Here's my super-simplified summary of the attack types:

Let's assume your stateless, JWT-authenticated, javascript browser app is for online banking and the attacker, "Evil Corp", wants to submit an AJAX REST call that transfers funds to their account by impersonating your users.

XSS (Cross-site scripting)

(As Stormpath points out, there are many attack vectors - I'll pick one)

Evil Corp buys the github account rights for the nifty text field widget you use for password entry. They know your bank site uses it, so they update it to submit AJAX requests to transfer funds to their account when you type in your passord and hit enter. Your build system foolishly pulls the update and puts in production.

CSRF (Cross-Site Request Forgery)

Evil Corp knows your bank site uses JWTs in cookies to authenticate transactions, so they write a web app that submits AJAX requests to transfer funds to their account. They host this on their own evil.com site, and lure you there with an email (phishing) or some other way, when you happen to be logged into your bank site in another tab. The browser submits the request from evil.com, but attaches your JWT becaues it's going to the correct site: the bank.

Standard defences

The defence against XSS is to be very careful about the code in your site so that you never let the browser process something the user types in without sanitizing it (removing javascript and html) and that all the 3rd party libraries (Evil's text field widget) are vetted before being used. As Stormpath rightly points out, this is hard, bordering on impossible.

The defence against CSRF is to use a form of double-submit-cookie. This means our server creates a token (securely random string) and sends it to our Javascript browser app in a readable cookie (call it "XSRF-TOKEN" by convention), and our Javascript sends it back in a header or body with every request.

Actually, double-sumbit-cookie's are only one defence agasint CSRF, but some others require stateful server sessions and no other (I think!) offers any better protection. The statelessness can be achieved by also putting the token in the JWT and comparing it on the server side with the one that comes in the header or body.

But the real CSRF-busting quality of this defence, is that same-origin-policy mean that only the javascript that our app loaded from our domain can read that cookie. So even if the javascript on evilcorp.com can send our cookies with its requests, it can't embed our XSRF-TOKEN because it can't read it in the first place.

To really simplify CSRF:

• CSRF attacks work because a browser attaching a cookie depends only on the destination of a request.
• CSRF defences work because Javascript access to a cookie depends on the origin of the Javascript.

Auth0's argument

It's easier to deal with XSS than XSRF Cookies have this feature that allows setting an?HttpOnly?flag from server side so they can only be accessed on the server and not from JavaScript. This is useful because it protects the content of that cookie to be accessed by injected client-side code (XSS). Since tokens are stored in local/session storage or a client side cookie, they are open to an XSS attack getting the attacker access to the token. This is a valid concern, and for that reason you should keep your tokens expiration low.

But if you think about the attack surface on cookies, one of the main ones is XSRF. The reality is that XSRF is one of the most misunderstood attacks, and the average developer, might not even understand the risk, so lots of applications lack anti-XSRF mechanism. However, everybody understands what injection is. Put simply, if you allow input on your website and then render that without escaping it, you are open to XSS. So based on our experience, it is easier to protect against XSS than protecting against XSRF. Adding to that, anti-XSRF is not built-in on every web framework. XSS on the other hand is easy to prevent by using the escape syntax available by default on most template engines. https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies#xss-xsrf

Stormpath's argument

Stormpath recommends that you store your JWT in cookies for web applications, because of the additional security they provide, and the simplicity of protecting against CSRF with modern web frameworks. HTML5 Web Storage is vulnerable to XSS, has a larger attack surface area, and can impact all application users on a successful attack. https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

Also:

I see a lot of discussions where cookies are pitted against access tokens. While we’ve all been burned by systems that store a session ID in a cookie, and that cookie is not secured and thus gets stolen. That sucks, but its not a reason to use tokens. Its a reason to avoid non-secure, non-https cookies. https://stormpath.com/blog/token-auth-spa/

My take

Stormpath's argument in favour of cookies is pretty convincing, but there's a hole in it that I don't see them addressing clearly:

The double-submit CSRF defence relies on the fact that my CSRF attacker cannot access my cookie: the one with the XSRF-TOKEN in it. But isn't that cookie just as vulnerable in an XSS attack as local storage?

An XSS exploit can run javascript on my domain, so it can read the same cookies my javascript can. (The browser doesn't know that it isn't my Javascript)

To look at it from the other side: local storage is protected by the same-origin-policy just as much as a readable cookie. If I'm using the Auth0 approach, and an XSS attacker knows how to find my JWT in local storage and use it. Can't that same attacker use that same XSS script to grab my XSRF-TOKEN cookie and use that?

Both attacks require them to read and understand my javascript app, but that's out there in their browser.

So what's the difference? Is one really more secure than another, and why?

Abandon all hope unless you can secure against XSS!

Or

Choose the approach that suits you based on other criteria because both are equally secure, equally insecure.

If you use cookies, you should definitely use the double-submit-cookie defence, or something similar, because it does protect you against CSRF in the absence of XSS. That is, if you don't do this, you're definitely open to CSRF attacks - from other domains - that don't even require XSS exploits to work.

But either way, your source code is publicly available (JavaScript in your browser) so for a motivated hacker, there is no significant difference in effort between finding which token to pull from local storage and reading your XSRF-TOKEN cookie. If Evil Corp can get some JavaScript running in your domain - that's XSS - then you're hosed.

Non-security-related criteria you might want to consider for your choice:

• Cookies are convenient because you don't have to write JavaScript code to manage the token - only the XSRF.

• Redirection becomes a little more automatic too, if you want to use it.

• Local storage is easier to adapt to non-browser apps - from the server perspective that is, because if you write say, an Android app in Java that doesn't want to deal with cookies, your server doesn't need to make any distinction between in and the browser, since it's not using cookies.

Anyway, make up your own mind, but be careful about the JavaScript you write and the 3rd party JavaScript you use!

這篇關于cookie 是否保護令牌免受 XSS 攻擊?的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！