Details
Major Description
Following issues lead to CSRF:
1.Jackrabbit-webdav processes POST requests as PUT requests. Handler doPost invokes doPut in code of org.apache.jackrabbit.webdav.server.AbstractWebdavServlet class.
2.There is CSRF protection based on Referer header - https://issues.apache.org/jira/browse/JCR-3036. This protection could be bypassed, because it allows requests with omitted Referer header. It is possible to strip referer by creating an iframe with Javascript in src attribute. It works because javascript is executed in context of about:blank page.
Attack scenario:
1. Attacker creates following HTML page:
<h1>CSRF PoC</h1>
<iframe src="javascript:document.write('<form method=post enctype=\'text/plain\' action=\'http://127.0.0.1:8080/jackrabbit-webapp-custom/repository/default/evil\'><input type=\'hidden\' name=\'EvilContent\'/></form>');document.forms[0].submit();"></iframe>
2. If victim previously used browser to access jackrabbit-webdav and opens attacker's page than node "evil" with content "EvilContent=" will be created on victim's behalf.
Proposed fix:
Jackrabbit-webdav should return 405 Method Not Allowed for POST requests by default. When POST requests are required robust CSRF protection must be implemented. At least omitted Referer should be prohibited for POST requests. Referer based protection considered weak, because it is possible to completely bypass Referer-based protection for IE browser using Java Applets or PDF files. The best option for CSRF protection is CSRF tokens.
CVSS:
2.6 (AV:N/AC:H/Au:N/C:N/I
/A:N)
Attachments
Issue Links
- is related to
-
JCR-4002 CSRF in Jackrabbit-Webdav using empty content-type (CVE-2016-6801)
-
- Closed
-