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

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