sling-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David G." <davidjgonza...@gmail.com>
Subject SlingPostServlet - Real-world concerns and general thoughts. Discussion encouraged!
Date Wed, 02 May 2012 15:47:18 GMT

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)


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message