Hi David I definitifely agree with you that the configuration if the webserver (Apache/IIS/...) should not contain any application logic. The configuration should only harden the already existing security of the application itself.
I think the problem you mentioning is less about filters but more about ACLs. We discussed ACLs in Sling a few months ago [1]. I feel confident that we rather should solve the ACLs for READ the same way as the ACLs for WRITE, MODIFY and DELETE. [1] http://markmail.org/thread/x77vyc3shinxdxof best regards mike > -----Original Message----- > From: Julian Sedding [mailto:[email protected]] > Sent: Wednesday, May 02, 2012 7:12 PM > To: [email protected] > Subject: Re: SlingPostServlet - Real-world concerns and general thoughts. > Discussion > encouraged! > > Hi David > > This is an interesting question and I consider the concerns you > mention absolutely valid. I have been thinking about this problem > before, but never got around to implementing/prototyping my ideas. In > a SlingPostProcessor, the changes should not yet be persisted, so it > should be possible to do a session.refresh(true), in order to reset > the session. Alternatively, I imagine that you could throw an > exception from a SlingPostProcessor, and have the action aborted. This > would need testing though. > > My preferred idea would be a Filter implementation (scope request) > that checks whether the POST'ed parameters are allowed (and possibly > also whether they are valid). The allowed parameters (and validations) > could be described by a resource-type dependent description, which > could be expressed by a node structure. A contrived example: > > /apps/sample/comment > /comment.jsp > /properties > /email (validate=email, mandatory=true) > /website (validate=url) > /text (validate=length, min=20, max=500) > > The filter implementation would then only allow POSTs where the > allowed parameters correspond to the configured properties. Different > validation implementations could be hooked in as OSGi services, > identified by name (e.g. email, url, length) and consuming any given > supplemental properties (e.g. min, max). > > Of course there is more to it, e.g. how do you handle POSTs that > create intermittent nodes, i.e. "./node/property=value", how do you > deal with uploads etc. It should be possible to accommodate these into > whatever description of the allowed (white-listed) properties, > however. > > Do you see the need for a use-case, where POST validation would not be > "per resource-type"? > > Regards > Julian > > > On Wed, May 2, 2012 at 5:47 PM, David G. <[email protected]> wrote: > > > > I thought i'd throw this out there as I've been mulling it over for a while. > > > > Sling is a pretty powerful framework, and one of its most powerful pieces > > is the > SlingPostServlet, which provides a client-based interface for manipulating > data. > > > > Now, the SlingPostServlet seems very powerful and very useful in a trusted > environment - for example, on the authoring side of sling-based CMS ;) -- > where > there is some amount of trust that the folks w access won't fire up a REST > client and > start shooting off operations (assuming they enjoy gainful employment). > > > > When you expose the SlingPostServlet to the public (internet) things seem > > like they > can get dicey. For example, if I find a set of nodes that that are writeable > to me (say > under my profile, or some suer generated content tree) I could start adding > unexpected data, like unexpected properties that could show up in public > representations of the resource (XML, JSON, etc.) or moving/renaming nodes, > etc. > > > > There are a couple ways to help mitigate this: > > 1) Ensure all the correct permissions are applied to the resources in > > question > (however this only helps prevent certain operations - if a resource is > writable, > permissioning won't restrict what properties I can write to it) > > 2) Create SlingPostProcessors that handle all the various conditions - > > PostProcessors > are executed after the POST operation has taken place, and I'm not aware of a > way to > tell Sling to revert all changes and fail the operation. > > 3) Create workflows/eventhandlers that perform some sort of async data > verification/scrubbing - I don't like this sort of async as bad things can > still happen to > the data, and its difficult to alert the client of an issue. > > > > Which leaves creating POST servlet/jsp handlers for each resource-type to > > handle > data manipulation, which will be used in lieu of the SlingPostServlet. > > > > TLDR > > > > My problem in using the SlingPostServlet requires you to develop > > (conceptually) a > blacklist of behaviors/operations/data that should not be allowed - rather > than a > whitelist -- and I hope most of us will concede that a whitelist is (almost) > always > better than a blacklist when it comes to managing security. > > > > > > Am i missing something here? > > > > Does anyone have examples of actual Prod sites where the SlingPostServlet is > heavily leveraged to allow public clients manipulate data? > > > > I'd love to hear everyone's thoughts and how they've handle similar > > situations. > > > > -- > > David Gonzalez > > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > >
