Fix auEngine mixed with POST and GET methods.

answered 2023-04-17 14:33:10 +0800

hawk
3185 ● 1 ● 5
http://hawkphoenix.blogsp...

ZK DhtmlUpdateServlet handles GET and POST in a unified way. Since zk client will fire an event with a POST request and get resources like *.wpd with a GET request.

You can see this in the code: DHtmlUpdateServlet.java#L459

I know there is a fact that an attacker might replace a POST request with GET (or PUT, HEAD) to avoid security checking. A web application usually checks POST requests more strictly because a POST request means a changing operation. And a web application might not check GET requests or not check other methods like PUT, HEAD. But this kind of attack doesn't work on ZK. The reason is, that this attack is mainly for some web apps that provide services for HTTP methods, such as web apps that provide restful APIs, each method (POST, PUT, GET...) directly corresponds to an application's operation. This type of web app has different handlers for different methods such as POST and GET. It is therefore possible to bypass the method-specific check by switching between different methods but with the same parameters.

ZK AU (asynchronous update based on AJAX) is the internal communication channel between the zk javascript widgets and a server. ZK widgets mainly send POST requests, but there are also a few GET requests. So in our implementation, these two requests are handled in the same way. You can check the DHtmlUpdateServlet doGet(), doPost() section in the source code.

When a zk widget sends these two requests (GET or POST), it will also include the desktop id and the element uuid of the related event, both of which are generated randomly and will be regenerated every time the page is reloaded. No matter what kind of request, zk will check whether these ids are valid. So ZK won't bypass the checking just because it's a GET request.

Moreover, zk au request also has a design to prevent external forgery, that is, unless it is the user himself, the outsiders cannot guess the current legal desktop ID and element UUID, and as long as the page is reloaded, both the id will be invalid, so there will be no long-term Time valid id. Please refer to Cross-site Request Forgery.

But we still consider to improve it: https://tracker.zkoss.org/browse/ZK-5142