You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Robert Munteanu <rm...@adobe.com> on 2012/06/08 14:46:23 UTC

Securing scripts under {libs,apps}

Hi,

I've recently been made aware that all resources under /apps are readable by everyone. This includes JSP scripts and I presume bundles deployed under the install folder.

What is the recommended way of securing access to such resources?

Thanks,

Robert

RE: Securing scripts under {libs,apps}

Posted by Robert Munteanu <rm...@adobe.com>.
Hi Eric,

(Thanks to Davide and David for their answers as well)

> -----Original Message-----
> From: Eric Norman [mailto:eric.d.norman@gmail.com]
> Sent: Sunday, June 10, 2012 7:46 AM
> To: users@sling.apache.org
> Subject: Re: Securing scripts under {libs,apps}
> 
> If I recall correctly, if all your scripts are published to the JCR
> repository, then you can just configure the JCR ACL to deny read access
> to
> everyone.  Sling uses a "script user" (admin by default) to read the
> scripts, so the end user doesn't have to have rights to read those
> script
> resources to use them.  On the other hand, if your scripts are provided
> by
> some non JCR resource provider then you would have more work to do to
> block
> read access to those files.

I'll go down the route of denying access to everyone to/{libs,apps} and allowing only the administrators group to read those. I might tweak it more since - for instance - the sling explorer deploys static assets to /libs/sling/explorer.

I'll also look into setting up some rules on the reverse proxy - which is already there.

Thanks,

Robert

> 
> Regards,
> Eric
> 
> On Fri, Jun 8, 2012 at 11:16 AM, David Gonzalez
> <da...@gmail.com>wrote:
> 
> > Ideally all security should be handled via JCR ACLs. Reverse proxy
> > rules/dispatcher should be used to harden those ACLs. Be careful
> using
> > ACLs - as they may impede script resolution - I believe
> > getResourceSuperType() where the SuperType is not readable by the
> user
> > will throw an error (unless this has already been fixed).
> >
> > Sent from my iPad
> >
> > On Jun 8, 2012, at 10:19 AM, Davide <ge...@gmail.com> wrote:
> >
> > > On 08/06/2012 13:46, Robert Munteanu wrote:
> > >> Hi,
> > >>
> > >> I've recently been made aware that all resources under /apps are
> > readable by everyone. This includes JSP scripts and I presume bundles
> > deployed under the install folder.
> > >>
> > >> What is the recommended way of securing access to such resources?
> > >
> > > hi Robert,
> > >
> > > normally I work with CQ and in that case there's the Dispatcher
> (apache
> > > module) that takes care about it.
> > >
> > > Let's say that without knowing sling too much, if I'd have to do it
> I
> > > would manage it a 2 levels.
> > >
> > > First one with ACL in jackrabbit. Giving the read access only
> behind
> > > authentication.
> > >
> > > Second using the apache rewrite rules a would rewrite all /apps and
> > > /libs to a 404.
> > >
> > > HTH
> > > Davide
> > >
> >

Re: Unable to set ACL for /lbs ( was RE: Securing scripts under {libs,apps} )

Posted by Felix Meschberger <fm...@adobe.com>.
Hi,

Am 12.06.2012 um 12:35 schrieb Robert Munteanu:

> Hi, 
> 
> 
>>> How can I make sure that ACLs are applied to the /libs folder as
>> well?
>> 
>> Create a /libs node to apply the ACLs
> 
> Thanks, creating the node using webdav manually worked and then ACLs were applied. I was just thrown off that the sling explorer did show a node for libs.

Yes, The Sling ResourceResolver exposes a virtual resource if there are resources below. So if there is a resource at /libs/sling/exporer, there is a virtual resource at /libs and probably also /libs/sling such that the full resource tree can be traversed

Regards
Felix

