javascript 如何使用同步器令牌模式来防止 CSRF 安全？

How is using Synchronizer Token Pattern to prevent CSRF safe?

提问by Juliet

I have been reading about using a synchronizer token pattern to prevent CSRF (CSRF meaning Cross-site request forgery.), and I don't understand how it actually safe.

我一直在阅读有关使用同步器令牌模式来防止 CSRF（CSRF 表示跨站点请求伪造）的信息，但我不明白它实际上是如何安全的。

Let's say I have a fake bank site fakebank.com with two urls:

假设我有一个带有两个网址的假银行网站 fakebank.com：

• fakebank.com/withdrawForm.html- a GET request which displays the withdraw money form
• fakebank.com/doWithdraw- POST to this url to do the withdraw

• fakebank.com/withdrawForm.html- 显示提款表格的 GET 请求
• fakebank.com/doWithdraw- 发布到此网址以进行撤回

My understanding of the security flaw is that maliciousSite.comcan spoof a POST request to fakebank.com/doWithdraw, and if you're currently logged in to fakebank, the POST will be successful.

我对安全漏洞的理解是，maliciousSite.com可以将 POST 请求欺骗到fakebank.com/doWithdraw，如果您当前登录到 fakebank，则 POST 将成功。

Let's say we implement a Synchronizer Token Pattern which will embed a secret code on fakebank.com/withdrawForm.html. Can't maliciousSite.comjust spoof a GET request for that form, parse the html result, get the token, and then create the POST request with that token?

假设我们实现了一个同步器令牌模式，它将在fakebank.com/withdrawForm.html. 不能maliciousSite.com只是欺骗该表单的 GET 请求，解析 html 结果，获取令牌，然后使用该令牌创建 POST 请求吗？

This is assuming fakebank.com isn't checking HTTP Referrer or Origin or maliciousSite.comis successfully spoofing that the Referrer/Origin is fakebank.com.

这是假设 fakebank.com 没有检查 HTTP Referrer 或 Origin，或者maliciousSite.com成功欺骗 Referrer/Origin 是 fakebank.com。

采纳答案by Freedom_Ben

The reason why this is secure, and maliciousSite.comcannot simply do a GET, steal the token, and then do a POSTis that the request is done by the user's browser, not by the server at maliciousSite.com. All data returned from fakebank.comis returned to the user's browser, not to the server at maliciousSite.com. If maliciousSite.comdoes perform a GET to retrieve a token, it will be a different token than was issued to the user. maliciousSite.comcannot set this cookie into the user's browser to be submitted to fakebank.combecause of same-domain restrictions.

之所以这样做是安全的，maliciousSite.com不能简单地做一个GET，窃取令牌，然后再做一个，POST是因为请求是由用户的浏览器完成的，而不是由位于 的服务器完成的maliciousSite.com。从fakebank.com返回的所有数据都返回到用户的浏览器，而不是返回到 的服务器maliciousSite.com。如果maliciousSite.com确实执行 GET 来检索令牌，它将是与颁发给用户的令牌不同的令牌。 由于同域限制，maliciousSite.com无法将此 cookie 设置到用户的浏览器中以进行提交fakebank.com。

The CSRF POSTattack works by tricking the user's browser into requesting fakebank.com/withdrawForm.htmldirectly using a properly formed POSTrequest. The server at fakebank.comhappily executes the requested POST, thus transferring funds using the parameters supplied in the POSTbody (which include a destination account belonging to the attacker that was put there by maliciousSite.com). The server at maliciousSite.comdoesn't need to see the data returned, because the action has been taken (unless fakebank.comuses these CSRF tokens, which the maliciousSite.comcan't possibly know unless it has been divulged in some way. It can't ask for it). If fakebank.comis using CSRF tokens, then maliciousSite.comwill submit a POSTrequest that is missing the token, thus indicating a potential CSRF attack in progress.

CSRFPOST攻击的工作原理是欺骗用户的浏览器fakebank.com/withdrawForm.html使用正确格式的请求直接进行POST请求。服务器 atfakebank.com愉快地执行所请求的POST，从而使用POST正文中提供的参数（其中包括属于攻击者的目标帐户，由 放置在那里maliciousSite.com）转移资金。服务器maliciousSite.com不需要看到返回的数据，因为已经采取了行动（除非fakebank.com使用这些CSRF令牌，maliciousSite.com除非它以某种方式泄露，否则不可能知道。它不能要求它） . 如果fakebank.com正在使用 CSRF 令牌，maliciousSite.com则将提交POST缺少令牌的请求，从而表明潜在的 CSRF 攻击正在进行中。

Vulnerabilities of this method include using a CSRF token that is not kept sufficiently secret and is divulged in some way. Also, if the CSRF token is not sufficiently random, then maliciousSite.commight be able to guess it. Also, if there is a weakness in the browser's enforcement of same domain policy, this could be exploited. Generally speaking, modern browsers are not vulnerable to this.

此方法的漏洞包括使用未充分保密且以某种方式泄露的 CSRF 令牌。此外，如果 CSRF 令牌不够随机，则maliciousSite.com可能能够猜到它。此外，如果浏览器在执行相同域策略方面存在弱点，则可能会被利用。一般来说，现代浏览器不易受此影响。

Please let me know if this is an insufficient explanation and I'll attempt to articulate it a little better for you.

如果这解释不够充分，请告诉我，我会尝试为您更好地阐明它。

回答by deceze

And that is exactly the point. The Same Origin Policyin the browser does not allow GETrequests to other sites. So no site can GET the CSRF token from another just using Javascipt within the browser.

这正是重点。浏览器中的同源策略不允许对其他站点的GET请求。因此，没有站点可以仅在浏览器中使用 Javascipt 从另一个站点获取 CSRF 令牌。