[
https://issues.apache.org/jira/browse/OAK-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13833577#comment-13833577
]
Michael Dürig commented on OAK-1230:
------------------------------------
FTR the same came up for observation where touched properties would not cause
events to be fired (OAK-948). That one was resolved won't fix.
> 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)