> 
> Robert
> 
>> 
>> Regards
>> Felix
>> 
>>> 
>>> Thanks,
>>> 
>>> Robert
>>> 
>>>> -----Original Message-----
>>>> From: Robert Munteanu
>>>> Sent: Tuesday, June 12, 2012 10:35 AM
>>>> To: users@sling.apache.org
>>>> Subject: RE: Securing scripts under {libs,apps}
>>>> 
>>>> Hi Eric,
>>>> 
>>>> (Thanks to Davide and David for their answers as well)
>>>> 
>>>>> -----Original Message-----
>>>>> From: Eric Norman [mailto:eric.d.norman@gmail.com]
>>>>> Sent: Sunday, June 10, 2012 7:46 AM
>>>>> To: users@sling.apache.org
>>>>> Subject: Re: Securing scripts under {libs,apps}
>>>>> 
>>>>> If I recall correctly, if all your scripts are published to the JCR
>>>>> repository, then you can just configure the JCR ACL to deny read
>>>> access
>>>>> to
>>>>> everyone.  Sling uses a "script user" (admin by default) to read
>> the
>>>>> scripts, so the end user doesn't have to have rights to read those
>>>>> script
>>>>> resources to use them.  On the other hand, if your scripts are
>>>> provided
>>>>> by
>>>>> some non JCR resource provider then you would have more work to do
>> to
>>>>> block
>>>>> read access to those files.
>>>> 
>>>> I'll go down the route of denying access to everyone to/{libs,apps}
>> and
>>>> allowing only the administrators group to read those. I might tweak
>> it
>>>> more since - for instance - the sling explorer deploys static assets
>> to
>>>> /libs/sling/explorer.
>>>> 
>>>> I'll also look into setting up some rules on the reverse proxy -
>> which
>>>> is already there.
>>>> 
>>>> Thanks,
>>>> 
>>>> Robert
>>>> 
>>>>> 
>>>>> Regards,
>>>>> Eric
>>>>> 
>>>>> On Fri, Jun 8, 2012 at 11:16 AM, David Gonzalez
>>>>> <da...@gmail.com>wrote:
>>>>> 
>>>>>> Ideally all security should be handled via JCR ACLs. Reverse proxy
>>>>>> rules/dispatcher should be used to harden those ACLs. Be careful
>>>>> using
>>>>>> ACLs - as they may impede script resolution - I believe
>>>>>> getResourceSuperType() where the SuperType is not readable by the
>>>>> user
>>>>>> will throw an error (unless this has already been fixed).
>>>>>> 
>>>>>> Sent from my iPad
>>>>>> 
>>>>>> On Jun 8, 2012, at 10:19 AM, Davide <ge...@gmail.com> wrote:
>>>>>> 
>>>>>>> On 08/06/2012 13:46, Robert Munteanu wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> I've recently been made aware that all resources under /apps are
>>>>>> readable by everyone. This includes JSP scripts and I presume
>>>> bundles
>>>>>> deployed under the install folder.
>>>>>>>> 
>>>>>>>> What is the recommended way of securing access to such
>>>> resources?
>>>>>>> 
>>>>>>> hi Robert,
>>>>>>> 
>>>>>>> normally I work with CQ and in that case there's the Dispatcher
>>>>> (apache
>>>>>>> module) that takes care about it.
>>>>>>> 
>>>>>>> Let's say that without knowing sling too much, if I'd have to do
>>>> it
>>>>> I
>>>>>>> would manage it a 2 levels.
>>>>>>> 
>>>>>>> First one with ACL in jackrabbit. Giving the read access only
>>>>> behind
>>>>>>> authentication.
>>>>>>> 
>>>>>>> Second using the apache rewrite rules a would rewrite all /apps
>>>> and
>>>>>>> /libs to a 404.
>>>>>>> 
>>>>>>> HTH
>>>>>>> Davide
>>>>>>> 
>>>>>> 
> 


RE: Unable to set ACL for /lbs ( was RE: Securing scripts under {libs,apps} )

Posted by Robert Munteanu <rm...@adobe.com>.
Hi, 


> > How can I make sure that ACLs are applied to the /libs folder as
> well?
> 
> Create a /libs node to apply the ACLs

