Jukka Zitting created OAK-1230:
----------------------------------
Summary: 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
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)
