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. <davidjgonza...@gmail.com> 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)
>
