what is the use of anti-forgery token salt?

后端 未结 2 1412
旧巷少年郎
旧巷少年郎 2021-01-08 00:54

In ASP.NET MVC 1.0, there is a new feature for handling cross site request forgery security problem:

 <%= Html.AntiForgeryToken() %>
[ValidateAntiForge         


        
相关标签:
2条回答
  • 2021-01-08 01:08

    You've ask a few unrelated problems:

    1. I don't know why your security software is reporting 'session fixed'. Try reading the documentation that comes with the report
    2. The anti-forgery token:

    This is used (presumably) to validate that each request is valid. So consider that someone tries to present a link to the page ?x=1, if the token is not also passed, the request will be rejected. Further, it (may) prevent duplicate posting of the same item. If you click 'post' twice, the token will likely change (each request), and this case will be detected via something like:

    Session["nextToken"] = token;
    WriteToken(token);
    
    ...
    
    if( !Request["nextToken"] == Session["nextToken"] ){
        ...
    }
    
    // note: order in code is slightly different, you must take the token
    // before regenerating it, obviously
    

    I think the term for this (the attack it protects) is called "CSRF" (Cross-Site Request Forgery), these days.

    0 讨论(0)
  • 2021-01-08 01:21

    Lots of info on the AntiForgeryToken here: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

    This is to prevent a Cross-Site Request Forgery (CSRF). It's pretty standard behavior to click 'Save' sumbit a form and perform some action on the server, i.e. save a user's details. How do you know the user submitting the form is the user they claim to be? In most cases you'd use some cookie or windows based auth.

    What if an attacker lures you to a site which submits exactly the same form in a little hidden IFRAME? Your cookies get submitted intact and the server doesn't see the request as any different to a legit request. (As gmail has discovered: http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/)

    The anti-forgery token prevents this form of attack by creating a additional cookie token everytime a page is generated. The token is both in the form and the cookie, if the form and cookie don't match we have a CSRF attack (as the attacker wouldn't be able to read the anti-forgery token using the attack described above).

    And what does the salt do, from the article above:

    Salt is just an arbitrary string. A different salt value means a different anti-forgery token will be generated. This means that even if an attacker manages to get hold of a valid token somehow, they can’t reuse it in other parts of the application where a different salt value is required.

    Update: How is the token generated? Download the source, and have a look at the AntiForgeryDataSerializer, AntiForgeryData classes.

    0 讨论(0)
提交回复
热议问题