2011-09-15 15:48
采纳率: 100%
浏览 8

CSRF令牌 - 如何正确实施?

I've just setup a simple CSRF protection in my application. It creates a unique crumb which are validated against a session value upon submitting a form.

Unfortunately this means now that I can't keep multiple instances (tabs in the browser) of my application open simultaneously as the CSRF crumbs collide with each other.

Should I create an individual token for each actual form or use a mutual, shared crumb for all my forms? What are common sense here?

图片转代码服务由CSDN问答提供 功能建议

我刚刚在我的应用程序中设置了一个简单的CSRF保护。 它创建了一个独特的crumb,它在提交表单时根据会话值进行验证。

不幸的是,这意味着我无法保持应用程序的多个实例(浏览器中的选项卡)打开 同时,当CSRF碎屑相互碰撞时。

我应该为每个实际表单创建一个单独的令牌,还是为我的所有表单使用共同的共享碎片? 这里有什么常识?

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 邀请回答

3条回答 默认 最新

  • drzrdc1766788 2011-09-15 18:02

    You can do either. It depends on the level of security you want.

    The OWASP Enterprise Security API (ESAPI) uses the single token per user session method. That is probably a pretty effective method assuming you have no XSS holes and you have reasonably short session timeouts. If you allow sessions to stay alive for days or weeks, then this is not a good approach.

    Personally, I do not find it difficult to use a different token for each instance of each form. I store a structure in the user's session with key-value pairs. The key for each item is the ID of the form, the value is another structure that contain the token and an expiry date for that token. Typically I will only allow a token to live for 10-20 minutes, then it expires. For longer forms I may give it a long expiry time.

    If you want to be able to support the same form in multiple browser tabs in the same session, then my method becomes a little trickery but could still be easily done by having unique form IDs.

    点赞 打赏 评论
  • doukuanyong1939 2011-09-15 16:12

    As I know about CSRF, you can use

    1) Random number and save it into session:
    Add it to hidden input called hidden, then when you recive info you can check hidden field with the session value

    2) Static config variable (like previous but no session)
    The hidden field will contain this value (variable from config). When you validate, you will check the hidden posted and the config security key value

    3) HTTP Referer
    You can use http referrer to know where user come from then check it with the real domain(this method can attack if your website contain xss).

    As I know you can use any solution :)

    点赞 打赏 评论
  • douyi9787 2011-09-15 16:43

    The OWASP Cheat Sheet has the most definitive answers for this sort of thing. It discusses different approaches and balancing of security vs. usability.

    In brief they recommend having a single token per (browser) session. In other words in your case the same token is shared among tabs. The cheat sheet also emphasizes that it is very important not to expose your site to cross site scripting vulnerabilities, as this subverts the per session CSRF token strategy.

    点赞 打赏 评论

相关推荐 更多相似问题