sailsjs 的 CSRF 令牌存储
CSRF Token Storage by sailsjs
我正在研究使用 sailsjs 作为 nodejs 框架的企业解决方案。安全是实施的组成部分。除了 SSL、CORS，我们还使用了 sailsjs CSRF 实现。我仍在评估使用此令牌的安全性。任何人都可以指导以下内容：
sailsjs 在哪里存储 CSRF 令牌？它是加密的吗？使用起来有多安全？
您需要做一些工作来验证您的令牌不能被不受信任的服务器访问；它们应该只响应 GET 请求，它们不应该通过 AJAX 访问，也不应该启用 CORS headers。
PillarJS 有一个 excellent readme on CSRF。它说关于 CSRF 令牌：
CSRF Tokens
Alas, the final solution is using CSRF tokens. How do CSRF tokens
work?
Server sends the client a token. Client submits a form with the token.
The server rejects the request if the token is invalid. An attacker
would have to somehow get the CSRF token from your site, and they
would have to use JavaScript to do so. Thus, if your site does not
support CORS, then there's no way for the attacker to get the CSRF
token, eliminating the threat.
Make sure CSRF tokens can not be accessed with AJAX! Don't create a
/csrf route just to grab a token, and especially don't support CORS on
that route!
The token just needs to be "unguessable", making it difficult for a
attacker to successful within a couple of tries. It does not have to
be cryptographically secure. An attack is one or two clicks by an
unbeknownst user, not a brute force attack by a server.
还可以从 Sails.js docs 中考虑这一点，它给出了 real-world 它们如何运作的示例：
CSRF tokens are temporary and session-specific; e.g. Imagine Mary and
Muhammad are both shoppers accessing our e-commerce site running on
Sails, and CSRF protection is enabled. Let's say that on Monday, Mary
and Muhammad both make purchases. In order to do so, our site needed
to dispense at least two different CSRF tokens- one for Mary and one
for Muhammad. From then on, if our web backend received a request with
a missing or incorrect token, that request will be rejected. So now we
can rest assured that when Mary navigates away to play online poker,
the 3rd party website cannot trick the browser into sending malicious
requests to our site using her cookies.
最后，Sails.js 使用 Connect CSRF protection middleware. Tokens are stored on a per-session basis, and therefore are not stored in a database nor is (double) encryption needed. Here's another excellent SO answer on the subject: Why does Express/Connect generate new CSRF token on each request?
我正在研究使用 sailsjs 作为 nodejs 框架的企业解决方案。安全是实施的组成部分。除了 SSL、CORS，我们还使用了 sailsjs CSRF 实现。我仍在评估使用此令牌的安全性。任何人都可以指导以下内容： sailsjs 在哪里存储 CSRF 令牌？它是加密的吗？使用起来有多安全？
您需要做一些工作来验证您的令牌不能被不受信任的服务器访问；它们应该只响应 GET 请求，它们不应该通过 AJAX 访问，也不应该启用 CORS headers。
PillarJS 有一个 excellent readme on CSRF。它说关于 CSRF 令牌：
CSRF Tokens
Alas, the final solution is using CSRF tokens. How do CSRF tokens work?
Server sends the client a token. Client submits a form with the token. The server rejects the request if the token is invalid. An attacker would have to somehow get the CSRF token from your site, and they would have to use JavaScript to do so. Thus, if your site does not support CORS, then there's no way for the attacker to get the CSRF token, eliminating the threat.
Make sure CSRF tokens can not be accessed with AJAX! Don't create a /csrf route just to grab a token, and especially don't support CORS on that route!
The token just needs to be "unguessable", making it difficult for a attacker to successful within a couple of tries. It does not have to be cryptographically secure. An attack is one or two clicks by an unbeknownst user, not a brute force attack by a server.
还可以从 Sails.js docs 中考虑这一点，它给出了 real-world 它们如何运作的示例：
CSRF tokens are temporary and session-specific; e.g. Imagine Mary and Muhammad are both shoppers accessing our e-commerce site running on Sails, and CSRF protection is enabled. Let's say that on Monday, Mary and Muhammad both make purchases. In order to do so, our site needed to dispense at least two different CSRF tokens- one for Mary and one for Muhammad. From then on, if our web backend received a request with a missing or incorrect token, that request will be rejected. So now we can rest assured that when Mary navigates away to play online poker, the 3rd party website cannot trick the browser into sending malicious requests to our site using her cookies.
最后，Sails.js 使用 Connect CSRF protection middleware. Tokens are stored on a per-session basis, and therefore are not stored in a database nor is (double) encryption needed. Here's another excellent SO answer on the subject: Why does Express/Connect generate new CSRF token on each request?