[
https://issues.apache.org/jira/browse/JCR-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-5261:
--------------------------------
Description:
_*Session Fixation / Session Reuse across Users vulnerability in Apache
Jackrabbit.*_
_*Jackrabbit WebDAV server attaches a cached authenticated session on any
Lock-Token/TransactionId/SubscriptionId/If-header field token match with no
credential check.*_
In Oak in general, and in Jackrabbit for session locks, WebDAV token are
calculated directly from node paths. Using predictable paths creates compliance
and collision issues:
# RFC 4918 (Section 6.5) requires lock tokens to be strictly unique across all
resources and all time. Path-based tokens fail this rule.
# The same node path on two different Oak instances generates the exact same
lock token, causing unintended matches across environments.
# Anyone who knows a node's path can easily guess its lock token (Jackrabbit:
session locks, Oak: all).
Changing the repo's token design is difficult. Moving away from path-based
tokens means generating random IDs, which must be saved as node updates. Thus a
temporary mapping in the WebDAV Server component will avoid these issues both
for both Jackrabbit and Oak.
was:
In Oak in general, and in Jackrabbit for session locks, WebDAV token are
calculated directly from node paths. Using predictable paths creates compliance
and collision issues:
# RFC 4918 (Section 6.5) requires lock tokens to be strictly unique across all
resources and all time. Path-based tokens fail this rule.
# The same node path on two different Oak instances generates the exact same
lock token, causing unintended matches across environments.
# Anyone who knows a node's path can easily guess its lock token (Jackrabbit:
session locks, Oak: all).
Changing the repo's token design is difficult. Moving away from path-based
tokens means generating random IDs, which must be saved as node updates. Thus a
temporary mapping in the WebDAV Server component will avoid these issues both
for bothJackrabbit and Oak.
> Pre-auth hijack of cached sessions via derivable WebDAV lock tokens (WebDAV
> lock tokens violate specs due to path-based generation)
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: JCR-5261
> URL: https://issues.apache.org/jira/browse/JCR-5261
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server
> Affects Versions: 2.20.17, 2.22.4, 2.23.5
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Critical
> Fix For: 2.20.18, 2.23.6, 2.22.5
>
>
> _*Session Fixation / Session Reuse across Users vulnerability in Apache
> Jackrabbit.*_
> _*Jackrabbit WebDAV server attaches a cached authenticated session on any
> Lock-Token/TransactionId/SubscriptionId/If-header field token match with no
> credential check.*_
> In Oak in general, and in Jackrabbit for session locks, WebDAV token are
> calculated directly from node paths. Using predictable paths creates
> compliance and collision issues:
> # RFC 4918 (Section 6.5) requires lock tokens to be strictly unique across
> all resources and all time. Path-based tokens fail this rule.
> # The same node path on two different Oak instances generates the exact same
> lock token, causing unintended matches across environments.
> # Anyone who knows a node's path can easily guess its lock token
> (Jackrabbit: session locks, Oak: all).
> Changing the repo's token design is difficult. Moving away from path-based
> tokens means generating random IDs, which must be saved as node updates. Thus
> a temporary mapping in the WebDAV Server component will avoid these issues
> both for both Jackrabbit and Oak.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
