为什么Express / Connect在每个请求上生成新的CSRF令牌？ [英] Why does Express/Connect generate new CSRF token on each request?
问题描述
据了解，有两种方法可以防止CSRF攻击：1）每个会话令牌，以及2）每个请求的令牌
As far as I understand there are two approaches in protecting from CSRF attacks: 1) token per session, and 2) token per request
1）在第一种情况下，当用户的会话初始化时，CSRF令牌仅生成一次。因此，用户一次只能有一个有效的令牌。
1) In the first case CSRF token is being generated only once when the user's session is initialized. So there is only one valid token for the user at once.
2）在第二种情况下，每个请求都会生成新的CSRF令牌，之后，旧的无效。
它更难利用这种可行性，因为即使攻击者窃取令牌（通过XSS），当用户进入下一页时，它将过期。
但另一方面，这种方法使webapp不太可用。以下是 security.stackexchange.com 的好报价：
2) In the second case new CSRF token is being generated on each request and after that an old one becomes invalid. It makes harder to exploit the vunerability because even if attacker steals a token (via XSS) it expires when the user goes to the next page. But on the other hand this approach makes webapp less usable. Here is a good quotation from security.stackexchange.com:
例如，如果他们点击返回按钮并以新值提交表单，则提交将失败，并可能会遇到一些敌对的错误消息。如果他们尝试在第二个选项卡中打开一个资源，他们会在一个或两个选项卡中随机中断会话。
For example if they hit the 'back' button and submit the form with new values, the submission will fail, and likely greet them with some hostile error message. If they try to open a resource in a second tab, they'll find the session randomly breaks in one or both tabs
当分析Node.js Express 框架（基于 Connect ）我注意到，每个请求都生成一个新的CSRF令牌，
但旧的不会变为无效。
When analizing Node.js Express framework (which is based on Connect) I noticed that a new CSRF token is generated on each request, but an old one doesn't become invalid.
我的问题是：在每个请求上提供新的CSRF令牌的原因是什么？
为什么不是每个会话生成一个单一的令牌？
My question is: what is the reason to provide new CSRF token on each request and not to make invalid an old one? Why not just generate a single token per session?
谢谢你对我的英文！
推荐答案
CSRF令牌是nonces。它们应该仅使用一次（或长时间安全使用）。它们用于识别和授权请求。让我们考虑防止CSRF的两种方法：
CSRF tokens are nonces. They are supposed to be used only once (or safely after a long time). They are used to identify and authorize requests. Let us consider the two approaches to prevent CSRF:
-
每个会话固定的单个令牌：这个缺点是客户端可以把它的令牌传给他人。这可能不是由于嗅闻或中间人或某种安全失误。这是用户部分的背叛。多个客户端可以使用相同的标记。不幸的是，没有任何事情可以做到。
Single token fixed per session: The drawback with this is that the client can pass its token to others. This may not be due to sniffing or man-in-the-middle or some security lapse. This is betrayal on user's part. Multiple clients can use the same token. Sadly nothing can be done about it.
动态令牌：每次任何交互发生在服务器和客户端之间或发生超时时，令牌将被更新。它阻止使用旧的令牌并同时从多个客户端使用。
Dynamic token: token is updated every time any interaction happens between server and client or whenever timeout occurs. It prevents use of older tokens and simultaneous use from multiple clients.
动态令牌的缺点是限制从那里回来继续。在某些情况下，可能需要，如果实施购物车，重新加载必须检查是否库存。 CSRF将防止重发发送的表单或重复买/卖。
The drawback of the dynamic token is that it restricts going back and continuing from there. In some cases it could be desirable, like if implementing shopping cart, reload is must to check if in stock. CSRF will prevent resending the sent form or repeat buy/sell.
细粒度控制会更好。对于您提到的场景，您可以在没有CSRF验证的情况下执行。那么不要在该页面使用CSRF。换句话说，每条路线处理CSRF（或其例外）。
A fine-grained control would be better. For the scenario you mention you can do without CSRF validation. Then don't use CSRF for that particular page. In other words handle the CSRF (or its exceptions) per route.
更新
我只能想到单一动态令牌多于两个原因的两个原因：
I can only think of two reasons why single dynamic token is better than multiple:
-
多个令牌的确更好，但是至少一个动态令牌像上面一样。这意味着设计可能变得复杂的详细工作流程。例如见：
Multiple tokens are indeed better but have at least one dynamic token like one above. This means designing a detailed workflow which may become complex. For example see here :
- https://developers.google.com/accounts/docs/OAuth2
- https://dev.twitter.com/docs/auth/implementing-sign-twitter
- < a href =https://developers.facebook.com/docs/facebook-login/access-tokens/ =nofollow> https://developers.facebook.com/docs/facebook-login/access-tokens /
- https://developers.google.com/accounts/docs/OAuth2
- https://dev.twitter.com/docs/auth/implementing-sign-twitter
- https://developers.facebook.com/docs/facebook-login/access-tokens/
这些是访问他们的API（表单提交等）的令牌，不仅仅是登录。每个人实现它们不同。除非有很好的用例，否则不值得。您的网页会大量使用。更不用说表单提交现在不简单。
These are tokens to access their API (form submission etc.) not just login. Each one implements them differently. Not worth doing unless have good use case. Your webpages will use it heavily. Not to mention form submission is not simple now.
动态单一标记是最简单的，而且在库中随时可用。所以可以随时随地使用它。
Dynamic single token is the easiest, and the readily available in library. So can use it on the go.
多个令牌的优点：
- 可以实现交易。您可以在请求之间订购。
- 可以从超时和身份验证错误中回退（您必须立即处理）。
- 安全！比单个令牌更强大。可以检测到令牌滥用，黑名单用户。
顺便说一句，如果要使用多个令牌，您现在有OAuth2库。
By the way if you want to use multiple tokens you have OAuth2 libraries now.
这篇关于为什么Express / Connect在每个请求上生成新的CSRF令牌？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
