[jira] [Commented] (SLING-11115) Allow path exemptions for referrer filter
[ https://issues.apache.org/jira/browse/SLING-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488710#comment-17488710 ] Lars Krapf commented on SLING-5: [~angela]: bq. what do you have in mind when you refer to 'complete paths'? I suggest to match the [resource path|https://sling.apache.org/apidocs/sling7/org/apache/sling/api/request/RequestPathInfo.html#getResourcePath--] portion of the path info. > Allow path exemptions for referrer filter > -- > > Key: SLING-5 > URL: https://issues.apache.org/jira/browse/SLING-5 > Project: Sling > Issue Type: Improvement > Components: Sling Security >Reporter: Lars Krapf >Assignee: Angela Schreiber >Priority: Major > Fix For: Security 1.1.24 > > > The referrer filter should have a configuration option to exclude one or > several paths from the check. > For context: > It seems that the RedHat SSO IDP sends "Referrer-Policy: no-referrer" by > default (to adress some [security > concerns|https://tools.ietf.org/id/draft-ietf-oauth-security-topics-14.html#rfc.section.4.2.4]). > This breaks the SAML POST binding in conjunction with the Sling referrer > filter. Currently the only option to make it work is to allow empty referrers > in general, however this weakens the CSRF protection. > Allowing to disable the filter for individual paths would allow to solve this > use-case with minimal additional risk. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SLING-11115) Allow path exemptions for referrer filter
[ https://issues.apache.org/jira/browse/SLING-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486456#comment-17486456 ] Lars Krapf commented on SLING-5: [~cziegeler]: bq. How should such an exclude list look like? Complete paths or path prefixes? My gut feeling is to only allow exact matches. It's faster and should prevent people from accidently opening up entire subtrees. I wouldn't expect the number of exempted paths to grow too big eventually. In AEM, the token based CSRF protection only allows exact matches either, and so far no one complained :) > Allow path exemptions for referrer filter > -- > > Key: SLING-5 > URL: https://issues.apache.org/jira/browse/SLING-5 > Project: Sling > Issue Type: Improvement > Components: Sling Security >Reporter: Lars Krapf >Priority: Major > > The referrer filter should have a configuration option to exclude one or > several paths from the check. > For context: > It seems that the RedHat SSO IDP sends "Referrer-Policy: no-referrer" by > default (to adress some [security > concerns|https://tools.ietf.org/id/draft-ietf-oauth-security-topics-14.html#rfc.section.4.2.4]). > This breaks the SAML POST binding in conjunction with the Sling referrer > filter. Currently the only option to make it work is to allow empty referrers > in general, however this weakens the CSRF protection. > Allowing to disable the filter for individual paths would allow to solve this > use-case with minimal additional risk. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SLING-11115) Allow path exemptions for referrer filter
Lars Krapf created SLING-5: -- Summary: Allow path exemptions for referrer filter Key: SLING-5 URL: https://issues.apache.org/jira/browse/SLING-5 Project: Sling Issue Type: Improvement Components: Sling Security Reporter: Lars Krapf The referrer filter should have a configuration option to exclude one or several paths from the check. For context: It seems that the RedHat SSO IDP sends "Referrer-Policy: no-referrer" by default (to adress some [security concerns|https://tools.ietf.org/id/draft-ietf-oauth-security-topics-14.html#rfc.section.4.2.4]). This breaks the SAML POST binding in conjunction with the Sling referrer filter. Currently the only option to make it work is to allow empty referrers in general, however this weakens the CSRF protection. Allowing to disable the filter for individual paths would allow to solve this use-case with minimal additional risk. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SLING-10225) Files with ".." In Name Throw 400 Exception
[
https://issues.apache.org/jira/browse/SLING-10225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17304160#comment-17304160
]
Lars Krapf commented on SLING-10225:
Hello [~rombert]
I agree that the fix for SLING-9741, i.e {{path.contains("...")}} is incomplete
(at least for JCR), since {{.}} is a valid node name character. Some ambiguity
most likely cannot be avoided.
Actually, I would *not* invalidate the path in the first place, but simply try
to be a bit more consistent with the normalization. I'm not sure if anything
other than {{/../}} or {{/..;foo/}} should resolve to the parent. From a strict
security POV however there is no right or wrong IMO, it's just different
interpretations.
[~dklco]:
bq. Or would this just make more sense to handle in the reverse proxy rather
than building this into the Sling Engine?
I think it's a combination of both - the decomposition from SLING-9741 is
rather confusing (note, that additionally this is dependent on whether {{a.js}}
exists or not, so it's impossible for a static proxy to determine the correct
resolution). But the problem of mismatching interpretations of ".." is [not
unique to
Sling|https://www.acunetix.com/blog/articles/a-fresh-look-on-reverse-proxy-related-attacks/]
- I think the best we can do is to be consistent and well documented.
> Files with ".." In Name Throw 400 Exception
> ---
>
> Key: SLING-10225
> URL: https://issues.apache.org/jira/browse/SLING-10225
> Project: Sling
> Issue Type: Bug
> Components: Engine
>Affects Versions: Engine 2.7.4
>Reporter: Dan Klco
>Priority: Critical
> Fix For: Engine 2.7.6
>
>
> SLING-9741 and the [associated
> PR|https://github.com/apache/sling-org-apache-sling-engine/pull/11]
> introduced a regression where the Sling Engine will return a 400 error on
> requests based on the presence of ".." in the URL when not preceded by a
> slash.
> This is an issue as file names may contain multiple periods and it is not
> obvious that it would cause an issue to upload a file with two periods in the
> name.
> h2. Reproduction steps:
> * Update a Sling instance to use Engine 2.7.4
> * Upload a file containing .. in the path
> * Attempt to get the file or any path with the file as a suffix
> * Note this returns a 400 error
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9767) Insecure Recommendation in Dynamic Include Documentation
Lars Krapf created SLING-9767:
-
Summary: Insecure Recommendation in Dynamic Include Documentation
Key: SLING-9767
URL: https://issues.apache.org/jira/browse/SLING-9767
Project: Sling
Issue Type: Improvement
Components: Documentation
Affects Versions: Dynamic Include 3.2.0
Reporter: Lars Krapf
The [documentation for the Sling Dynamic
Includes|https://sling.apache.org/documentation/bundles/dynamic-includes.html#enabling-ssi-in-apache-with-the-aem-dispatcher-module]
mentions the following:
bq. Having added the SetOutputFilter directive, open the virtual host's
configuration and add the Includes option to the Options directive:
This is an extremely unsafe recommendation. The "Includes" option will allow
anyone who can change content on the backend (e.g. AEM) to run arbitrary
commands on the webserver (dispatcher), by injecting the {{}}
directive.
The recommendation should be to use the "IncludesNOEXEC" option instead, which
will only allow to include static content (with a "safe" mime-type such as HTML
or plain-text).
See also: http://httpd.apache.org/docs/current/mod/mod_include.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9741) Invalid path decomposition in case of multiple dots
Lars Krapf created SLING-9741:
-
Summary: Invalid path decomposition in case of multiple dots
Key: SLING-9741
URL: https://issues.apache.org/jira/browse/SLING-9741
Project: Sling
Issue Type: Bug
Components: ResourceResolver
Affects Versions: Resource Resolver 1.7.0
Reporter: Lars Krapf
The resource resolver performs path normalization using
[ResourceUtil.normalize()|https://github.com/apache/sling-org-apache-sling-api/blob/a459f157b87e2ca6a274a1d890aad1d86ff7a631/src/main/java/org/apache/sling/api/resource/ResourceUtil.java#L49].
This leads to unexpected results in the case of a combination of non-existing
resources, and multiple dots in a path segment.
E.g. the following request:
{{http://localhost/content/a.js/..children-1json/a.txt}}
will be decomposed as follows:
{code}
Extension=json
resourcePath=/content/a.js/..
selectors=[, , , children, , , , -1]
seclectorString=...children-1...
suffix=/a.txt
{code}
Note that the first two dots of the third path segment are interpreted as the
parent path (a.js does not exist), which essentially turns this line into
{{/content.children.-1.json/a.txt}}, which can confuse reverse proxies.
I think the {{..}} should only be interpreted as the parent path if followed by
a {{/}} (or potentially a semicolon if path parameters on {{..}} segments
should be allowed).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9740) Invalid handling of requests containing URL path parameters
Lars Krapf created SLING-9740:
-
Summary: Invalid handling of requests containing URL path
parameters
Key: SLING-9740
URL: https://issues.apache.org/jira/browse/SLING-9740
Project: Sling
Issue Type: Bug
Components: Engine
Affects Versions: Engine 2.7.2
Reporter: Lars Krapf
{{RequestData.initResource()}} has support for requests containing URL-path
parameters (e.g. /path;foo=bar/path2;bar=baz/). It will split at the first
semicolon, and concatenate this to the {{request.getPathInfo()}} (not
containing such parameters). See
[RequestData.java|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L232].
However, this handling is incomplete as it only covers the case where one such
parameter is added at the end of the request, but path parameters can be added
to *any* path segment, leading to unexpected results.
E.g. the following request:
http://localhost:4502/content;foo=bar/we-retail;bar=baz/us/en.html
will result in {{path}} being:
/content/we-retail/us/en.html;foo=bar/we-retail;bar=baz/us/en.html
This gets especially confusing when path normalization happens in conjunction
with path parameters:
http://localhost/content/we-retail.html/..;/..;/bin/querybuilder.json.css?path=/home/users
will result in {{path}} being:
/bin/querybuilder.json.css;/..;/bin/querybuilder.json.css
after the concatenation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9739) Wrong decomposition/resolution in Servlets Resolver Plugin
Lars Krapf created SLING-9739:
-
Summary: Wrong decomposition/resolution in Servlets Resolver Plugin
Key: SLING-9739
URL: https://issues.apache.org/jira/browse/SLING-9739
Project: Sling
Issue Type: Bug
Components: Console
Affects Versions: Servlets Resolver 2.7.10
Reporter: Lars Krapf
Attachments: 2020-09-17-104013_1554x416_scrot.png
The servlets resolver webconsole plugin is sometimes displaying a different
decomposition and candidate servlet, than what Sling actually resolves.
E.g. the path:
/content/we-retail.html/..;/..;/bin/querybuilder.json.css?path=/home/users
is resolved to Page.jsp (the resource-type of /content/we-retail.html), see:
!2020-09-17-104013_1554x416_scrot.png!
whereas the true decomposition/resolution will be:
{code}
Extension=css;
resourcePath=/bin/querybuilder.json
selectors=[]
seclectorString=null
suffix=/..;/bin/querybuilder.json.css
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9441) Sling POST servlet responds with 500 if target is not modifiable
Lars Krapf created SLING-9441:
-
Summary: Sling POST servlet responds with 500 if target is not
modifiable
Key: SLING-9441
URL: https://issues.apache.org/jira/browse/SLING-9441
Project: Sling
Issue Type: Bug
Components: Servlets
Affects Versions: Servlets Post 2.3.36
Reporter: Lars Krapf
In case a POST is attempted to a node that the request session does not have
write access to, the POST servlets throws a 500, e.g.
{code}
04.05.2020 21:34:09.162 *ERROR* [xxx.xxx.xxx.xxx [1588628049158] POST
/content/cmo/us/en/home/users/geometrixx/james.dev...@spambob.com/fSPiyhliJm
HTTP/1.1] org.apache.sling.servlets.post.impl.operations.ModifyOperation
Exception during response processing.
org.apache.sling.api.resource.PersistenceException: Unable to create node at
/content/cmo/us/en/home/users
at
org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.create(JcrResourceProvider.java:477)
[org.apache.sling.jcr.resource:3.0.20]
{code}
Since this is actually a client error I think a 4xx response would be better
suited, and make it more obvious that such errors can be safely ignored when
doing health monitoring.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SLING-9043) COPY should be in the referer filter's default list of protected HTTP methods
[ https://issues.apache.org/jira/browse/SLING-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032288#comment-17032288 ] Lars Krapf commented on SLING-9043: --- [~reschke], [~kwin]: [~sonagupt] has updated the PR and added MOVE. Any more concerns from your side? Merci! > COPY should be in the referer filter's default list of protected HTTP methods > - > > Key: SLING-9043 > URL: https://issues.apache.org/jira/browse/SLING-9043 > Project: Sling > Issue Type: Bug > Components: Resource Access Security >Reporter: Sonal Gupta >Priority: Major > Labels: vulnerability > Time Spent: 20m > Remaining Estimate: 0h > > The COPY method , by default, is not in the list of methods covered by the > CSRF Referer filter. This might allow an attacker to copy files (abusing the > privileges of a logged in victim) using CSRF. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9043) COPY should be in the referer filter's default list of protected HTTP methods
[ https://issues.apache.org/jira/browse/SLING-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031455#comment-17031455 ] Lars Krapf commented on SLING-9043: --- [~kwin]: Yes, with proper CORS configuration this issue is mitigated - however, both headers might be stripped in some situations (see also: https://owasp.org/www-project-cheat-sheets/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) and IMHO it wouldn't hurt to add the methods to the referrer filter given that it's already there, and given the many lax CORS configurations out there. > COPY should be in the referer filter's default list of protected HTTP methods > - > > Key: SLING-9043 > URL: https://issues.apache.org/jira/browse/SLING-9043 > Project: Sling > Issue Type: Bug > Components: Resource Access Security >Reporter: Sonal Gupta >Priority: Major > Labels: vulnerability > > The COPY method , by default, is not in the list of methods covered by the > CSRF Referer filter. This might allow an attacker to copy files (abusing the > privileges of a logged in victim) using CSRF. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-9043) COPY should be in the referer filter's default list of protected HTTP methods
[ https://issues.apache.org/jira/browse/SLING-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031428#comment-17031428 ] Lars Krapf commented on SLING-9043: --- Hello [~reschke] COPY (and yes, MOVE as well) are state-changing operations and should ideally be protected against CSRF as a defense-in-depth measure in case of an overly permissive CORS (or even same-site) configuration. The attack consists of luring a victim to an attacker's site, and then do an COPY XHR to the target, abusing the fact that the victim is authenticated and their browser will be automatically sending a session token. Since the referrer will be the attackers site this attack would be mitigated by the referrer filter (analogous to PUT and DELETE already present in the list). > COPY should be in the referer filter's default list of protected HTTP methods > - > > Key: SLING-9043 > URL: https://issues.apache.org/jira/browse/SLING-9043 > Project: Sling > Issue Type: Bug > Components: Resource Access Security >Reporter: Sonal Gupta >Priority: Major > Labels: vulnerability > > The COPY method , by default, is not in the list of methods covered by the > CSRF Referer filter. This might allow an attacker to copy files (abusing the > privileges of a logged in victim) using CSRF. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SLING-7777) XSSFilter is rejecting URLs containing only queries or fragments
Lars Krapf created SLING-: - Summary: XSSFilter is rejecting URLs containing only queries or fragments Key: SLING- URL: https://issues.apache.org/jira/browse/SLING- Project: Sling Issue Type: Bug Components: XSS Protection API Affects Versions: XSS Protection API 2.0.10 Reporter: Lars Krapf Attachments: sling_xssfilter_patch.txt The XSSFilter is erroneously rejecting URLs that consist only of queries, (potentially empty) fragments or both, e.g. "#", "#test", "?foo=bar" etc. Even though the RELATIVE_PART regexp contains an PATH_EMPTY group, it is explicitly matching the *entire* string, so will fail if the QUERY or FRAGMENT groups match. A potential solution (see attached patch and tests) might be to remove the PATH_EMPTY group from the RELATIVE_PART, and make the entire RELATIVE_PART optional by adding ? to the group in RELATIVE_REF. This will still match completely empty URLs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-6438) Add encodeForHTMLAttrName() to XSSAPI
Lars Krapf created SLING-6438:
-
Summary: Add encodeForHTMLAttrName() to XSSAPI
Key: SLING-6438
URL: https://issues.apache.org/jira/browse/SLING-6438
Project: Sling
Issue Type: Improvement
Components: XSS Protection API
Affects Versions: XSS Protection API 1.0.16
Reporter: Lars Krapf
The XSSAPI currently does not provide a method to safely encode HTML attribute
names. This could cause problems if for example attackers were allowed to
define arbitrary "data-" attributes. I don't think Encoder already provides a
context for that, but {{forHtmlUnquotedAttribute}} might just do the trick.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-4560) XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
[
https://issues.apache.org/jira/browse/SLING-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15427306#comment-15427306
]
Lars Krapf edited comment on SLING-4560 at 8/18/16 10:47 PM:
-
Hello [~radu.cotescu]
With this change {{onSiteURL}} will accept spaces and colons and thus does no
longer filter external (and/or " javascript:") URLs.
This could be caught by the following additional
tests:{code:title=XSSAPIImplTest.testfilterHtml()} {"space","space"},
{"http://www.google.com\;>", ""},
{code}
Please note however, that the test mentioned above does not contain bengali /
hindi characters. FWIW, I tried to come up with a hindi test using google
translate:
{code:title=XSSAPIImplTest.testGetValidHref()}
{"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
{"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995",
"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995"},
{code}
Nonetheless, the summary is correct, this test too fails with the old regexps.
The reason for this is that the unicode "letter" character class
{code}\p{L}{code} is matching single unicode *code points* only. To match any
letter including diacritics, one might use {code}\p{L}\p{M}*+{code}. See also
[1] ("Unicode Categories").
I've added a corresponding patch to the regexp (changing only the character
class) and added a couple of tests.
Note, The test provided by [~jck] *would still fail* even with this change, but
AFAICT that's correct, since these characters are symbols and not letters.
was (Author: chaotic):
Hello [~radu.cotescu]
With this change {{onSiteURL}} will accept spaces and colons and thus does no
longer filter external (and/or " javascript:") URLs.
This could be caught by the following additional
tests:{code:title=XSSAPIImplTest.testfilterHtml()} {"space","space"},
{"http://www.google.com\;>", ""},
{code}
Please note however, that the test mentioned above does not contain bengali /
hindi characters. FWIW, I tried to come up with a hindi test using google
translate:
{code:title=XSSAPIImplTest.testGetValidHref()}
{"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
{"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995",
"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995"},
{code}
Nonetheless, the summary is correct, this test too fails with the old regexps.
The reason for this is that the unicode "letter" character class \\p\{L\} is
matching single unicode *code points* only. To match any letter including
diacritics, one might use \\p\{L\}\\p\{M\}*+. See also [1] ("Unicode
Categories").
I've added a corresponding patch to the regexp (changing only the character
class) and added a couple of tests.
Note, The test provided by [~jck] *would still fail* even with this change, but
AFAICT that's correct, since these characters are symbols and not letters.
> XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
> --
>
> Key: SLING-4560
> URL: https://issues.apache.org/jira/browse/SLING-4560
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.0
>Reporter: Jean-Christophe Kautzmann
>Assignee: Radu Cotescu
> Fix For: XSS Protection API 1.0.14
>
> Attachments: xssapi.patch
>
>
> I added (locally) 2 test cases to
> org.apache.sling.xss.impl.XSSAPIImplTest#testGetValidHref:
> {code}
> {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
> {"/etc/commerce/collections/⺁〡〢☉⊕〒", "/etc/commerce/collections/⺁〡〢☉⊕〒"},
> {code}
> the first test passes (chinese characters), the 2nd fails (bengali/hindi
> characters) although it should pass as they are valid characters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-4560) XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
[
https://issues.apache.org/jira/browse/SLING-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15427306#comment-15427306
]
Lars Krapf edited comment on SLING-4560 at 8/18/16 10:47 PM:
-
Hello [~radu.cotescu]
With this change {{onSiteURL}} will accept spaces and colons and thus does no
longer filter external (and/or " javascript:") URLs.
This could be caught by the following additional
tests:{code:title=XSSAPIImplTest.testfilterHtml()} {"space","space"},
{"http://www.google.com\;>", ""},
{code}
Please note however, that the test mentioned above does not contain bengali /
hindi characters. FWIW, I tried to come up with a hindi test using google
translate:
{code:title=XSSAPIImplTest.testGetValidHref()}
{"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
{"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995",
"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995"},
{code}
Nonetheless, the summary is correct, this test too fails with the old regexps.
The reason for this is that the unicode "letter" character class \\p\{L\} is
matching single unicode *code points* only. To match any letter including
diacritics, one might use \\p\{L\}\\p\{M\}*+. See also [1] ("Unicode
Categories").
I've added a corresponding patch to the regexp (changing only the character
class) and added a couple of tests.
Note, The test provided by [~jck] *would still fail* even with this change, but
AFAICT that's correct, since these characters are symbols and not letters.
was (Author: chaotic):
Hello [~radu.cotescu]
With this change {{onSiteURL}} will accept spaces and colons and thus does no
longer filter external (and/or " javascript:") URLs.
This could be caught by the following additional
tests:{code:title=XSSAPIImplTest.testfilterHtml()} {"space","space"},
{"http://www.google.com\;>", ""},
{code}
Please note however, that the test mentioned above does not contain bengali /
hindi characters. FWIW, I tried to come up with a hindi test using google
translate:
{code:title=XSSAPIImplTest.testGetValidHref()}
{"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
{"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995",
"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995"},
{code}
Nonetheless, the summary is correct, this test too fails with the old regexps.
The reason for this is that the unicode "letter" character class \p{L} is
matching single unicode *code points* only. To match any letter including
diacritics, one might use \P{L}\p{M}*+. See also [1] ("Unicode Categories").
I've added a corresponding patch to the regexp (changing only the character
class) and added a couple of tests.
Note, The test provided by [~jck] *would still fail* even with this change, but
AFAICT that's correct, since these characters are symbols and not letters.
> XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
> --
>
> Key: SLING-4560
> URL: https://issues.apache.org/jira/browse/SLING-4560
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.0
>Reporter: Jean-Christophe Kautzmann
>Assignee: Radu Cotescu
> Fix For: XSS Protection API 1.0.14
>
> Attachments: xssapi.patch
>
>
> I added (locally) 2 test cases to
> org.apache.sling.xss.impl.XSSAPIImplTest#testGetValidHref:
> {code}
> {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
> {"/etc/commerce/collections/⺁〡〢☉⊕〒", "/etc/commerce/collections/⺁〡〢☉⊕〒"},
> {code}
> the first test passes (chinese characters), the 2nd fails (bengali/hindi
> characters) although it should pass as they are valid characters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SLING-4560) XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
[
https://issues.apache.org/jira/browse/SLING-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Krapf updated SLING-4560:
--
Attachment: xssapi.patch
Adding potential patch.
> XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
> --
>
> Key: SLING-4560
> URL: https://issues.apache.org/jira/browse/SLING-4560
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.0
>Reporter: Jean-Christophe Kautzmann
>Assignee: Radu Cotescu
> Fix For: XSS Protection API 1.0.14
>
> Attachments: xssapi.patch
>
>
> I added (locally) 2 test cases to
> org.apache.sling.xss.impl.XSSAPIImplTest#testGetValidHref:
> {code}
> {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
> {"/etc/commerce/collections/⺁〡〢☉⊕〒", "/etc/commerce/collections/⺁〡〢☉⊕〒"},
> {code}
> the first test passes (chinese characters), the 2nd fails (bengali/hindi
> characters) although it should pass as they are valid characters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SLING-4560) XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
[
https://issues.apache.org/jira/browse/SLING-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15427306#comment-15427306
]
Lars Krapf edited comment on SLING-4560 at 8/18/16 10:44 PM:
-
Hello [~radu.cotescu]
With this change {{onSiteURL}} will accept spaces and colons and thus does no
longer filter external (and/or " javascript:") URLs.
This could be caught by the following additional
tests:{code:title=XSSAPIImplTest.testfilterHtml()} {"space","space"},
{"http://www.google.com\;>", ""},
{code}
Please note however, that the test mentioned above does not contain bengali /
hindi characters. FWIW, I tried to come up with a hindi test using google
translate:
{code:title=XSSAPIImplTest.testGetValidHref()}
{"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
{"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995",
"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995"},
{code}
Nonetheless, the summary is correct, this test too fails with the old regexps.
The reason for this is that the unicode "letter" character class \p{L} is
matching single unicode *code points* only. To match any letter including
diacritics, one might use \P{L}\p{M}*+. See also [1] ("Unicode Categories").
I've added a corresponding patch to the regexp (changing only the character
class) and added a couple of tests.
Note, The test provided by [~jck] *would still fail* even with this change, but
AFAICT that's correct, since these characters are symbols and not letters.
was (Author: chaotic):
Hello [~radu.cotescu]
With this change {{onSiteURL}} will accept spaces and colons and thus does no
longer filter external (and/or " javascript:") URLs.
This could be caught by the following additional
tests:{code:title=XSSAPIImplTest.testfilterHtml()} {"space","space"},
{"http://www.google.com\;>", ""},
{code}
Please note however, that the added test does not contain bengali / hindi
characters. FWIW, I tried to come up with a hindi test using google translate:
{code:title=XSSAPIImplTest.testGetValidHref()}
{"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
{"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995",
"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995"},
{code}
Nonetheless, the summary is correct, this test too fails with the old regexps.
The reason for this is that the unicode "letter" character class \p{L} is
matching single unicode *code points* only. To match any letter including
diacritics, one might use \P{L}\p{M}*+. See also [1] ("Unicode Categories").
I've added a corresponding patch to the regexp (changing only the character
class) and added a couple of tests.
Note, The test provided by [~jck] *would still fail* even with this change, but
AFAICT that's correct, since these characters are symbols and not letters.
> XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
> --
>
> Key: SLING-4560
> URL: https://issues.apache.org/jira/browse/SLING-4560
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.0
>Reporter: Jean-Christophe Kautzmann
>Assignee: Radu Cotescu
> Fix For: XSS Protection API 1.0.14
>
> Attachments: xssapi.patch
>
>
> I added (locally) 2 test cases to
> org.apache.sling.xss.impl.XSSAPIImplTest#testGetValidHref:
> {code}
> {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
> {"/etc/commerce/collections/⺁〡〢☉⊕〒", "/etc/commerce/collections/⺁〡〢☉⊕〒"},
> {code}
> the first test passes (chinese characters), the 2nd fails (bengali/hindi
> characters) although it should pass as they are valid characters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4560) XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
[
https://issues.apache.org/jira/browse/SLING-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15427306#comment-15427306
]
Lars Krapf commented on SLING-4560:
---
Hello [~radu.cotescu]
With this change {{onSiteURL}} will accept spaces and colons and thus does no
longer filter external (and/or " javascript:") URLs.
This could be caught by the following additional
tests:{code:title=XSSAPIImplTest.testfilterHtml()} {"space","space"},
{"http://www.google.com\;>", ""},
{code}
Please note however, that the added test does not contain bengali / hindi
characters. FWIW, I tried to come up with a hindi test using google translate:
{code:title=XSSAPIImplTest.testGetValidHref()}
{"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
{"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995",
"/etc/commerce/collections/\u09aa\u09b0\u09c0\u0995\u09cd\u09b7\u09be\u09ae\u09c2\u09b2\u0995"},
{code}
Nonetheless, the summary is correct, this test too fails with the old regexps.
The reason for this is that the unicode "letter" character class \p{L} is
matching single unicode *code points* only. To match any letter including
diacritics, one might use \P{L}\p{M}*+. See also [1] ("Unicode Categories").
I've added a corresponding patch to the regexp (changing only the character
class) and added a couple of tests.
Note, The test provided by [~jck] *would still fail* even with this change, but
AFAICT that's correct, since these characters are symbols and not letters.
> XSSAPI#getValidHref is empty for valid Bengali or Hindi characters
> --
>
> Key: SLING-4560
> URL: https://issues.apache.org/jira/browse/SLING-4560
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
>Affects Versions: XSS Protection API 1.0.0
>Reporter: Jean-Christophe Kautzmann
>Assignee: Radu Cotescu
> Fix For: XSS Protection API 1.0.14
>
>
> I added (locally) 2 test cases to
> org.apache.sling.xss.impl.XSSAPIImplTest#testGetValidHref:
> {code}
> {"/etc/commerce/collections/中文", "/etc/commerce/collections/中文"},
> {"/etc/commerce/collections/⺁〡〢☉⊕〒", "/etc/commerce/collections/⺁〡〢☉⊕〒"},
> {code}
> the first test passes (chinese characters), the 2nd fails (bengali/hindi
> characters) although it should pass as they are valid characters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-5675) Logout only called if AuthenticationHandler is registered to "/"
Lars Krapf created SLING-5675:
-
Summary: Logout only called if AuthenticationHandler is registered
to "/"
Key: SLING-5675
URL: https://issues.apache.org/jira/browse/SLING-5675
Project: Sling
Issue Type: Bug
Components: Authentication
Affects Versions: Auth Core 1.3.14
Reporter: Lars Krapf
In {{SlingAuthenticator.logout()}} only the AuthenticationHandlers which are
registered on paths which are roots of
{{SlingAuthenticator.getHandlerSelectionPath()}} are selected.
This path should either be taken from the servlet path, or will be read from
the {{Authenticator.LOGIN_RESOURCE}} request attribute _if it is present_.
Now, in {{LogoutServlet.service()}} the LOGIN_RESOURCE is _always_ set to it's
default value ("/") by calling {{AuthUtil.setLoginResourceAttribute()}}.
As a result, {{dropCredentials()}} will only be called on authentication
handlers which are registered to "/".
My expectation is that the selection of logout handlers should be independent
of their registration paths, in order to allow a POST to
{{/system/sling/logout}} have *all* registered handlers drop credentials.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SLING-4701) SlingAuthenticator.isAnonAllowed matches for all paths starting with the same characters
Lars Krapf created SLING-4701: - Summary: SlingAuthenticator.isAnonAllowed matches for all paths starting with the same characters Key: SLING-4701 URL: https://issues.apache.org/jira/browse/SLING-4701 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.3.6 Reporter: Lars Krapf The SlingAuthenticator check if anonymous access is allowed compares paths with String.startsWith. If the holder.path does not end with a '/' it will erroneously match a different path that starts with the same characters, even if it is not a descendant of the first path. Example: - Allow anonymous acces on '/' - Deny anonymous access on a path '/blubb' - Authentication is enforced on a request to '/blubb-blah' - which is wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4701) SlingAuthenticator.isAnonAllowed matches for all paths starting with the same characters
[ https://issues.apache.org/jira/browse/SLING-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Krapf updated SLING-4701: -- Attachment: SlingAuthenticator.patch Attached possible patch. SlingAuthenticator.isAnonAllowed matches for all paths starting with the same characters Key: SLING-4701 URL: https://issues.apache.org/jira/browse/SLING-4701 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.3.6 Reporter: Lars Krapf Labels: authentication Attachments: SlingAuthenticator.patch The SlingAuthenticator check if anonymous access is allowed compares paths with String.startsWith. If the holder.path does not end with a '/' it will erroneously match a different path that starts with the same characters, even if it is not a descendant of the first path. Example: - Allow anonymous acces on '/' - Deny anonymous access on a path '/blubb' - Authentication is enforced on a request to '/blubb-blah' - which is wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4413) :applyTo should send 403 instead of 500 when operation fails
[ https://issues.apache.org/jira/browse/SLING-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Krapf updated SLING-4413: -- Summary: :applyTo should send 403 instead of 500 when operation fails (was: :applyTo should send 403 instead of 500 when operation fails) :applyTo should send 403 instead of 500 when operation fails - Key: SLING-4413 URL: https://issues.apache.org/jira/browse/SLING-4413 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.3.6 Reporter: Lars Krapf Priority: Minor Example: curl -vv curl -F:operation=delete -F:applyTo=/etc/* http://localhost:4502/content/geometrixx Will give you a 500 (PersistenceException) in case /etc/* is not writable to the request session - as discussed with Felix Carsten this should rather be a 403. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4414) :applyTo should only apply to requested resource (and below)
Lars Krapf created SLING-4414: - Summary: :applyTo should only apply to requested resource (and below) Key: SLING-4414 URL: https://issues.apache.org/jira/browse/SLING-4414 Project: Sling Issue Type: Improvement Components: Servlets Affects Versions: Servlets Post 2.3.6 Reporter: Lars Krapf Priority: Minor :applyTo operations currently accept arbitrary paths that are independent from the requested resource. In the spirit of REST they should only accept relative paths below the requested node. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4415) :applyTo should not display changeLog (when operation fails)
Lars Krapf created SLING-4415: - Summary: :applyTo should not display changeLog (when operation fails) Key: SLING-4415 URL: https://issues.apache.org/jira/browse/SLING-4415 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.3.6 Reporter: Lars Krapf When the :applyTo operation fails the change-log leaks information about the internal path-structure even when the requesting session does not have access to these paths. One solution would be to completely omit the ChangeLog (at least when the operation fails), another option would be to make the :sendError behaviour configurable in the POST servlet, so that the error message can be reliably overlaid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-4413) :applyTo should send 403 instead of 500 when operation fails
Lars Krapf created SLING-4413: - Summary: :applyTo should send 403 instead of 500 when operation fails Key: SLING-4413 URL: https://issues.apache.org/jira/browse/SLING-4413 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Post 2.3.6 Reporter: Lars Krapf Priority: Minor Example: curl -vv curl -F:operation=delete -F:applyTo=/etc/* http://localhost:4502/content/geometrixx Will give you a 500 (PersistenceException) in case /etc/* is not writable to the request session - as discussed with Felix Carsten this should rather be a 403. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SLING-2966) Insufficient synchronization in SlingAuthenticator
Lars Krapf created SLING-2966: - Summary: Insufficient synchronization in SlingAuthenticator Key: SLING-2966 URL: https://issues.apache.org/jira/browse/SLING-2966 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.1.2 Reporter: Lars Krapf In the serviceChanged method of SlingAuthenticator a service is removed and subsequently re-added in case of a modification event. This can lead to synchronization problems (e.g. remove, remove, add, add) if two threads trigger this handler at the same time (e.g. duplication of CUG roots in the holder-cache of the CQ CUG handler after activation of a page with alias). -- 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] [Updated] (SLING-2966) Insufficient synchronization in SlingAuthenticator
[ https://issues.apache.org/jira/browse/SLING-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Krapf updated SLING-2966: -- Attachment: sling_authenticator.patch Attached a possible patch: synchronizing the whole serviceChanged() method. Insufficient synchronization in SlingAuthenticator -- Key: SLING-2966 URL: https://issues.apache.org/jira/browse/SLING-2966 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.1.2 Reporter: Lars Krapf Labels: authentication, sling Attachments: sling_authenticator.patch In the serviceChanged method of SlingAuthenticator a service is removed and subsequently re-added in case of a modification event. This can lead to synchronization problems (e.g. remove, remove, add, add) if two threads trigger this handler at the same time (e.g. duplication of CUG roots in the holder-cache of the CQ CUG handler after activation of a page with alias). -- 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
