Does Arachni support session long anti-CSRF tokens

Steven Phillips's Avatar

Steven Phillips

17 Jul, 2017 01:57 PM

Hi Tasos,

First let me thank you again for the nested cookies feature, its working perfectly - you closed the other thread before I could feedback on my larger tests which have found some problems that I would never have found without this feature, so thanks again!

I have one remaining issue that I'm not making any progress on and that's with the anti-CSRF check. I have a randomly generated 32 byte hex string which is generated once per session (not the most secure but I believe still deemed adequate and about the best I can do without severely compromising performance or usability, or probably both) and Arachni is claiming all but one form as being susceptible to CSRF attacks.

So I've created a simple test harness which has a 'home' page with a link to a simple 'Set name' page using a session variable to store the 32 byte random anti-CSRF token - this site reportedly works fine with no issues (only running csrf check). If I then duplicate the 'Set name' page (i.e. just copy to a new file name) so the home page has 2 link, one to each page that does exactly the same thing I then trigger a CSRF error for one of them but not the other.

The CSRF check reports the Vector information as:

name 
mems   Save changes 
sk         608da8d8d0dffcd696696d6e41d44613e

The 'sk' input is the anti-csrf token and I've tried renaming the input to 'csrf_token' but nothing I've tried avoids the 2nd page triggering a CSRF issue.

Is a session long anti-CSRF token still considered an acceptable security measure? Does Arachni support session long CSRF tokens? If so what am I doing wrong?

I can send you the test harness if it would help.

Thanks,

