Proposal: Race Condition detection add-on for ZAP Marketplace — architecture advice needed

[Mohand Amokrane Meghaoui]

Hi everyone, I’m currently exploring the idea of developing a ZAP add-on for testing web application race conditions, with the goal of eventually publishing it on the ZAP Marketplace. My motivation is that Burp Suite currently provides dedicated functionality for race-condition testing, including synchronization techniques such as Single-Packet Attack (SPA) and last-byte synchronization, while I haven’t found an equivalent workflow in ZAP. The idea is to take an HTTP request from ZAP, allow the user to configure multiple concurrent executions, and provide synchronization mechanisms specifically designed for race-condition testing. I’m also interested in supporting HTTP/2, where synchronization may need to operate at the stream/frame level rather than simply sending requests concurrently. I’ve been looking through the ZAP extension and active-scan-rule architecture, but I’m not sure which approach would be most appropriate for this type of functionality. Would you recommend implementing this primarily as a general ZAP Extension within an Add-on, or is there an existing component/API I should build on? I’d also appreciate any guidance on the appropriate ZAP HTTP/networking APIs for achieving the synchronization required by SPA and last-byte synchronization, as well as any architectural considerations I should keep in mind if I intend to publish the add-on on the Marketplace.  

[psiinon]

Hiya,

Thanks for getting in touch.

We do not have this functionality in ZAP right now, so very keen to help you work on this :D

We recommend that new functionality like this is implemented in your own add-on, as per https://www.zaproxy.org/docs/guides/how-to-publish-a-zap-addon/

Whether it should be an active scan rule or not really depends on how you see it working.

If its going to implement a set of tests that typically apply to any requests related to a site, and as long as it will not take too long to run against the whole site, then an active scan rule may well be appropriate.

If its something that needs more manual guidance (like fuzzing for example) then it probably should not be an active scan rule, as they are harder for a user to directly interact with.

Re the HTTP/networking APIs - let us know what you're looking for in a bit more detail and then we'll do our best to help!

Many thanks,

Simon

[Mohand Amokrane Meghaoui]

Sorry for the late response, I’ve been a bit busy with university.

I’m planning to implement this as a manual tool rather than an active scan rule, since race-condition testing generally requires the user to select the requests, configure the number of concurrent executions, and choose the synchronization technique.

Regarding the HTTP/networking APIs, I’m specifically looking for low-level control over how requests are transmitted. For HTTP/2, I’d like to implement a Single-Packet Attack (SPA). This requires preparing multiple HTTP/2 requests on separate streams and controlling the transmission of their frames so that the relevant frames from multiple streams can be sent together in a single TCP packet, allowing the requests to reach the server as closely together as possible.

For HTTP/1.1, I’d like to implement last-byte synchronization. The idea is to establish a separate TCP connection for each request and send each request up to its final byte, while holding the final byte back until all of the connections are ready. The final byte can then be released on each connection as closely together as possible, minimizing the timing difference between the requests reaching the server.

So I’m mainly looking for guidance on whether ZAP exposes APIs that provide sufficient control over HTTP/2 frame transmission and the underlying TCP connections/writes for HTTP/1.1, or whether implementing these synchronization techniques would require working below ZAP’s normal HTTP client/networking abstractions within the add-on.