Not sure if I should respond here with what we do with CQ5 but here goes. I consider CQ5 (or Sling) to be in the application tier so usually if it's going to serve internet facing content or functionality, then it has to be appropriated fronted by a web server in front which can do this whitelisting you're talking about depending on your needs. Most CQ5 installations will have Apache/IIS with CQ5 Dispatcher which will deny all access and open up set paths or resources. You could probably use mod_security, mod_rewrite to add more of this type of thing or any other reverse proxy server like squid or varnish. It really depends on what the site is trying to do.
On the server side, you absolutely do need some hardening in terms of ACLs and stuff like that. That just comes with installing any server (CMS or not) in production. Sarwar On Wed, May 2, 2012 at 4: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) > >
