[
https://issues.apache.org/jira/browse/SLING-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Zahler updated SLING-3040:
------------------------------
Description:
Sling selectors have been identified as a possible means of DoS attacks in CQ5.
Therefore, this ticket contains proposals on how selector restrictions can be
implemented in Sling.
I propose two mechanisms that can/should be used together:
- define selectors frequently used in the Sling instance and allow them
on any request
- define selectors per resource/resource type that are only allowed for
that resource/resource type (already proposed in [1])
The original requestor is not necessarily aware of the resources that are
included internally. Therefore, all checks are performed in request scope
filters. Also, this implies that selectors added internally (e.g. through
sling:include) are not affected.
The two mechanisms in more detail:
1. The generally allowed selectors can be configured as a list of entries
* A configuration entry can contain multiple selectors, "*" allows all selectors
* selectors can be configured only for specific repository trees as follows:
repositorypath:selectors
** the repository path is evaluated as a regular expression
** example: /content/.*:myselector,anotherselector
** If a configuration entry contains multiple selectors, a request containing
these selectors must contain them in the same order as in the configuration.
2. On a resource or on its resource type, the property sling:resourceSelectors
can be implemented. On that resource, the specified selectors are allowed in
addition to the ones specified in mechanism 1.
* A resource/resource type without the property sling:resourceSelectors does
not allow any selectors except the ones defined in mechanism 1.
* Inheritance must be considered: if a resource has a sling:resourceSuperType
set, the inherited selectors must be applied and the selectors added to the
ones of the current resource. (see examples below)
** If both the current resource and its resource type and or its resource
supertype have the property set, all selectors specified in either node are
allowed.
* If multiple selectors are defined on a resource, a request that has multiple
selectors must contain them in the same order as defined on the resource.
** Fixed ordering can be switched off configuratively
* Checks are performed only on request scope, therefore the check is only
performed on the resource actually requested.
3. Selectors defined by a Servlet in property sling.servlet.selectors are
treated as any other selector: either these selectors must be configured in the
generally allowed selectors or the resource requested must specifically allow
for them.
Attached is a sample implementation (definitely not production ready!).
[1]
http://svn.apache.org/repos/asf/sling/trunk/samples/urlfilter/src/main/java/org/apache/sling/samples/urlfilter/impl/UrlFilter.java
was:
Sling selectors have been identified as a possible means of DoS attacks in CQ5.
Therefore, this ticket contains proposals on how selector restrictions can be
implemented in Sling.
I propose two mechanisms that can/should be used together:
- define selectors frequently used in the Sling instance and allow them
on any request
- define selectors per resource/resource type that are only allowed for
that resource/resource type (already proposed in [1])
The original requestor is not necessarily aware of the resources that are
included internally. Therefore, all checks are performed in request scope
filters. Also, this implies that selectors added internally (e.g. through
sling:include) are not affected.
The two mechanisms in more detail:
1. The generally allowed selectors can be configured as a list of entries
a. A configuration entry can contain multiple selectors, * allows
all selectors
b. selectors can be configured only for specific repository trees
as follows:
repositorypath:selectors
i. the repository path is evaluated as a regular expression
ii. example: /content/.*:myselector,anotherselector
c. If a configuration entry contains multiple selectors, a request
containing these selectors must contain them in the same order as in the
configuration.
2. On a resource or on its resource type, the property
sling:resourceSelectors can be implemented. On that resource, the specified
selectors are allowed in addition to the ones specified in mechanism 1.
a. A resource/resource type without the property
sling:resourceSelectors does not allow any selectors except the ones defined in
mechanism 1.
b. Inheritance must be considered: if a resource has a
sling:resourceSuperType set, the inherited selectors must be applied and the
selectors added to the ones of the current resource. (see examples below)
i. If both the current resource and its resource type and
or its resource supertype have the property set, all selectors specified in
either node are allowed.
c. If multiple selectors are defined on a resource, a request that
has multiple selectors must contain them in the same order as defined on the
resource.
i. Fixed ordering can be switched off configuratively
d. Checks are performed only on request scope, therefore the check
is only performed on the resource actually requested.
3. Selectors defined by a Servlet in property sling.servlet.selectors are
treated as any other selector: either these selectors must be configured in the
generally allowed selectors or the resource requested must specifically allow
for them.
Attached is a sample implementation (definitely not production ready!).
[1]
http://svn.apache.org/repos/asf/sling/trunk/samples/urlfilter/src/main/java/org/apache/sling/samples/urlfilter/impl/UrlFilter.java
> Selector Restriction
> --------------------
>
> Key: SLING-3040
> URL: https://issues.apache.org/jira/browse/SLING-3040
> Project: Sling
> Issue Type: Wish
> Components: Extensions
> Reporter: Ben Zahler
> Priority: Minor
> Labels: security
> Attachments: SlingSelectorConfig.java, SlingSelectorFilter.java
>
>
> Sling selectors have been identified as a possible means of DoS attacks in
> CQ5. Therefore, this ticket contains proposals on how selector restrictions
> can be implemented in Sling.
> I propose two mechanisms that can/should be used together:
> - define selectors frequently used in the Sling instance and allow them
> on any request
> - define selectors per resource/resource type that are only allowed for
> that resource/resource type (already proposed in [1])
> The original requestor is not necessarily aware of the resources that are
> included internally. Therefore, all checks are performed in request scope
> filters. Also, this implies that selectors added internally (e.g. through
> sling:include) are not affected.
> The two mechanisms in more detail:
> 1. The generally allowed selectors can be configured as a list of entries
> * A configuration entry can contain multiple selectors, "*" allows all
> selectors
> * selectors can be configured only for specific repository trees as follows:
> repositorypath:selectors
> ** the repository path is evaluated as a regular expression
> ** example: /content/.*:myselector,anotherselector
> ** If a configuration entry contains multiple selectors, a request containing
> these selectors must contain them in the same order as in the configuration.
> 2. On a resource or on its resource type, the property
> sling:resourceSelectors can be implemented. On that resource, the specified
> selectors are allowed in addition to the ones specified in mechanism 1.
> * A resource/resource type without the property sling:resourceSelectors does
> not allow any selectors except the ones defined in mechanism 1.
> * Inheritance must be considered: if a resource has a sling:resourceSuperType
> set, the inherited selectors must be applied and the selectors added to the
> ones of the current resource. (see examples below)
> ** If both the current resource and its resource type and or its resource
> supertype have the property set, all selectors specified in either node are
> allowed.
> * If multiple selectors are defined on a resource, a request that has
> multiple selectors must contain them in the same order as defined on the
> resource.
> ** Fixed ordering can be switched off configuratively
> * Checks are performed only on request scope, therefore the check is only
> performed on the resource actually requested.
> 3. Selectors defined by a Servlet in property sling.servlet.selectors are
> treated as any other selector: either these selectors must be configured in
> the generally allowed selectors or the resource requested must specifically
> allow for them.
> Attached is a sample implementation (definitely not production ready!).
> [1]
> http://svn.apache.org/repos/asf/sling/trunk/samples/urlfilter/src/main/java/org/apache/sling/samples/urlfilter/impl/UrlFilter.java
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
