[
https://issues.apache.org/jira/browse/SLING-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13759274#comment-13759274
]
Julian Sedding commented on SLING-3040:
---------------------------------------
{quote}
* What is the appropriate HTTP response code if the request is denied?
** [1] suggests 403, I would suggest 400
{quote}
The HTTP specification[0] defines the status code 400 as follows:
{quote}
10.4.1 400 Bad Request
The request could not be understood by the server due to malformed syntax. The
client SHOULD NOT repeat the request without modifications.
{quote}
I would suggest a 404 Not Found, as that's what you are trying to communicate
to an DoS attacker.
Other than that I would keep it simple and only allow per resource-type
definitions and support the resource-type inheritance hierarchy. "Global" rules
are then automatically supported via allowed-selector definitions for
"sling/servlet/default".
I don't see any benefit on a per resource configuration, as the selectors tend
to get supported by the resource-types independent of the resources. If someone
has the need to support it per-resource, they can still manually implement it
in the rendering script/servlet and return a 404 themselves. This would be
required for "dynamic" selectors in any case.
[0] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1
> 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. 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
--
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