Thanks, creating the node using webdav manually worked and then ACLs were applied. I was just thrown off that the sling explorer did show a node for libs.

Robert

> 
> Regards
> Felix
> 
> >
> > Thanks,
> >
> > Robert
> >
> >> -----Original Message-----
> >> From: Robert Munteanu
> >> Sent: Tuesday, June 12, 2012 10:35 AM
> >> To: users@sling.apache.org
> >> Subject: RE: Securing scripts under {libs,apps}
> >>
> >> Hi Eric,
> >>
> >> (Thanks to Davide and David for their answers as well)
> >>
> >>> -----Original Message-----
> >>> From: Eric Norman [mailto:eric.d.norman@gmail.com]
> >>> Sent: Sunday, June 10, 2012 7:46 AM
> >>> To: users@sling.apache.org
> >>> Subject: Re: Securing scripts under {libs,apps}
> >>>
> >>> If I recall correctly, if all your scripts are published to the JCR
> >>> repository, then you can just configure the JCR ACL to deny read
> >> access
> >>> to
> >>> everyone.  Sling uses a "script user" (admin by default) to read
> the
> >>> scripts, so the end user doesn't have to have rights to read those
> >>> script
> >>> resources to use them.  On the other hand, if your scripts are
> >> provided
> >>> by
> >>> some non JCR resource provider then you would have more work to do
> to
> >>> block
> >>> read access to those files.
> >>
> >> I'll go down the route of denying access to everyone to/{libs,apps}
> and
> >> allowing only the administrators group to read those. I might tweak
> it
> >> more since - for instance - the sling explorer deploys static assets
> to
> >> /libs/sling/explorer.
> >>
> >> I'll also look into setting up some rules on the reverse proxy -
> which
> >> is already there.
> >>
> >> Thanks,
> >>
> >> Robert
> >>
> >>>
> >>> Regards,
> >>> Eric
> >>>
> >>> On Fri, Jun 8, 2012 at 11:16 AM, David Gonzalez
> >>> <da...@gmail.com>wrote:
> >>>
> >>>> Ideally all security should be handled via JCR ACLs. Reverse proxy
> >>>> rules/dispatcher should be used to harden those ACLs. Be careful
> >>> using
> >>>> ACLs - as they may impede script resolution - I believe
> >>>> getResourceSuperType() where the SuperType is not readable by the
> >>> user
> >>>> will throw an error (unless this has already been fixed).
> >>>>
> >>>> Sent from my iPad
> >>>>
> >>>> On Jun 8, 2012, at 10:19 AM, Davide <ge...@gmail.com> wrote:
> >>>>
> >>>>> On 08/06/2012 13:46, Robert Munteanu wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I've recently been made aware that all resources under /apps are
> >>>> readable by everyone. This includes JSP scripts and I presume
> >> bundles
> >>>> deployed under the install folder.
> >>>>>>
> >>>>>> What is the recommended way of securing access to such
> >> resources?
> >>>>>
> >>>>> hi Robert,
> >>>>>
> >>>>> normally I work with CQ and in that case there's the Dispatcher
> >>> (apache
> >>>>> module) that takes care about it.
> >>>>>
> >>>>> Let's say that without knowing sling too much, if I'd have to do
> >> it
> >>> I
> >>>>> would manage it a 2 levels.
> >>>>>
> >>>>> First one with ACL in jackrabbit. Giving the read access only
> >>> behind
> >>>>> authentication.
> >>>>>
> >>>>> Second using the apache rewrite rules a would rewrite all /apps
> >> and
> >>>>> /libs to a 404.
> >>>>>
> >>>>> HTH
> >>>>> Davide
> >>>>>
> >>>>


Re: Unable to set ACL for /lbs ( was RE: Securing scripts under {libs,apps} )

Posted by Felix Meschberger <fm...@adobe.com>.
Hi

Am 12.06.2012 um 10:40 schrieb Robert Munteanu:

