[
https://issues.apache.org/jira/browse/OAK-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13833583#comment-13833583
]
angela commented on OAK-1230:
-----------------------------
and the same arises with the move-permission story:
if a tree structure is moved away and the identical structure is re-created at
the original source (not even modifying the child-order), the is now a way to
detect that there was a move but the permission validator will not detect that
the replacement tree has been created. currently i am inclined to ignore this
in order to keep it consistent with any other kind of validation. *if* we
wanted to address this we have to re-evaluate the option of using a changelog
as michael suggested at the very early days of the oak project.
we can discuss this again at the next oakathon but if we decided to resolve
this kind of issues as wontfix we should update the diff-documentation such
that it's really clear for everyone what the implications are.
> Write access control of "touched" content
> -----------------------------------------
>
> Key: OAK-1230
> URL: https://issues.apache.org/jira/browse/OAK-1230
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: Jukka Zitting
> Labels: security
>
> Following up from OAK-928 and OAK-948 to clarify the interesting case of
> updates that set a property (or a broader subtree of content) to the exact
> same value that it used to have.
> Since such "touching" of content results in an empty content diff, the
> {{PermissionValidator}} doesn't get invoked and thus write access controls
> are not checked. Additionally (as reported in OAK-948) no observation events
> get sent for such updates. This seems like a reasonable thing to do, as if
> nothing changes there should be no need to check for write access or to
> inform observation listeners.
> However, OAK-928 makes this case trickier, as it opens a possibility to use
> brute force to circumvent read access controls for certain kinds of content.
> For example, if an attacker knows (or can guess) the existence of a certain
> read/write-protected property (e.g. some sensitive configuration setting),
> it's possible to repeatedly try to update that property with different likely
> values. Normally the update would fail with an exception because of the write
> protection, but when the attempted update matches the stored value there
> would be no exception because no change gets detected. At that point the
> attacker would know what the stored value is!
> The above scenario is somewhat artificial as it only works for highly
> specific cases, so I'm not sure how important it is for us to address this
> case at the repository level.
> If we don't address this then a simple workaround for security-sensitive
> content would be to deny read access to the whole containing node and add a
> property containing a random value along the sensitive information. That
> would make it impossible for the attacker to use this mechanism to guess the
> sensitive bits, as they'd also need to guess what the random value is.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
