Cross-Site Request Forgery (CSRF) tests failed to find the vulnerabilities in my application. (504 Views)
Reply
Occasional Advisor
Febins
Posts: 13
Registered: ‎04-19-2012
Message 1 of 2 (504 Views)

Cross-Site Request Forgery (CSRF) tests failed to find the vulnerabilities in my application.

[ Edited ]

It seems Webinspect has updated the Cross-Site Request Forgery (CSRF) policy in OWASP 2013 . I have found 2 tests are included in the vulnerability list ; saying ; Cross-Site Request Forgery (Vulnerability ID: 10963) and Cross-Site Request Forgery (High) (Vulnerability ID: 10977). Please let me know any other vulnerability test  is available in webinspect against this check. 

 

 I had run the my application to check the CSRF , but WI have failed to find any issues , but we done it manually. I have done with Standard scan and list down scan and both ways failed to find CSRF issues.  I don't know the issue is in my side or any configuration. If not why Webinspect is failed to find the issue . 

 

Respected Contributor
HansEnders
Posts: 613
Registered: ‎07-01-2008
Message 2 of 2 (457 Views)

Re: Cross-Site Request Forgery (CSRF) tests failed to find the vulnerabilities in my application.

Febins;

 

Yes, those are the CSRF checks currently.  What you may not be aware of is their prerequisites and that you can alter the inputs for this particular check!

 

From the Policy Manager's description of check: 10963 Cross-Site Request Forgery

+++++

Criteria for identifying CSRF:

1. This check is only run against POST requests.
2. The page must be either a login page, or a page in restricted session (i.e. an authenticated session) .
* Note: In order to avoid testing every POST request made during authenticated sessions, we will only run the check against a URL one time. This means that forms with multiple parameters will only be tested one time and not multiple times like a XSS or parameter injection check.
3. The page is not a re-authentication page. This is to avoid cases where a user is asked to either change a password or provide their password when they are already in an authenticated session. A re-authentication page is not CSRF vulnerable.
4. The page does not contain CAPTCHA. A CAPTCHA page is not CSRF vulnerable
5. The page is not an error page or an invalid page from the server.

+++++

 

 

Going further within the Policy Manager, if you were to click the link "Find Vulnerability in Standard View" for that check, it would open the full details for it, which include the available user inputs.

  • Password field names
  • Possible Username List
  • CSRF Request Black List
  • CSRF Response Black List
  • CSRF Response White List

 

For more direct access to the available user inputs for all affected checks, use the Tools menu within the Policy Manager to open the Audit Inputs Editor.  There you will see these same fields for check 10963.  Opening the Help Guide will provide the following explanation to help you formulate your own customized settings.  These details may help explain why your particular known instance of CSRF was not discovered in your prior tests.

 

Once you have defined custom check inputs, save that Audit Inputs file and specify in within your scan settings for your subsequent scans > Attack Exclusions panel > Import Audit Inputs button.  This same panel offers another way to open the Audit Inputs Editor tool besides within the Policy Manager.

 

+++++

10963: Cross-Site Request Forgery

 

Criteria for identifying Cross-Site Request Forgery (CSRF)

  • This check is only run against POST requests.
  • The page must be either:
    • A login page.
    • A page in restricted session (i.e., an authenticated session) . 

Note: To avoid testing every POST request made during authenticated sessions, the check is run against a URL one time. This means that forms with multiple parameters will be tested one time only and not multiple times like a cross-site scripting or parameter injection check.

  • The page is not a re-authentication page. This is to avoid cases where a user is asked to either change a password or provide a password when already in an authenticated session. A re-authentication page is not CSRF vulnerable.
  • The page does not contain CAPTCHA. A CAPTCHA page is not vulnerable to CSRF.
  • The page is not an error page or an invalid page from the server.

Inputs

Check inputs are used as heuristics to help the CSRF agent refine detected results. There are a number of criteria used for CSRF detection that help to avoid false positives.

 

Required

  • Password field names - This field is used to help identify login pages. The matches are string matches.
  • Possible Username List - This field is used to help identify login pages. The matches are string matches.

 

Optional

  • CSRF Request Black List - This field is used to identify pages that are NOT to be flagged as vulnerable to CSRF.  Matching values are identified for the name values in POST parameters.
  • CSRF Response Black List - This field is used to identify error pages or invalid pages. The default value here is a combination of two regular expressions and also a string value (CAPTCHA). Matching values are identified on the response body.
  • CSRF Response White List - This field is used to elevate the risk associated with this vulnerability for specific pages. By default, CSRF findings are a Medium severity.  A match for values in this field will result in the finding being rated as a High severity. Matching values are identified in the response body.

+++++


-- Habeas Data
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.