> I've tried to update the ACLs for /apps and /libs using 
> 
> $ curl -FprincipalId=administrators -Fprivilege@jcr:all=granted http://admin:admin@localhost:8080/libs.modifyAce.html
> 
> This works for apps, but not for libs ; the error message from the HTML page is
> 
> Status: 404
> Message: Resource is not a JCR Node
> Location: /libs
> Parent Location: /

This indicates that an actual /libs node does not exist.

> 
> In the sling explorer I don't see any properties for those nodes so they are probably not JCR nodes . I did not place any resources by myself under /libs but this was created by some Sling bundles, for instance the Sling Explorer
> 
> <Sling-Bundle-Resources>
>    /libs/sling/explorer,
>    /libs/sling/servlet/default/explorer
> </Sling-Bundle-Resources>

This are non-JCR resources not hooked off a /libs node.

> 
> How can I make sure that ACLs are applied to the /libs folder as well?

Create a /libs node to apply the ACLs

Regards
Felix

> 
> Thanks,
> 
> Robert
> 
>> -----Original Message-----
>> From: Robert Munteanu
>> Sent: Tuesday, June 12, 2012 10:35 AM
>> To: users@sling.apache.org
>> Subject: RE: Securing scripts under {libs,apps}
>> 
>> Hi Eric,
>> 
>> (Thanks to Davide and David for their answers as well)
>> 
>>> -----Original Message-----
>>> From: Eric Norman [mailto:eric.d.norman@gmail.com]
>>> Sent: Sunday, June 10, 2012 7:46 AM
>>> To: users@sling.apache.org
>>> Subject: Re: Securing scripts under {libs,apps}
>>> 
>>> If I recall correctly, if all your scripts are published to the JCR
>>> repository, then you can just configure the JCR ACL to deny read
>> access
>>> to
>>> everyone.  Sling uses a "script user" (admin by default) to read the
>>> scripts, so the end user doesn't have to have rights to read those
>>> script
>>> resources to use them.  On the other hand, if your scripts are
>> provided
>>> by
>>> some non JCR resource provider then you would have more work to do to
>>> block
>>> read access to those files.
>> 
>> I'll go down the route of denying access to everyone to/{libs,apps} and
>> allowing only the administrators group to read those. I might tweak it
>> more since - for instance - the sling explorer deploys static assets to
>> /libs/sling/explorer.
>> 
>> I'll also look into setting up some rules on the reverse proxy - which
>> is already there.
>> 
>> Thanks,
>> 
>> Robert
>> 
>>> 
>>> Regards,
>>> Eric
>>> 
>>> On Fri, Jun 8, 2012 at 11:16 AM, David Gonzalez
>>> <da...@gmail.com>wrote:
>>> 
>>>> Ideally all security should be handled via JCR ACLs. Reverse proxy
>>>> rules/dispatcher should be used to harden those ACLs. Be careful
>>> using
>>>> ACLs - as they may impede script resolution - I believe
>>>> getResourceSuperType() where the SuperType is not readable by the
>>> user
>>>> will throw an error (unless this has already been fixed).
>>>> 
>>>> Sent from my iPad
>>>> 
>>>> On Jun 8, 2012, at 10:19 AM, Davide <ge...@gmail.com> wrote:
>>>> 
>>>>> On 08/06/2012 13:46, Robert Munteanu wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> I've recently been made aware that all resources under /apps are
>>>> readable by everyone. This includes JSP scripts and I presume
>> bundles
>>>> deployed under the install folder.
>>>>>> 
>>>>>> What is the recommended way of securing access to such
>> resources?
>>>>> 
>>>>> hi Robert,
>>>>> 
>>>>> normally I work with CQ and in that case there's the Dispatcher
>>> (apache
>>>>> module) that takes care about it.
>>>>> 
>>>>> Let's say that without knowing sling too much, if I'd have to do
>> it
>>> I
>>>>> would manage it a 2 levels.
>>>>> 
>>>>> First one with ACL in jackrabbit. Giving the read access only
>>> behind
>>>>> authentication.
>>>>> 
>>>>> Second using the apache rewrite rules a would rewrite all /apps
>> and
>>>>> /libs to a 404.
>>>>> 
>>>>> HTH
>>>>> Davide
>>>>> 
>>>> 