Steve

  1. Support Staff 1 Posted by Tasos Laskos on 31 Jul, 2017 07:32 AM

    Tasos Laskos's Avatar

    For forms Arachni will check whether or not the token gets changed after every refresh, if not then the form is deemed to have no nonce.

  2. 2 Posted by Steven Phillips on 31 Jul, 2017 04:27 PM

    Steven Phillips's Avatar

    Hi Tasos,

    Thanks for responding, I've been digging into this a lot more and also reading older threads such as 'CLI identifies XSS but not CSRF' which help explain the way Arachni's CSRF test has evolved etc. In the process of doing this I think I've found a bug in Arachni and the result of my research is that believe my approach to safeguarding against CSRF attacks is reasonable but Arachni can't currently be used to verify it - which is disappointing and I hope I'm wrong.

    Potential bug in Arachni first - to understand Arachni better I created a test harness with a Home page containing 6 links, 3 pairs, each pair edits 2 values and each pair having a different implementation of an Anti-CSRF solution. I found that which ever link I put first Arachni will not explore the sub-page fully and as a result it will not submit the 'Save changes' button and never discover the hidden page that it calls to 'save' the changes - this is why I had to initially duplicate the page because the first one is never followed properly.

    The main reason I really think this is an Arachni bug is because the page that is not fully processed is always, and only, determined by the link order, if I change the order the new first link page is the one not processed and any problems that page has (well CSRF at least) will not be found.

    I have verified the first page's form action page is never called by the server side logging and I'm using the latest overnight build. I can sent you this test harness or I can run tests etc.

    Now to CSRF - I can understand Arachni's move to require nonces to cut down on false-positives but this requirement seems to contradict Arachni's own 'Remediation guidance' which states:

    These tokens can be configured in such a way that each session generates a new anti-CSRF token or such that each individual request requires a new token.
    

    In my case I have a site with multiple objects that can be edited by multiple users at the same time using multiple tabs (i.e. one user can edit many objects at once using multiple browser tabs), trying to support individual request based anti-CSRF tokens is therefore difficult and thus I have gone for the much simpler session based solution which I believe is still considered secure as long as the site has no XXS vulnerability (and if the site has an XXS vulnerability then CSRF is probably the least of your problems?)

    But there appears to be no support for this approach in Arachni which is a shame as I think it could still do a lot without risk of false-positives. The simplest first step I can think of is to have a 'Session Anti-CSRF token name' parameter (or this could be a separate csrf_session check which requires a parameter) and if used the CSRF check changes to simply verifying this one input parameter exists and its value is suitably long and reasonable.

    For example if session_csrf_token_name was set to 'csrf_token' it would verify that every state changing form (or URL) had this parameter and set to a suitable value, making it easy to identify any unprotected forms.

    Does this seem reasonable and feasible?

  3. 3 Posted by Steven Phillips on 01 Aug, 2017 07:21 AM

    Steven Phillips's Avatar

    Hi Tasos,

    Thanks for responding, I've been digging into this a lot more and also reading older threads such as 'CLI identifies XSS but not CSRF' which help explain the way Arachni's CSRF test has evolved etc. In the process of doing this I think I've found a bug in Arachni and the result of my research is that believe my approach to safeguarding against CSRF attacks is reasonable but Arachni can't currently be used to verify it - which is disappointing and I hope I'm wrong.

    Potential bug in Arachni first - to understand Arachni better I created a test harness with a Home page containing 6 links, 3 pairs, each pair edits 2 values and each pair having a different implementation of an Anti-CSRF solution. I found that which ever link I put first Arachni will not explore the sub-page fully and as a result it will not submit the 'Save changes' button and never discover the hidden page that it calls to 'save' the changes - this is why I had to initially duplicate the page because the first one is never followed properly.

    The main reason I really think this is an Arachni bug is because the page that is not fully processed is always, and only, determined by the link order, if I change the order the new first link page is the one not processed and any problems that page has (well CSRF at least) will not be found.

    I have verified the first page's form action page is never called by the server side logging and I'm using the latest overnight build. I can sent you this test harness or I can run tests etc.

    Now to CSRF - I can understand Arachni's move to require nonces to cut down on false-positives but this requirement seems to contradict Arachni's own 'Remediation guidance' which states:

    These tokens can be configured in such a way that each session generates a new anti-CSRF token or such that each individual request requires a new token.
    

    In my case I have a site with multiple objects that can be edited by multiple users at the same time using multiple tabs (i.e. one user can edit many objects at once using multiple browser tabs), trying to support individual request based anti-CSRF tokens is therefore difficult and thus I have gone for the much simpler session based solution which I believe is still considered secure as long as the site has no XXS vulnerability (and if the site has an XXS vulnerability then CSRF is probably the least of your problems?)

    But there appears to be no support for this approach in Arachni which is a shame as I think it could still do a lot without risk of false-positives. The simplest first step I can think of is to have a 'Session Anti-CSRF token name' parameter (or this could be a separate csrf_session check which requires a parameter) and if used the CSRF check changes to simply verifying this one input parameter exists and its value is suitably long and reasonable.

    For example if session_csrf_token_name was set to 'csrf_token' it would verify that every state changing form (or URL) had this parameter and set to a suitable value, making it easy to identify any unprotected forms.

    Does this seem reasonable and feasible?

    Thanks,

    Steve

  4. 4 Posted by Steven Phillips on 21 Aug, 2017 11:21 AM

    Steven Phillips's Avatar

    Hi Tasos,

    Not seen a response to this and hoping I've not missed it (and sorry about the double post).

    Fundamentally I can see the need for the current csrf test and accept that this is checking for a more secure solution to the CSRF vulnerability, but this approach is not open to me and currently there is no way I can find to use Arachni to validate my session based anti-CSRF token is present and correct.

    How hard, and how would I go about, creating a new csrf_session check which verified that for all state changing submissions the given csrf token has been included and set to a suitable value?

    Thanks,

    Steve

  5. Support Staff 5 Posted by Tasos Laskos on 21 Aug, 2017 04:48 PM

    Tasos Laskos's Avatar

    Sorry I've been going back and forth for a while, summer vacations and whatnot.

    If I understand you correctly, you believe you've also found a bug in the crawl and audit irrespective of the anti-CSRF check situation?
    If so could you please open a bug on GitHub with a link to your test case?

    About the anti-CSRF check you propose, I don't see how that could be automated effectively. I'll give it some more thought and see if I can figure something out and keep you posted.
    I'm open to ideas btw.

  6. 6 Posted by Steven Phillips on 21 Aug, 2017 05:52 PM

    Steven Phillips's Avatar

    Hi Tasos,

    Yes I do think I've found an issue with the crawl and will cut the example down to as small as I can make it. I hope Classic ASP example is okay for you.

    I think I may not have explained my idea very well because I think it should be very easy to implement. I'm suggesting that when an Arachni configuration option is set/used it changes the way the xss check works - rather than trying to identify a nonce parameter (which I can't do for my site) it will look for the presence of a specific, pre-configured form parameter and check its value is reasonable.

    For example, lets first consider the current behaviour (as I understand it):

    a. Arachni determines if a site submission is state changing - if not End
    b. Arachni looks for a nonce - if not found report CSRF Error

    I'm suggesting that, given the new parameter is called 'anti_csrf_token', this is changed to:

    a. Arachni determines if a site submission is state changing - if not End
    b. If 'anti_csrf_token' is set then:
    b.1. Arachni looks for a parameter with the name of what 'anti_csrf_token' is set to with a suitable anti-csrf value - if not found or it has a trivial value then report CSRF Error
    c. Else if 'anti_csrf_token' is not set then:
    c.1. Arachni looks for a nonce - if not found report CSRF Error

    So if I don't set 'anti_csrf_token' there is no change in behaviour, however if I do set 'anti_csrf_token' to say "csrf_token" in my Arachni config then every state changing form Arachni simply needs to check for the presence of a "csrf_token" parameter a its value is good (i.e. long and random).

    I think this is good enough to give Arachni basic session-based CSRF support, which for me would be excellent.

    I have also got an Idea on how to further extend the xss check to give Arachni the ability to verify that the CSRF token is being checked, avoiding false positives, however this does requires sites to be implemented in a certain way (like mine is :-). Happy to document if you're interested...

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac