[jira] [Commented] (SLING-3040) Selector Restriction
[ https://issues.apache.org/jira/browse/SLING-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758919#comment-13758919 ] Ben Zahler commented on SLING-3040: --- Some discussion topics I have come accress when designing this: 1. Is a Servlet Filter the best place to check this? * Servlet Filter is a good place because it can be also shipped if not included in default Sling distribution 2. What is the appropriate HTTP response code if the request is denied? * [1] suggests 403, I would suggest 400 3. [1] checks mechanism 2 for the resource type, but not for the resource. Does allowing the configuration on resource base bring additional value? * For CQ environments, resource type (with inheritance) very likely is sufficient 4. Do we need to consider runmode for sling:resourceSelectors? In CQ, author systems tend to require a lot more selectors and with the proposed configuration options, this means they are all available on publish instances as well. 5. Should this mechanism also be extended to other aspects of sling urls sich as extensions and suffix paths (as implemented in [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
[jira] [Commented] (SLING-3040) Selector Restriction
[ https://issues.apache.org/jira/browse/SLING-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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