反CSRF令牌和Javascript [英] anti-CSRF token and Javascript
问题描述
我试图保护CSRF的应用程序（PHP和大量的JS）。
I'm trying to protect an application (php and lots of JS) from CSRF.
我想用代币。
很多操作都是用AJAX做的，所以我要通过JavaScript中的令牌。 如果我要生成每个会话或每个页面加载它是简单的1令牌 - 我产生新的令牌，把它放在某处一个DOM，然后发现它使用JavaScript和发送到加工方
A lot of operations are done with AJAX, so I have to pass the token in Javascript. If I want to generate 1 token per session or per page load it's simple - I generate new token, put it somewhere in a DOM and then find it with Javascript and send to the processing side.
但是，如果我想使用新令牌的每个操作是什么？ 我在想这样做Ajax调用重新生成的令牌，然后将结果传递到处理页。
But what if I want to use new token for every operation? I was thinking about doing an ajax call to regenerate token and then pass the result to processing page.
这是否增加安全风险？ 我在想引诱用户在页面脚本会要求标记，然后用它来作要求，但话又说回来跨域JavaScript是禁止的。 可以用闪光灯做？
Does this increase security risk? I was thinking about luring user to page with script which would ask for token and then use it to make the request but then again cross domain Javascript is forbidden. Can it be done with flash?
也许对于保护Ajax调用从CSRF另一种方法？
Maybe another approach for protecting ajax calls from CSRF?
谢谢！
推荐答案
有多种技术，其中一起使用时提供了充足的CSRF保护。
There are several techniques, which when used together provide a sufficient CSRF protection.
唯一标记
有一个单一的，特定于会话的令牌是对于大多数应用已经足够了。只要确保你的网站没有任何XSS漏洞，否则任何一种你使用令牌技术是一种浪费。
A single, session-specific token is good enough for most applications. Just make sure that your site doesn't have any XSS vulnerabilities, otherwise any kind of token technique you employ is a waste.
AJAX调用来重新生成令牌是一个坏主意。谁将会守卫的卫兵？如果Ajax调用本身很容易受到跨站请求伪造，它种失败的目的。使用AJAX多个令牌一般坏主意。它迫使你序列化的要求，即只有一个AJAX请求被允许的时间。如果你愿意忍受这种限制，你或许可以捎带令牌的第二个AJAX调用响应的第一个请求。
AJAX call to regenerate the token is a bad idea. Who will guard the guards? If the AJAX call itself is vulnerable to CSRF, it kind of defeats the purpose. Multiple tokens with AJAX are in general bad idea. It forces you to serialize your requests i.e. only one AJAX request is allowed at a time. If you are willing to live with that limitation, you can perhaps piggyback token for the second AJAX call in response to the first request.
我个人认为最好是重新认证的关键事务的用户，并保护剩下的交易，特定于会话令牌。
Personally, I think it is better to re-authenticate the user for critical transactions, and protect the remaining transactions with the session-specific token.
自定义HTTP标头
您可以添加到您的每个请求的自定义HTTP标头，并检查其presence在服务器端。实际的键/值不必是秘密的，服务器只需要确保它存在于传入请求。
You can add a custom HTTP header to each of your requests, and check its presence on the server side. The actual key/value doesn't need to be secret, the server just needs to ensure it exists in the incoming request.
此方法是不够好，保护CSRF较新版本的浏览器，但是它可能太工作围绕这一点，如果你的用户有Flash Player的旧版本。
This approach is good enough to protect CSRF in newer versions of the browsers, however its possible too work-around this if your user has older version for Flash Player.
检查引荐
检查引荐头也不错，以保护CSRF在新的浏览器。它不可能欺骗这个头，虽然它有可能在较旧版本的Flash。所以，虽然它不是万无一失的，但它仍然增加了一些保护。
Checking for the Referrer header is also good to protect CSRF in the newer browsers. Its not possible to spoof this header, though it was possible in older versions of Flash. So, while it is not foolproof, it still adds some protection.
解决验证码
强制用户解决一个验证码也是有效抵御CSRF。它不方便的地狱，但pretty的效果。这也许是唯一的CSRF保护的作品，即使你有XSS漏洞。
Forcing the user to solve a captcha is also effective against CSRF. Its inconvenient as hell, but pretty effective. This is perhaps the only CSRF protection that works even if you have XSS vulnerabilities.
摘要
- 使用基于会话的道理，但重新认证的高价值交易
- 添加自定义HTTP标头，并且还检查引荐。两者都不能由自己万无一失，但不要伤害
这篇关于反CSRF令牌和Javascript的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
