OWASP ZAP Forms Authentication Query

[Samuel Kierney]

Hi,

I am trying to implement OWASP ZAP using Selenium. To do this, I have used the sample code provided here:

https://github.com/zaproxy/zap-api-dotnet/blob/master/src/OWASPZAPDotNetAPI/OWASPZAPDotNetAPI.Samples/AuthenticatedScanWithFormsAuthentication.cs

When replacing their website with our own, I am running into issues with Authentication. If I execute the tests and try to spider, it will just constantly retry the login tests due to issues with the CSRF token. The error returned is:

"The anti-forgery cookie token and form field token do not match"

However, if prior to running the test script, I press the 'Quick Start' tab to open Firefox, navigate to our Portal and login manually, it will spider successfully the first time the test runs. Future runs will error due to not being able to find the resource, as the CSRF is likely not valid.

I use Forms Authentication, and in the Login Request POST Data I use the following format: __RequestVerificationToken=*&UserName=user&Password=password

Have I done the POST data incorrectly? Or is there something obvious I am missing? When I view the request, I can see its getting the token in the wildcard, but it just does not work with any consistency.

Thanks,

[Christoph Brunner]

Perform a manual login and check the request + response messages in the ZAP GUI history tab. You will see what parameter names + values have been included in the request. Then compare that against the requests sent out by your authentication script.

Regarding CSRF tokens, ZAP will automatically include those for as long your your web app uses a CSRF token name that is on ZAP's default token name list. On the GUI, go to the menu andcheck Tools  > Options > Anti-CSRF tokens.

If your token name is not included there, you will have to add it there.

When using automation, you will have to add the `-config anticsrf.tokens.token.name="TOKENNAME"   -config anticsrf.tokens.token.enabled=true ` parameters to zap.sh

[Samuel Kierney]

Hi,

So between a manual try and running the test via automation, the only differences in the initial post seems to be not including the following:

Content-Length: 168
Origin: [initialwebsite]
Connection: keep-alive
Referer: [initialwebsite]

Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1

In the body text, for both, its providing a valid AntiCSRF token as well as the correct username and password. Such as:

__RequestVerificationToken=[validtoken]&UserName=[validusername]&Password=[validpassword]

Each time a login occurs, a new token is generated and becomes part of the URL.

When I query our database that the page uses, it has definitely created a valid session in both cases too. It is just when its automated, it does not progress past the authentication in OWASP Zap, as I can see from logging the session is there and the __RequestVerificationToken that it should be using is in the POST request.

As mentioned in my original post, if I manually open the browser via ZAP and login then run the automated tests it will then pass the first time it has to Spider. If I then run it again, it fails as though its using the old Anti-CSRF token.

Is there anyway to make sure it is refreshing this on each run, or if I've not done it manually first, that it can correctly process the token on the first try?

[Christoph Brunner]

It is unclear to me how exactly you are running the "automated tests": by loading an automation framework YAML in the GUI or using the zap.sh script from command line? My guess is it's the former...

As you are saying that your application logs indicate a successful login, then the problem might be with the logged in / logged out indicators in the automation tests. Maybe they are different compared to the one defined in the GUI context.

It is difficult to figure out what the problem is with incomplete information.

What I generally learned from custom authentication and ZAP GUI + automation framework:

* Compare requests in GUI against those in headlless operations (=automation framework)

* Run the automation framework YAML from the GUI for easier debugging

* Check if your custom authentication script triggers no Java exceptions

* Increase log level to see what's going on, in authentication and in general

* Make sure your YAML has no errors

* Make sure your regexes are valid

[Samuel Kierney]

Hi,

So I have implemented the methods in Selenium as guided here:

https://github.com/zaproxy/zap-api-dotnet/blob/master/src/OWASPZAPDotNetAPI/OWASPZAPDotNetAPI.Samples/AuthenticatedScanWithFormsAuthentication.cs

This basically loads the pages into the context tree and populates the Forms Authentication, adds the user, etc. 

What I have found this morning as well, is if in my Selenium tests I execute a simple login test before I start loading the webpages from Sites into the Context tree, it also works on the initial Spider. 

The issue definitely seems to be with how its saving/using the Anti-CSRF token or whether its just storing the first successful one, and then just trying to refresh it every time when the database to our site is considering it expired, rather than trying to use the new one it receives on other login requests.

That means I can work around this to get the results of a spider, but if I do the active scan it does constantly just throw the anti-forgery token errors: The anti-forgery cookie token and form field token do not match - which is because it must be using the old token in the website URL, but it does not match the newest session.