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

["angela (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13921041#comment-13921041 ] 

angela commented on OAK-1230:
-----------------------------

note that move operations (except for the special cases listed as know issues) are detected now within the permission evaluation and dealt with in a backwards compatible way.

> 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
>            Assignee: angela
>              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.2#6252)