Hi, Replying to Jörg but I think this addresses Eric's concerns as well.
On Thu, Jun 21, 2018 at 9:24 PM Jörg Hoh <[email protected]> wrote: > ...this approach of using a shadow permission resource doesn't sound well for > me. I think that binding servlets to a resource type always gives anyone > with write access to the repo the chance to create a resource with any > resourcetype and then get the servlet executed. If we consider this a way > which we should protect ourselves against, we should come up with a > dedicated design and nothing ad-hoc; because then we have to secure quite > some functionality.... With the current code, the exploit scenario is as follows: a. CapabilitiesServlet is mounted on the sling/capabilities resource type, by default b. A resource is created under /bin/capabilities with that resource type, suitably protected to avoid information disclosure c. Attacker creates a resource under /content/theirsubtree/foo with that resource type d. Attacker requests /content/theirsubtree/foo.json and reads the CapabilitiesServlet output, which they were not meant to see What I'm suggesting is that the servlet always checks a resource at a configurable path, like /sling/permissions/capabilities/read, and returns a 403 forbidden status if the current user cannot read that resource. The /sling/permissions path is suitably protected so that non-admin users cannot write under it. In this way, step d. above will fail. Eric, does this explain the mechanism better? Jörg, I understand this feels like ad-hoc security, but we might implement such "sling permissions check" with a service to define this as a standard pattern? Or do you have another suggestion? The overall goal is to restrict access to servlets when users can create resources that point to them. -Bertrand
