[jira] [Commented] (OAK-1230) Write access control of "touched" content

["Michael Dürig (JIRA)" <ji...@apache.org>]

    [ 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)