Fuzzer seems to ignore "set-cookie" response header

Describe the bug

I performed a successful manual SQLi attack (using the Manual Explore feature). During this manual exploration, the History tab exhibits the following information regarding cookies and anti-CSRF:

(notice: each picture shows a different HTTP request. The blue boxes were used to show, at the same time, the Request and the Response tabs pertaining to this request).

---

---

---

---

Fort short, it shows that my Firefox browser correctly sets up a new session cookie when requested by the server-side application (request 142), and that the form-originated POST request (145) correctly includes the Anti-CSRF token generated by the server-side application (request 143), while still sticking to the session cookie that was previously set up.

---

On the other hand, trying to automate the same SQLi attack using the Fuzzer yields a radically different result, which ultimately results in receiving a series of HTTP 400 errors (“Invalid CSRF token (session does not contain a CSRF token)”) from the server-side application. The issue here seems to be the fact that the Fuzzer will always try to reuse the same session cookie, i.e. the one from the original message (task ID 0), completely ignoring the set-cookie HTTP headers along the responses that follow.

In pink: the ignored set-cookie attempts by the server-side application

In red: the incorrect cookie passed by the Fuzzer, reused from the original request

---

---

---

---

Is this the expected behavior? Is there a setting somewhere to change this default behavior?

Steps to reproduce the behavior

1. Perform a manual/automated exploration in order to generate the initial request for the Fuzzer attack.
2. On the history tab, right click the desired request, then pick Attack > Fuzz.
3. Select the text segment from the original request where the Fuzzer will perform the automated substitution, then proceed to the usual Payload configuration.
4. Still on the Fuzzer window, go to the Message Processors tab, then make sure Anti-CSRF Token Refresher is on the list. 4.1. In order to obtain additional debug info, I also double clicked the Anti-CSRF Token Refresher line, then checked the “Show token requests” checkbox.

1. Start Fuzzer

Expected behavior

I expected the Fuzzer to refresh the session request cookie with each set-cookie HTTP response header received during the fuzzing operation.

The Fuzzer already correctly refreshes the Anti-CSRF token, that it obtains from the response body of the previous HTTP request. It should also catch the new session cookie specified by the server-side application, to use it along with the updated Anti-CSRF token. This way, the server-side app would detect the session token successfully.

Software versions

OWASP ZAP Version: 2.11.1

Installed Add-ons: [[id=alertFilters, version=13.0.0], [id=ascanrules, version=46.0.0], [id=automation, version=0.15.0], [id=bruteforce, version=11.0.0], [id=callhome, version=0.3.0], [id=commonlib, version=1.9.0], [id=custompayloads, version=0.11.0], [id=diff, version=11.0.0], [id=directorylistv1, version=5.0.0], [id=domxss, version=12.0.0], [id=encoder, version=0.6.0], [id=exim, version=0.1.0], [id=formhandler, version=4.0.0], [id=fuzz, version=13.6.0], [id=fuzzdb, version=8.0.0], [id=gettingStarted, version=13.0.0], [id=graaljs, version=0.2.0], [id=graphql, version=0.9.0], [id=help, version=14.0.0], [id=hud, version=0.13.0], [id=importurls, version=9.0.0], [id=invoke, version=11.0.0], [id=network, version=0.2.0], [id=oast, version=0.10.0], [id=onlineMenu, version=9.0.0], [id=openapi, version=27.0.0], [id=pscanrules, version=40.0.0], [id=quickstart, version=33.0.0], [id=replacer, version=9.0.0], [id=reports, version=0.10.0], [id=retest, version=0.2.0], [id=retire, version=0.10.0], [id=reveal, version=4.0.0], [id=saverawmessage, version=7.0.0], [id=savexmlmessage, version=0.3.0], [id=scripts, version=30.0.0], [id=selenium, version=15.8.0], [id=soap, version=13.0.0], [id=spiderAjax, version=23.7.0], [id=sqliplugin, version=15.0.0], [id=tips, version=9.0.0], [id=webdriverlinux, version=37.0.0], [id=websocket, version=25.0.0], [id=zest, version=35.0.0]]

Operating System: Linux Java Version: Ubuntu 11.0.11 System’s Locale: en_US Display Locale: en_GB Format Locale: en_US ZAP Home Directory: /home/rui/.ZAP/ ZAP Installation Directory: /snap/zaproxy/8/./ Look and Feel: FlatLaf Light (com.formdev.flatlaf.FlatLightLaf)

Screenshots

No response

Errors from the zap.log file

No response

Additional context

No response

Would you like to help fix this issue?

• Yes

[ruipimentel]

Hi, folks, I was able to successfully fuzz my application with the unmodified version of OWASP ZAP, after some debugging of the original source code 🤣 🤣 🤣

However, the solution seems really hacky.

For short, while manually exploring the web app, not only did I submit the form (generating the POST URL which will be fuzzed later on), but also forced a page reload after that. This seems to make the anticsrf extension register this last (GET to same URL) message as the token generator, and when the fuzzer extension is called via right click over this URL, it makes a call to this.acsrfToken.getMsg().cloneAll(), and consequently gets the correct source message to call.

Is this by design? Is actually the Anti-CSRF extension the one responsible for the Anti-CSRF Token Refresher call, and is this call simply a clone of the last HTTP request that generated an Anti-CSRF token? Should the GET message really modify the behavior of the right click over the POST URL on the “Sites” tab?

If so, I volunteer to increment documentation of the Fuzzer add-on in order to explicitly address these points, and also the session management one. Any additional comments/knowledge on them would also be highly appreciated! 😃

Thank you again!

[kingthorin]

Okay, thanks for trying.