Checking for Auth with the Automation Framework

[Maximilian Schlosser]

Hi,

I've been trying to implement a scan using the automation framework.
So far I have successful runs, but I am unable to check auth.

I wanted to use a test for the `stats.auth.success` or `stats.auth.state.loggedin` metrics.

These tests always fail for the spider, although I defined a user in the env and in the spider job. However, I noticed that the automation framework complains about

2022-03-29 16:04:46,157 [main ] ERROR JobUtils - Automation Framework failed to find method setUser on org.zaproxy.zap.spider.SpiderParam

Will the spider automatically use the first user thats defined in the env?

Further runs and looking at the messages from the auth script shows that ZAP seems to be able to log in, but doesn't report the auth stats to the test. The request and response have the correct content for a successful login.

I have used the packaged scans before, which were able to authenticate sucessfully. I used the python api in my hooks file to check for auth before. Is something similar possible for the automation framework? Am I using the wrong stat for my test?

Or is it possible to access the API from a standalone script that I could run as part of my automation jobs?

Cheers,
Max

[Maximilian Schlosser]

This is my automation framework file.

[GOOD VIBBEOS]

hey are we allowed to post like black hat stuff in here?

I never saw the rules and recommendations!

Sometimes I am confused!

--
You received this message because you are subscribed to the Google Groups "OWASP ZAP User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zaproxy-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zaproxy-users/ef483386-9aed-4cdd-9cbc-1678e26dcf4dn%40googlegroups.com.

[Simon Bennetts]

Hi Max,

Can you run the AF plan in the ZAP Desktop?

If so that will make diagnosing problems like this much easier.

If not then we have other options, but they might be more painful ;)

Cheers,

Simon

[Simon Bennetts]

This question doesnt appear to have anything to do with the original post - you should always create new conversations for new topics.

If you do that then I'll response to that thread :)

Cheers,

Simon

[GOOD VIBBEOS]

Hello, I am still new to zap, so i heard some interesting questions about it, like can one run a pentest on his/her own web app and find vulns on the server?

Also I saw a youtuber pentesting through her site's server and enumerated her own user name and password. Is it possible or was she a scam?  

To view this discussion on the web visit https://groups.google.com/d/msgid/zaproxy-users/4b9172a7-ae4e-4385-bcc9-452d2d999c0dn%40googlegroups.com.

[Simon Bennetts]

As I said before - please start new conversations for new topics :)

[Maximilian Schlosser]

Hi Simon,

I imported the plan into ZAP Desktop after replacing the envvars with the correct data.

Sadly, I still have the same issue. The metric 'stats.auth.state.loggedin' seems to exist but is 0 right after the spider runs.

I tried using the test directly on the spider job. There, stats.auth.state.loggedin and stats.auth.failure are always 0.

I tried using a delay of 60s in case ZAP needed some time to process the messages. There, stats.auth.state.loggedin was also 0.

Are these metrics not available for the automation framework yet? If so, how could I check if my job was able to authenticate?

A related issue, but easy to work around for now:

While doing the tests above, I noticed that the context would be marked as green but wasn't created properly,

because ZAP couldn't import my Auth script (there was already a script with the same name).

Where should I report this? In ZAP core or ZAP extensions?

This also happens when I try to run the plan twice in the same session.

Cheers,

Max

--
You received this message because you are subscribed to a topic in the Google Groups "OWASP ZAP User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/zaproxy-users/blg_7qu5gTw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to zaproxy-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zaproxy-users/c4fe5884-7956-4639-b2a5-9ae8dca311aan%40googlegroups.com.

[Simon Bennetts]

Replies inline:

I imported the plan into ZAP Desktop after replacing the envvars with the correct data.

Sadly, I still have the same issue. The metric 'stats.auth.state.loggedin' seems to exist but is 0 right after the spider runs.

I would say this is a good thing - you can reproduce the issue in the desktop, that will make it much easier to debug.

 

I tried using the test directly on the spider job. There, stats.auth.state.loggedin and stats.auth.failure are always 0.

I tried using a delay of 60s in case ZAP needed some time to process the messages. There, stats.auth.state.loggedin was also 0.

This means that either authentication did not work or your verification configs are wrong.

 

Are these metrics not available for the automation framework yet? If so, how could I check if my job was able to authenticate?

Yes they are available to the AF.

And you can tell that based on your configs authentication was not successful :)

To debug this I would make a copy of your AF plan and remove all of the jobs after the spider (and associated tests).

Re run it.

Look in the History tab - you should see a small number of authentication requests.

If you see lots of them then it implies that either authentication is failing or ZAP is failing to maintain the session.

Look at the requests and responses sent by the spider - can you see the logged in/out regexes in them?

Point your browser at the host and port ZAP is running on.

View the site stats : https://www.zaproxy.org/docs/api/#statsviewsitestats

Let us know what the other auth stats are.

 

A related issue, but easy to work around for now:

While doing the tests above, I noticed that the context would be marked as green but wasn't created properly,

because ZAP couldn't import my Auth script (there was already a script with the same name).

Where should I report this? In ZAP core or ZAP extensions?

This also happens when I try to run the plan twice in the same session.

Is the script the same?

If so then you can ignore that.

If its not the same then it will be a problem.

If you are running an AF plan from the command line then you should know the state of ZAP and whether the script is already present.

Its less clear in the desktop - we dont want to delete all scripts before running a plan as I suspect most people wont ant that.

I guess we could add an option to say whether the script should be overwritten.

Cheers,

Simon

[Maximilian Schlosser]

Regarding the script not being loaded,

the issue happened both in the command line and in the GUI.

In the CLI, it happened when ZAP was already running with a script that had the same name.

In the GUI, it happened when I tried to run the same plan twice, without changing the script in between. There was no indication why it didn't work in the AF output, it just stopped after marking creating the context as successful. It ran successfully after I deleted the script via the scripts tab.

I will have a closer look at my Auth config.

To view this discussion on the web visit https://groups.google.com/d/msgid/zaproxy-users/c8e97ed8-9e51-4eb5-8f39-d8b9de3be3e2n%40googlegroups.com.

[Maximilian Schlosser]

Hi Simon,

I think I might have spotted a bug in the AF.

I've checked my config and exported the  generated context, to compare it to the old context I have been using for the packaged scans.

Doing that, I noticed that the authentication strategy is set to "EACH_RESP", although I am setting env.contexts.authentication.verification.method to "request" in my plan.

The context is consistently generated this way. I tried different options, deleting the context and reimporting it, and setting the verification method in the GUI.

This seems to be causing my problems, because a context with the same configuration, except "EACH_REQ" instead of "EACH_RESP" works.

I checked on GitHub and found that this is in the VerificationData code:

https://github.com/zaproxy/zap-extensions/blob/main/addOns/automation/src/main/java/org/zaproxy/addon/automation/VerificationData.java#L184-L200


public void initAuthenticationVerification(Context context, AutomationProgress progress) {
   AuthenticationMethod authMethod = context.getAuthenticationMethod();
   switch (this.getMethod().toLowerCase(Locale.ROOT)) {
     case METHOD_BOTH:
       authMethod.setAuthCheckingStrategy(AuthCheckingStrategy.EACH_REQ_RESP);
       break;
     case METHOD_RESPONSE:
       authMethod.setAuthCheckingStrategy(AuthCheckingStrategy.EACH_RESP);
       break;
     case METHOD_REQUEST:
        authMethod.setAuthCheckingStrategy(AuthCheckingStrategy.EACH_RESP);
        break;
     case METHOD_POLL:
        default:
        authMethod.setAuthCheckingStrategy(AuthCheckingStrategy.POLL_URL);
        break;
}

I haven't opened an issue yet because I am unsure if this is a bug or just not obvious, although it seems very likely.

I can provide some more details and create an issue if it is a bug and you need more context.

Cheers,
Max

[GOOD VIBBEOS]

I don't understand anything but I think you are on the right path!

You received this message because you are subscribed to the Google Groups "OWASP ZAP User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to zaproxy-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zaproxy-users/e592c426-f951-404a-ac8f-be039e249c81n%40googlegroups.com.

[Maximilian Schlosser]

To avoid misunderstandings:

I saw the issues you mentioned when rerunning the spider, with ZAP sending about 20 requests to authenticate for 50 crawl attempts. Looking at the messages themselves and the auth messages my script sent, it shows that ZAP was able to authenticate, but did not register it. Which is why I tried to figure out how the AF generated context differs from the existing one.

The packaged scan uses a handwritten context, largely based on an export. This has worked before and also works in the GUI, sending only a single auth request and then authenticated messages.