[
https://issues.apache.org/jira/browse/SLING-13333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Hoh updated SLING-13333:
------------------------------
Description:
An internal error-recovery path used during HTML/URL sanitization could, under
certain conditions, cause sanitization to fall back to an alternate code path
whose behavior was less strict than the primary path, reducing the
effectiveness of input sanitization in some scenarios.
Also address excessive resource consumption in the same area.
h5. Details:
* XSSFilterImpl: StackOverflow fallback sanitizer admits {{javascript:}} hrefs
in {{{}filterHTML{}}}.
* XSSFilterImpl: Polynomial ReDoS in {{OFF_SITE_SIMPLIFIED}} fallback href
regex.
* HtmlToHtmlContentContext: Second {{StackOverflowError}} escapes
{{filterHTML}} fallback scan.
* MapBuilder: {{maxInputSize}} and other policy directives parsed but never
enforced.
* AntiSamyPolicyAdapter: {{maxInputSize}} and other policy directives parsed
but never enforced.
h5. Relevant change: {{MaxInputSize}} policy was ignored
* Previously, {{AntiSamyXmlParser}} parsed all directives from the policy XML
into a map, but only ever _acted_ on {{embedStyleSheets}} (a warning if set to
{{{}true{}}}). {{maxInputSize}} was parsed and then discarded —
{{HtmlSanitizer.scan()}} had {*}no size check at all{*}, regardless of input
length.
* Now, if the policy XML declares {{{}maxInputSize{}}}, inputs longer than
that limit are rejected fail-closed ({{{}scan(){}}} returns an empty, errored
{{{}SanitizedResult{}}}, so {{filter()}} returns {{""}} and {{check()}} returns
{{{}false{}}}).
Commit:
https://github.com/apache/sling-org-apache-sling-xss/commit/1ccb98684672eb99d8db4245d83aeb939c6bb5b4
was:
An internal error-recovery path used during HTML/URL sanitization could, under
certain conditions, cause sanitization to fall back to an alternate code path
whose behavior was less strict than the primary path, reducing the
effectiveness of input sanitization in some scenarios.
Also address excessive resource consumption in the same area.
> Fix potential HTML sanitization weakness in fallback error-handling path
> ------------------------------------------------------------------------
>
> Key: SLING-13333
> URL: https://issues.apache.org/jira/browse/SLING-13333
> Project: Sling
> Issue Type: Improvement
> Components: XSS Protection API
> Reporter: Joerg Hoh
> Assignee: Joerg Hoh
> Priority: Major
> Fix For: XSS Protection API 2.4.12
>
>
> An internal error-recovery path used during HTML/URL sanitization could,
> under certain conditions, cause sanitization to fall back to an alternate
> code path whose behavior was less strict than the primary path, reducing the
> effectiveness of input sanitization in some scenarios.
> Also address excessive resource consumption in the same area.
> h5. Details:
> * XSSFilterImpl: StackOverflow fallback sanitizer admits {{javascript:}}
> hrefs in {{{}filterHTML{}}}.
> * XSSFilterImpl: Polynomial ReDoS in {{OFF_SITE_SIMPLIFIED}} fallback href
> regex.
> * HtmlToHtmlContentContext: Second {{StackOverflowError}} escapes
> {{filterHTML}} fallback scan.
> * MapBuilder: {{maxInputSize}} and other policy directives parsed but never
> enforced.
> * AntiSamyPolicyAdapter: {{maxInputSize}} and other policy directives parsed
> but never enforced.
> h5. Relevant change: {{MaxInputSize}} policy was ignored
> * Previously, {{AntiSamyXmlParser}} parsed all directives from the policy
> XML into a map, but only ever _acted_ on {{embedStyleSheets}} (a warning if
> set to {{{}true{}}}). {{maxInputSize}} was parsed and then discarded —
> {{HtmlSanitizer.scan()}} had {*}no size check at all{*}, regardless of input
> length.
> * Now, if the policy XML declares {{{}maxInputSize{}}}, inputs longer than
> that limit are rejected fail-closed ({{{}scan(){}}} returns an empty, errored
> {{{}SanitizedResult{}}}, so {{filter()}} returns {{""}} and {{check()}}
> returns {{{}false{}}}).
>
> Commit:
> https://github.com/apache/sling-org-apache-sling-xss/commit/1ccb98684672eb99d8db4245d83aeb939c6bb5b4
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
