Hello David Please find some comments inline.
On 05/02/2012 05:47 PM, David G. 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). It's not too much about trust, but more about authorization. You define where authors can write to by setting repository ACLs. > > 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. If you find a node that is (explicitly) writeable to you it is just that. Data added there should not be unexpected, or you have a problem with your ACLs. There's nothing the POST servlet can or should do about that. > 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) For access control on a property level you can either use a globbing ACL or structural restrictions in the node type definition. But again: If a node is writeable to you, there must be reason for 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. I am not sure I really understand your point. I believe there is no need for additional input verification/scrubbing. Can you maybe give an example? > > Which leaves creating POST servlet/jsp handlers for each resource-type to > handle data manipulation, which will be used in lieu of the SlingPostServlet. But only for the (imo rare) cases that could not be handled by ACLs / node types? Even UGC is usually created by authenticated users only. > > 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. I'm all for whitelists. But IMO this is exactly how it works now. Set deny all on / for everyone - and then reopen what you need. What operations do you have in mind? Cheers Lars