Unable to set ACL for /lbs ( was RE: Securing scripts under {libs,apps} )

Posted by Robert Munteanu <rm...@adobe.com>.
I've tried to update the ACLs for /apps and /libs using 

$ curl -FprincipalId=administrators -Fprivilege@jcr:all=granted http://admin:admin@localhost:8080/libs.modifyAce.html

This works for apps, but not for libs ; the error message from the HTML page is

Status: 404
Message: Resource is not a JCR Node
Location: /libs
Parent Location: /

In the sling explorer I don't see any properties for those nodes so they are probably not JCR nodes . I did not place any resources by myself under /libs but this was created by some Sling bundles, for instance the Sling Explorer

<Sling-Bundle-Resources>
    /libs/sling/explorer,
    /libs/sling/servlet/default/explorer
</Sling-Bundle-Resources>

How can I make sure that ACLs are applied to the /libs folder as well?

Thanks,

Robert

> -----Original Message-----
> From: Robert Munteanu
> Sent: Tuesday, June 12, 2012 10:35 AM
> To: users@sling.apache.org
> Subject: RE: Securing scripts under {libs,apps}
> 
> Hi Eric,
> 
> (Thanks to Davide and David for their answers as well)
> 
> > -----Original Message-----
> > From: Eric Norman [mailto:eric.d.norman@gmail.com]
> > Sent: Sunday, June 10, 2012 7:46 AM
> > To: users@sling.apache.org
> > Subject: Re: Securing scripts under {libs,apps}
> >
> > If I recall correctly, if all your scripts are published to the JCR
> > repository, then you can just configure the JCR ACL to deny read
> access
> > to
> > everyone.  Sling uses a "script user" (admin by default) to read the
> > scripts, so the end user doesn't have to have rights to read those
> > script
> > resources to use them.  On the other hand, if your scripts are
> provided
> > by
> > some non JCR resource provider then you would have more work to do to
> > block
> > read access to those files.
> 
> I'll go down the route of denying access to everyone to/{libs,apps} and
> allowing only the administrators group to read those. I might tweak it
> more since - for instance - the sling explorer deploys static assets to
> /libs/sling/explorer.
> 
> I'll also look into setting up some rules on the reverse proxy - which
> is already there.
> 
> Thanks,
> 
> Robert
> 
> >
> > Regards,
> > Eric
> >
> > On Fri, Jun 8, 2012 at 11:16 AM, David Gonzalez
> > <da...@gmail.com>wrote:
> >
> > > Ideally all security should be handled via JCR ACLs. Reverse proxy
> > > rules/dispatcher should be used to harden those ACLs. Be careful
> > using
> > > ACLs - as they may impede script resolution - I believe
> > > getResourceSuperType() where the SuperType is not readable by the
> > user
> > > will throw an error (unless this has already been fixed).
> > >
> > > Sent from my iPad
> > >
> > > On Jun 8, 2012, at 10:19 AM, Davide <ge...@gmail.com> wrote:
> > >
> > > > On 08/06/2012 13:46, Robert Munteanu wrote:
> > > >> Hi,
> > > >>
> > > >> I've recently been made aware that all resources under /apps are
> > > readable by everyone. This includes JSP scripts and I presume
> bundles
> > > deployed under the install folder.
> > > >>
> > > >> What is the recommended way of securing access to such
> resources?
> > > >
> > > > hi Robert,
> > > >
> > > > normally I work with CQ and in that case there's the Dispatcher
> > (apache
> > > > module) that takes care about it.
> > > >
> > > > Let's say that without knowing sling too much, if I'd have to do
> it
> > I
> > > > would manage it a 2 levels.
> > > >
> > > > First one with ACL in jackrabbit. Giving the read access only
> > behind
> > > > authentication.
> > > >
> > > > Second using the apache rewrite rules a would rewrite all /apps
> and
> > > > /libs to a 404.
> > > >
> > > > HTH
> > > > Davide
> > > >
> > >

