How do you intend to prevent unauthorizrd users from creating a readable resource with that resource type?
Especially with the nt:unstructured data models that are so popular? Maybe I don't fully follow what the general use cases are where a http client would need this information. Is this capabilities data something that would be more appropriate to expose from a plugin to the web console or perhaps protected by some other role based access control? Regards, Eric On Thu, Jun 21, 2018, 6:29 AM Bertrand Delacretaz <[email protected]> wrote: > Hi, > > On Wed, Jun 20, 2018 at 9:47 PM Eugen Stan <[email protected]> wrote: > > On 20.06.2018 19:02, Eric Norman wrote: > > >... It seems to me that there a risk that this endpoint could leave the > system > > > vulnerable to an information disclosure attack. > > > > > I was thinking the same thing. I think this should be protected and of > > course the risks of exposing this endpoint should be documented. .. > > You are right! > > I think we have discussed a few times how to restrict the execution of > certain servlets like this one, as currently any user who can create a > node with the sling/capabilities resource type can get access to that > information. > > But we didn't come to a firm conclusion AFAIR. > > To prevent this I can use a "shadow permissions resource" at a > configurable path, defaulting to > /libs/sling/permissions/capabilities/read > > The CapabilitiesServlet can then require that resource to be present > and readable by the current user, and return a 403 Forbidden status if > not. > > How does that sound? > > If people like this idea we might document it as a recommended pattern > for such cases. > > -Bertrand >
