You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by "David G." <da...@gmail.com> on 2012/05/02 17:47:18 UTC
SlingPostServlet - Real-world concerns and general thoughts.
Discussion encouraged!
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)
RE: SlingPostServlet - Real-world concerns and general thoughts.
Discussion encouraged!
Posted by Mike Müller <mi...@mysign.ch>.
Hi David
Maybe you missunderstood me. The idea in the linked thread is NOT implemented
at this time. But the idea discussed there could also be the solution for your problem.
The main idea is, that you can plug in any kind of ACL which is not covered by the JCR -
so even special ACLs on properties or, as in the thread mentioned, eg. access from
8.00 to 17.00 to the resource could be implemented, because you can implement it
in Java code. The only thing you have to do is to register something like a
ResourceAccessController. But as said, this is not implemented yet.
My suggestion was, not to implement something new which only covers the
SlingPostServlet-case but introduce real ACLs for all actions (CRUD).
best regards
mike
> -----Original Message-----
> From: David G. [mailto:davidjgonzalez@gmail.com]
> Sent: Wednesday, May 02, 2012 11:13 PM
> To: users@sling.apache.org
> Subject: Re: SlingPostServlet - Real-world concerns and general thoughts.
> Discussion encouraged!
>
> Mike,
>
> I read through the thread you linked to and it appears that the
> "ACLAwareResourceProvider" was an idea that Carsten floated but isn't
> implemented (I can't find the interface in the sling github proj at least, or any docs
> around it).
>
> Without thinking too hard about how ACLs can be used to manage this type of
> thing, it seems like modeling and applying the ACLs would get messy (difficult to
> maintain) -- also, I dont believe ACLs be applied on a property level in the JCR.
> Here's a list of the available privileges:
> http://www.day.com/maven/jsr170/javadocs/jcr-2.0/constant-
> values.html#javax.jcr.security.Privilege.JCR_ADD_CHILD_NODES
> Even with ACLs on the node level, I don't see how you could only allow certain
> child-nodes (named in a certain way, or with certain properties, etc.) to be added
> to a node by a client.
>
> Each resource type could have its own requirements on how it can be manipulated
> in VERY specific ways - I'm having a difficult time seeing how ACLs are flexible
> enough provide a robust real-world solution to using the SlingPostServlet.
>
> Have you seen this done on a large-scale in the wild? Ive very interested in seeing
> "proven" solutions to this issue - as the devils are in the implementation details :)
>
> --
> David Gonzalez
> Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
>
>
> On Wednesday, May 2, 2012 at 3:21 PM, Mike Müller wrote:
>
> > Hi David
> >
> > I definitifely agree with you that the configuration if the webserver
> (Apache/IIS/...)
> > should not contain any application logic. The configuration should only harden
> > the already existing security of the application itself.
> >
> > I think the problem you mentioning is less about filters but more about ACLs.
> > We discussed ACLs in Sling a few months ago [1].
> >
> > I feel confident that we rather should solve the ACLs for READ the same
> > way as the ACLs for WRITE, MODIFY and DELETE.
> >
> >
> > [1] http://markmail.org/thread/x77vyc3shinxdxof
> >
> >
> > best regards
> > mike
> >
> >
> > > -----Original Message-----
> > > From: Julian Sedding [mailto:jsedding@gmail.com]
> > > Sent: Wednesday, May 02, 2012 7:12 PM
> > > To: users@sling.apache.org (mailto:users@sling.apache.org)
> > > Subject: Re: SlingPostServlet - Real-world concerns and general thoughts.
> Discussion
> > > encouraged!
> > >
> > > 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. <davidjgonzalez@gmail.com
> (mailto:davidjgonzalez@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)
> > > >
> > >
> > >
> >
> >
> >
> >
>
Re: SlingPostServlet - Real-world concerns and general
thoughts. Discussion encouraged!
Posted by "David G." <da...@gmail.com>.
Mike,
I read through the thread you linked to and it appears that the "ACLAwareResourceProvider" was an idea that Carsten floated but isn't implemented (I can't find the interface in the sling github proj at least, or any docs around it).
Without thinking too hard about how ACLs can be used to manage this type of thing, it seems like modeling and applying the ACLs would get messy (difficult to maintain) -- also, I dont believe ACLs be applied on a property level in the JCR. Here's a list of the available privileges: http://www.day.com/maven/jsr170/javadocs/jcr-2.0/constant-values.html#javax.jcr.security.Privilege.JCR_ADD_CHILD_NODES
Even with ACLs on the node level, I don't see how you could only allow certain child-nodes (named in a certain way, or with certain properties, etc.) to be added to a node by a client.
Each resource type could have its own requirements on how it can be manipulated in VERY specific ways - I'm having a difficult time seeing how ACLs are flexible enough provide a robust real-world solution to using the SlingPostServlet.
Have you seen this done on a large-scale in the wild? Ive very interested in seeing "proven" solutions to this issue - as the devils are in the implementation details :)
--
David Gonzalez
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Wednesday, May 2, 2012 at 3:21 PM, Mike Müller wrote:
> Hi David
>
> I definitifely agree with you that the configuration if the webserver (Apache/IIS/...)
> should not contain any application logic. The configuration should only harden
> the already existing security of the application itself.
>
> I think the problem you mentioning is less about filters but more about ACLs.
> We discussed ACLs in Sling a few months ago [1].
>
> I feel confident that we rather should solve the ACLs for READ the same
> way as the ACLs for WRITE, MODIFY and DELETE.
>
>
> [1] http://markmail.org/thread/x77vyc3shinxdxof
>
>
> best regards
> mike
>
>
> > -----Original Message-----
> > From: Julian Sedding [mailto:jsedding@gmail.com]
> > Sent: Wednesday, May 02, 2012 7:12 PM
> > To: users@sling.apache.org (mailto:users@sling.apache.org)
> > Subject: Re: SlingPostServlet - Real-world concerns and general thoughts. Discussion
> > encouraged!
> >
> > 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. <davidjgonzalez@gmail.com (mailto:davidjgonzalez@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)
> > >
> >
> >
>
>
>
>
RE: SlingPostServlet - Real-world concerns and general thoughts.
Discussion encouraged!
Posted by Mike Müller <mi...@mysign.ch>.
Hi David
I definitifely agree with you that the configuration if the webserver (Apache/IIS/...)
should not contain any application logic. The configuration should only harden
the already existing security of the application itself.
I think the problem you mentioning is less about filters but more about ACLs.
We discussed ACLs in Sling a few months ago [1].
I feel confident that we rather should solve the ACLs for READ the same
way as the ACLs for WRITE, MODIFY and DELETE.
[1] http://markmail.org/thread/x77vyc3shinxdxof
best regards
mike
> -----Original Message-----
> From: Julian Sedding [mailto:jsedding@gmail.com]
> Sent: Wednesday, May 02, 2012 7:12 PM
> To: users@sling.apache.org
> Subject: Re: SlingPostServlet - Real-world concerns and general thoughts. Discussion
> encouraged!
>
> 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. <da...@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)
> >
Re: SlingPostServlet - Real-world concerns and general thoughts.
Discussion encouraged!
Posted by Julian Sedding <js...@gmail.com>.
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. <da...@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)
>
Re: SlingPostServlet - Real-world concerns and general thoughts.
Discussion encouraged!
Posted by Sarwar Bhuiyan <sa...@gmail.com>.
One thing I hadn't mentioned is that when you have specific resources that
require GET/POST/PUT/DELETE, you will most likely be writing servlets
extending SlingSafeMethodsServlet or SlingAllMethodsServlet which cater to
that specific resource type, selector, extension. You can even register
sling servlets which get triggered on a specific path. SlingPostServlet is
the default servlet which would handle a request for which it couldn't find
another servlet or script so it's not your only one. Best thing to do is
download the Sling source and look at all kinds of sling servlet examples.
Some docs here (http://sling.apache.org/site/servlets.html)
The other way is writing custom Resource Providers but that's more for when
you want to serve resources which aren't JCR resources.
I've been on projects where CQ5 has been used as a platform delivering an
HTTP API (accepting GET/POST/PUT requests) for custom content lifecycle
functions. So it can definitely be used as such because of Sling and OSGi.
I developed a lot of those SlingSafeMethodsServlet and
SlingAllMethodsServlet classes for that.
Where CQ5 excels is that a lot of the CQ5 specific components (dialogs,
client library manager, workflows, versioning, search API, query builder
etc) are also at your disposal so you don't have to reinvent the wheel in
many cases.
Sarwar
On Wed, May 2, 2012 at 5:40 PM, David G. <da...@gmail.com> wrote:
> 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. <davidjgonzalez@gmail.com(mailto:
> davidjgonzalez@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)
> > >
> >
> >
> >
>
>
>
Re: SlingPostServlet - Real-world concerns and general
thoughts. Discussion encouraged!
Posted by "David G." <da...@gmail.com>.
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. <davidjgonzalez@gmail.com (mailto:davidjgonzalez@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)
> >
>
>
>
Re: SlingPostServlet - Real-world concerns and general thoughts.
Discussion encouraged!
Posted by Sarwar Bhuiyan <sa...@gmail.com>.
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. <da...@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)
>
>
Re: SlingPostServlet - Real-world concerns and general
thoughts. Discussion encouraged!
Posted by "David G." <da...@gmail.com>.
Lars - thanks for the feedback - i look forward to your extended answers.
When you mention "handlers" .. do you mean creating custom servlets/JSPs to handle the POST requests?
Or create custom overriding supporting implementations for:
SlingPostProcessor
PostOperation
NodeNameGenerator
PostResponseCreator
ContentImporter
and allowing the SlingPostServlet to use those to handle custom impl?
The reason I ask is ideally the "SlingPostServlet API pattern" would be used across all calls -- Adding divergent custom APIs for specific resources makes for a less maintainable app.
Thanks
--
David Gonzalez
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Thursday, May 3, 2012 at 12:10 PM, Lars Krapf wrote:
> Hello David
>
>
> > Ah - this is what i'm looking for. Can you expound on "globbing ACL"?
> > I was under the impression globbing ACLs were merely on the Node level. Could you enforce permissioning on the property level using this as well?
> >
>
>
> Yes. The rep:globs work on property level.
> You can for example set deny jcr:write on a node and then add
> allow jcr:write with globbing on jcr:title to allow writing
> to the title property only.
>
> >
> > I assume a structural restriction is setting a node to be a certain node type which enforces certain properties? Does this cause existing nodes to become inflexible? Once a node type, always a node type?
>
> There is some flexibility.
> The node type is a protected property. (e.g. you can only change
> it using the API call "setPrimaryType")
> Additionally you could add a mix-in type to the node to extend
> its functionality.
>
> > I think an example would be very helpful.
> >
> > My sample requirement is: Allow users to post comments with an optional supporting links (Properties: title, body, link). Title and Body are required, Link is optional. Once a comment is written Title and Body cannot be edited, but the Link can be changed by the original-submitter if it was not previously submitted. Upon success the user is displayed a "thank you" page, on error the user is returned to the comment form with the offending fields denoted and the previously submitted values repopulated.
> >
> > The "Title" must be alpha-numeric, non-empty and unique across comment titles.
> > The "Body" must be alpha-numeric, non-empty.
> > The "Link" is optional, but if provided must be a well formed URL and responds to a GET with a 200 response.
> > "sling:resourceType" must be "mysite/components/comment"
> > "jcr:primaryType" must be "nt:unstructured"
> >
> > The only properties allowed on the node are as listed above (these resources will be consumed via a browser as HTML and as JSON for access by external clients).
> >
> > Using the SlingPostServlet and ACLs how can this requirement be met?
>
> I will have to get back to you on this.
> Short answer: I don't think these input restrictions can be met with
> just ACLs, you would need your own handler for this.
>
> Traditionally we do not bother to much with input validation
> (e.g try to store anything unfiltered), and only potect the user on
> output. (which i agree does not work to well for your link-juice
> extraction case above)
>
> > Anonymous comments would be UGC created by unauth'd users. I think this is a very reasonable requirement for a web site.
>
> Yes this is an important use-case.
> For managing content from unauthenticated sources, I suggest writing
> an own handler as well. It should then read/write the content
> using something like a special 'UGC' user.
>
> But I will still try to find you some meaningful examples.
>
> Cheers
> Lars
>
>
Re: SlingPostServlet - Real-world concerns and general thoughts.
Discussion encouraged!
Posted by Lars Krapf <lk...@adobe.com>.
Hello David
> Ah - this is what i'm looking for. Can you expound on "globbing ACL"?
> I was under the impression globbing ACLs were merely on the Node level. Could you enforce permissioning on the property level using this as well?
Yes. The rep:globs work on property level.
You can for example set deny jcr:write on a node and then add
allow jcr:write with globbing on jcr:title to allow writing
to the title property only.
>
> I assume a structural restriction is setting a node to be a certain node type which enforces certain properties? Does this cause existing nodes to become inflexible? Once a node type, always a node type?
There is some flexibility.
The node type is a protected property. (e.g. you can only change
it using the API call "setPrimaryType")
Additionally you could add a mix-in type to the node to extend
its functionality.
> I think an example would be very helpful.
>
> My sample requirement is: Allow users to post comments with an optional supporting links (Properties: title, body, link). Title and Body are required, Link is optional. Once a comment is written Title and Body cannot be edited, but the Link can be changed by the original-submitter if it was not previously submitted. Upon success the user is displayed a "thank you" page, on error the user is returned to the comment form with the offending fields denoted and the previously submitted values repopulated.
>
> The "Title" must be alpha-numeric, non-empty and unique across comment titles.
> The "Body" must be alpha-numeric, non-empty.
> The "Link" is optional, but if provided must be a well formed URL and responds to a GET with a 200 response.
> "sling:resourceType" must be "mysite/components/comment"
> "jcr:primaryType" must be "nt:unstructured"
>
> The only properties allowed on the node are as listed above (these resources will be consumed via a browser as HTML and as JSON for access by external clients).
>
> Using the SlingPostServlet and ACLs how can this requirement be met?
I will have to get back to you on this.
Short answer: I don't think these input restrictions can be met with
just ACLs, you would need your own handler for this.
Traditionally we do not bother to much with input validation
(e.g try to store anything unfiltered), and only potect the user on
output. (which i agree does not work to well for your link-juice
extraction case above)
> Anonymous comments would be UGC created by unauth'd users. I think this is a very reasonable requirement for a web site.
Yes this is an important use-case.
For managing content from unauthenticated sources, I suggest writing
an own handler as well. It should then read/write the content
using something like a special 'UGC' user.
But I will still try to find you some meaningful examples.
Cheers
Lars
Re: SlingPostServlet - Real-world concerns and general
thoughts. Discussion encouraged!
Posted by "David G." <da...@gmail.com>.
Lars - appreciate the responses - see my own inline:
--
David Gonzalez
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Thursday, May 3, 2012 at 8:17 AM, Lars Krapf wrote:
> 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.
>
Absolutely. I agreed wholeheartedly that "trust" is not truly sufficient -- thought, in the "real-world" trust is sometimes (often??) considered as much -- such as in enterprise CMS's that allow authors to post any data to nodes -- i won't name names. :)
For instance, Author Mallory could POST full a HTML page representations to /content/good/en/services/jcr:content/title/hidden-page-prop with back links to her affiliate site (bad.com), get the Services page pushed through review (since hidden-page-prop would only be seen by someone inspecting the JCR or looking at full JSON/XML/Node-dump representations of the page) and then submit
http://good.com/content/good/en/services/_jcr_content/title/hidden-page-prop to Google and start squeezing good.com for link juice!
> > 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.
>
Sure - I am trying to understand how the best way (if there is a way) to manage what is written to a node and (after your reply now) what level of granularity is provided by JCR and how that maps to the standard SlingPostServlet operations.
>
> > 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.
>
Ah - this is what i'm looking for. Can you expound on "globbing ACL"?
I was under the impression globbing ACLs were merely on the Node level. Could you enforce permissioning on the property level using this as well?
http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
I assume a structural restriction is setting a node to be a certain node type which enforces certain properties? Does this cause existing nodes to become inflexible? Once a node type, always a node type?
> > 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?
>
I think an example would be very helpful.
My sample requirement is: Allow users to post comments with an optional supporting links (Properties: title, body, link). Title and Body are required, Link is optional. Once a comment is written Title and Body cannot be edited, but the Link can be changed by the original-submitter if it was not previously submitted. Upon success the user is displayed a "thank you" page, on error the user is returned to the comment form with the offending fields denoted and the previously submitted values repopulated.
The "Title" must be alpha-numeric, non-empty and unique across comment titles.
The "Body" must be alpha-numeric, non-empty.
The "Link" is optional, but if provided must be a well formed URL and responds to a GET with a 200 response.
"sling:resourceType" must be "mysite/components/comment"
"jcr:primaryType" must be "nt:unstructured"
The only properties allowed on the node are as listed above (these resources will be consumed via a browser as HTML and as JSON for access by external clients).
Using the SlingPostServlet and ACLs how can this requirement be met?
Using a "traditional" web-app approach, this is fairly trivial: accept the POST, validate the data, if the data meets the validation requirements use the Session to save the data to the node, if not kick back an error response. The only ACLs required would be that the node is writable by the user.
>
> >
> > 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.
>
Anonymous comments would be UGC created by unauth'd users. I think this is a very reasonable requirement for a web site.
>
> >
> > 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
>
>
Lars - really appreciate the feedback. I'd love to here your thoughts and if possible get links to resources around how best to manage more complex ACLs combined with data validation all while using the SlingPostServlet to transport data.
Thanks again.
Re: SlingPostServlet - Real-world concerns and general thoughts.
Discussion encouraged!
Posted by Lars Krapf <lk...@adobe.com>.
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