Re: Securing scripts under {libs,apps}

Posted by Eric Norman <er...@gmail.com>.
If I recall correctly, if all your scripts are published to the JCR
repository, then you can just configure the JCR ACL to deny read access to
everyone.  Sling uses a "script user" (admin by default) to read the
scripts, so the end user doesn't have to have rights to read those script
resources to use them.  On the other hand, if your scripts are provided by
some non JCR resource provider then you would have more work to do to block
read access to those files.

Regards,
Eric

On Fri, Jun 8, 2012 at 11:16 AM, David Gonzalez <da...@gmail.com>wrote:

> Ideally all security should be handled via JCR ACLs. Reverse proxy
> rules/dispatcher should be used to harden those ACLs. Be careful using
> ACLs - as they may impede script resolution - I believe
> getResourceSuperType() where the SuperType is not readable by the user
> will throw an error (unless this has already been fixed).
>
> Sent from my iPad
>
> On Jun 8, 2012, at 10:19 AM, Davide <ge...@gmail.com> wrote:
>
> > On 08/06/2012 13:46, Robert Munteanu wrote:
> >> Hi,
> >>
> >> I've recently been made aware that all resources under /apps are
> readable by everyone. This includes JSP scripts and I presume bundles
> deployed under the install folder.
> >>
> >> What is the recommended way of securing access to such resources?
> >
> > hi Robert,
> >
> > normally I work with CQ and in that case there's the Dispatcher (apache
> > module) that takes care about it.
> >
> > Let's say that without knowing sling too much, if I'd have to do it I
> > would manage it a 2 levels.
> >
> > First one with ACL in jackrabbit. Giving the read access only behind
> > authentication.
> >
> > Second using the apache rewrite rules a would rewrite all /apps and
> > /libs to a 404.
> >
> > HTH
> > Davide
> >
>

Re: Securing scripts under {libs,apps}

Posted by David Gonzalez <da...@gmail.com>.
Ideally all security should be handled via JCR ACLs. Reverse proxy
rules/dispatcher should be used to harden those ACLs. Be careful using
ACLs - as they may impede script resolution - I believe
getResourceSuperType() where the SuperType is not readable by the user
will throw an error (unless this has already been fixed).

Sent from my iPad

On Jun 8, 2012, at 10:19 AM, Davide <ge...@gmail.com> wrote:

> On 08/06/2012 13:46, Robert Munteanu wrote:
>> Hi,
>>
>> I've recently been made aware that all resources under /apps are readable by everyone. This includes JSP scripts and I presume bundles deployed under the install folder.
>>
>> What is the recommended way of securing access to such resources?
>
> hi Robert,
>
> normally I work with CQ and in that case there's the Dispatcher (apache
> module) that takes care about it.
>
> Let's say that without knowing sling too much, if I'd have to do it I
> would manage it a 2 levels.
>
> First one with ACL in jackrabbit. Giving the read access only behind
> authentication.
>
> Second using the apache rewrite rules a would rewrite all /apps and
> /libs to a 404.
>
> HTH
> Davide
>

Re: Securing scripts under {libs,apps}

Posted by Davide <ge...@gmail.com>.
On 08/06/2012 13:46, Robert Munteanu wrote:
> Hi,
> 
> I've recently been made aware that all resources under /apps are readable by everyone. This includes JSP scripts and I presume bundles deployed under the install folder.
> 
> What is the recommended way of securing access to such resources?

hi Robert,

normally I work with CQ and in that case there's the Dispatcher (apache
module) that takes care about it.

Let's say that without knowing sling too much, if I'd have to do it I
would manage it a 2 levels.

First one with ACL in jackrabbit. Giving the read access only behind
authentication.

Second using the apache rewrite rules a would rewrite all /apps and
/libs to a 404.

HTH
Davide