Step to reproduce

   <timer id="timer" onTimer='msg.setValue(System.currentTimeMillis()+"")'  delay="1000"/>
    <button label="start" onClick="timer.start()"/>
    <button label="stop" onClick="timer.stop()"/>
    <label id="msg" value="timestamp"/>

1. Grab a zk au POST request
2. According to the POST request and parameters, send a similar GET request and append the original parameters as query parameters

Use Postman to capture, modify, and resend an AU request:

Current Result

The response of this GET request is the same as POST, Security tool like Appscan judges it's "low risk".

Expected Result

The response is different from a POST request

Explanation

This test mainly targets an attack called "HTTP Verb Tampering" or "HTTP Method Tampering." In this attack, the attacker may replace a POST request with a GET (or PUT, HEAD) request to bypass security checks. Typically, web applications perform stricter checks on POST requests because a POST request implies a changing operation. However, some web applications may not check GET requests or other methods like PUT and HEAD.

Ref: https://resources.infosecinstitute.com/http-verb-tempering-bypassing-web-authentication-and-authorization/#gref

The reason for this result is that ZK's DhtmlUpdateServlet handles GET and POST requests in a unified way. The zk client engine fires events using POST requests and retrieves resources like *.wpd files using GET requests. You can see this in the code: DHtmlUpdateServlet.java#L459.

However, this kind of attack does not work on ZK due to the following reasons:

This attack is primarily aimed at web applications that provide services for different HTTP methods, such as RESTful APIs, where each method (POST, PUT, GET, etc.) directly corresponds to an application's operation. Such web applications have different handlers for different methods like POST and GET. It is possible to bypass method-specific checks by switching between different methods with the same parameters.
ZK's au (Asynchronous Update) is an internal communication channel between ZK JavaScript widgets and Java components. While ZK widgets mainly use POST requests, there are also some GET requests. In ZK's implementation, both types of requests are securely checked and handled in the same way. Therefore, the test results in the report show the same response for both GET and POST requests.
When a ZK widget sends these two types of requests, it includes the desktop ID and the element UUID related to the event, both of which are randomly generated and will be regenerated every time the page is reloaded. ZK checks whether these IDs are valid, regardless of the type of request (GET or POST), and drops any invalid request. As a result, ZK does not bypass the checking just because it's a GET request.

Furthermore, zk au requests are designed to prevent external forgery. Only the users themselves can have access to the current valid desktop ID and element UUID, and both IDs become invalid whenever the page is reloaded, making them short-lived and non-predictable for external attackers. This helps prevent Cross-Site Request Forgery (CSRF) attacks.

In conclusion, ZK's design and handling of requests help mitigate the risk of HTTP Verb Tampering attacks.

Proposed solution

While this is not a real concern, we can still improve the framework by separating things handled by DHtmlUpdateServlet into doGet() and doPost().
doGet() processes requests for resources like wpd, wcs...
doPost() processes au requests for events.