Sarwar, Real-life experience with any sling-based apps are welcome - CQ included! :)
First off - thanks for your response! I can appreciate locking down content trees and verbs (GET/POST) on the web server/reverse proxy side - however that doesn't address my primary concerns. My concerns are more around resources that SHOULD allow POSTs to manipulate data. I'll argue that creating a whitelist of query (read input) params belongs in the app rather than a reverse proxy config. Using tools like mod_security/mod_rewrite to inspect query params and (:operation, and property names, etc) seems extremely brittle and requires very tight coupling between the app and the web server config -- and could even start spilling "logic" into web server configs. CQ seems most often used as a content delivery platform rather than web app platform that manages a wide variety of user input - however there is really no reason is couldn't be used as such. Understanding how the SlingPostServlet should/shouldn't be leveraged is critical to the success of these types of "web app oriented" sling-based implementations though. I guess I'm most interested in your thoughts around your comment: "you absolutely do need some hardening in terms of ACLs and stuff like that." -- specifically "stuff like that" (considering ACLs will only get you so far) with regards to the SlingPostServlet behavior :) -- David Gonzalez Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Wednesday, May 2, 2012 at 12:23 PM, Sarwar Bhuiyan wrote: > 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] > (mailto:[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) > > > > >
