Cross-Site Request Forgery (CSRF) in easysoft/zentaopms
Reported on
Dec 26th 2021
Description
Zentaopms 16.0 is vulnerable to CSRF in the delete functionality.
Proof of Concept
1 - Go to my section and create a my todo
2 - Browse to http://127.0.0.1/zentaopms/www/index.php?m=my&f=todo&type=all&userID=&status=all&orderBy=id_desc and take note of the ID in the first column.
3 - Create the following page (use the ID found at the step 2) and visit it in another browser tab while the admin is authenticated.
<html>
<body>
<img src="http://127.0.0.1/zentaopms/www/index.php?m=todo&f=delete&todoID=1&confirm=yes">
</body>
</html>
4 - The todo identified by the ID 1 will be deleted.
The vulnerability is present because the function ajaxDelete at https://github.com/easysoft/zentaopms/blob/master/www/js/my.full.js#L319 performs the delete operation using a GET request and no anti-CSRF token is used.
Impact
This vulnerability allows an attacker to force an end user to execute unwanted actions on the web application.
Remediation advices
For all the operations which change the state on the server (add, edit, delete, etc.):
1 - Use HTTP POST request
2 - Use unpredictable and cryptographically strong anti-CSRF token sent along with the POST request
Also set Samesite: Lax or Samesite: Strict for the cookie zentaosid.
Occurrences
front.class.php L920
<html>
<body>
<img src="http://127.0.0.1/zentaopms/www/index.php?m=my&f=deleteContacts&listID=1&confirm=yes">
</body>
</html>
The function confirm at https://github.com/easysoft/zentaopms/blob/master/lib/base/front/front.class.php#L920 performs e redirect at the okurl via self.location https://github.com/easysoft/zentaopms/blob/master/lib/base/front/front.class.php#L953 returned as javascript code at line https://github.com/easysoft/zentaopms/blob/master/lib/base/front/front.class.php#L981. Thus the delete action is performed via a GET request to http://127.0.0.1/zentaopms/www/index.php?m=my&f=deleteContacts&listID=6&confirm=yes.
Remediation advices
Same as for the first occurrence.
