html_sanitize_ex

Summary

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to inject CSS at-rules, including an import of a remote stylesheet, into a page served to other users. HtmlSanitizeEx.Scrubber.CSS.scrub/1 applies its property and value allowlist through a Regex.replace over substrings matching a property: value declaration pattern, so input that does not match that pattern is never inspected and is copied to the output unchanged. @import url(//attacker.example/style.css); survives, while the same URL inside a background: url(...) declaration is removed.

Element boundaries are resolved before the scrubber runs, so injected content does not escape the <style> element and no script executes.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.4.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow <style> elements, or define a custom scrubber that omits it.

A Content-Security-Policy style-src directive that permits no external stylesheet origins stops an injected @import from loading, though injected inline rules still apply.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, permit <style> elements, and the sanitized output must be rendered to other users. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

Inefficient Algorithmic Complexity vulnerability in the traversal engine in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU and memory via a flat run of sibling elements in sanitized HTML. The list clause of HtmlSanitizeEx.Traverser.traverse/2 recurses on the tail of a sibling list and then evaluates List.flatten([head] ++ tail) over the already flattened result, so every one of n siblings copies and re-walks the entire remaining tail. The flattening is only needed for the rare case where scrub returns several replacement nodes for one node, but the cost is paid across the whole tail at every step, making traversal quadratic in sibling count.

The traverser sits on every public entry point, so no particular scrubber or configuration is required and the payload needs only allowed tags. A 160 KB body of 20,000 sibling elements occupies a scheduler for roughly 1.7 seconds, and the cost grows faster than the body does.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Cap the size of user-supplied HTML, and in particular the node count, before it reaches the sanitizer. The quadratic growth means the cap has to be small to be effective.

Summary

Inefficient Regular Expression Complexity vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU via a long CSS declaration in sanitized HTML. The declaration regex in HtmlSanitizeEx.Scrubber.CSS.scrub/1 matches the property name with an unbounded greedy [-\w]+ followed by a mandatory :, so a long run of word characters not followed by a colon makes the engine give back one character at a time and retry the colon at every start offset. The work is quadratic in the length of the run, and no length cap is applied to the CSS handed to the scrubber. An 80 KB <style> body costs roughly 2.4 seconds of scheduler time, so a few concurrent requests saturate the BEAM scheduler pool and make the application unresponsive.

The impact is CPU exhaustion only. Nothing is read, modified or disclosed.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which reach the CSS scrubber, or define a custom scrubber that allows neither <style> elements nor style attributes.

Capping the size of user-supplied HTML before it reaches the sanitizer bounds the cost, though the quadratic growth means the cap has to be small to be effective.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, route input into the CSS scrubber, by way of <style> element bodies and style attributes. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to inject CSS at-rules, including an import of a remote stylesheet, into a page served to other users. HtmlSanitizeEx.Scrubber.CSS.scrub/1 applies its property and value allowlist through a Regex.replace over substrings matching a property: value declaration pattern, so input that does not match that pattern is never inspected and is copied to the output unchanged. @import url(//attacker.example/style.css); survives, while the same URL inside a background: url(...) declaration is removed.

Element boundaries are resolved before the scrubber runs, so injected content does not escape the <style> element and no script executes.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.4.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow <style> elements, or define a custom scrubber that omits it.

A Content-Security-Policy style-src directive that permits no external stylesheet origins stops an injected @import from loading, though injected inline rules still apply.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, permit <style> elements, and the sanitized output must be rendered to other users. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to force visitors of a page to navigate to a site of the attacker's choosing via a <meta http-equiv="refresh"> element in sanitized HTML. HtmlSanitizeEx.html5/1 keeps attacker-supplied <meta> elements in its output. A meta element acts on the whole document rather than on the fragment it was embedded in, so it can also declare document-wide directives such as Content-Security-Policy.

This is not cross-site scripting. Browsers do not navigate a meta refresh to a javascript: URL, so the uppercase JAVASCRIPT: filter bypass yields no script execution and none was demonstrated.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow meta, or define a custom scrubber that omits it.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the meta element, and the sanitized output must be rendered to other users.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to retarget a form already on the rendering page and receive whatever the victim submits, including credentials, via the form and formaction attributes on an <input> element in sanitized HTML. HTML's form attribute associates an input with any form on the page by its id even when the input sits outside that form, and formaction on a submit control overrides the owning form's action. Neither attribute receives a scheme check, so an absolute cross-origin URL survives sanitizing.

No script executes. The scrubber allows neither form nor button, so the attacker cannot introduce a form of their own and the rendering page must already contain a form carrying an id.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow input, or define a custom scrubber that omits it.

Omitting the id attribute from the page's own forms, or giving them values an attacker cannot predict, removes the anchor the injected form attribute needs.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the input element, and the sanitized output must be rendered to other users.

The rendering page must also contain a form with an id, since that id is what the injected form attribute binds to.

Summary

Inclusion of Functionality from Untrusted Control Sphere vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to load a document of their choosing into a trusted page via the data attribute of an <object> element in sanitized HTML. object is the one URI-bearing element in lib/html_sanitize_ex/scrubber/html5.ex never registered through allow_tag_with_uri_attributes/3, and its only guard is a prefix match on lowercase "javascript:", so mixed-case variants, data: URIs, protocol-relative URLs and same-origin paths all survive.

This is not unconditional cross-site scripting. A javascript: URL does not execute through <object data> in current browsers, data: documents load in an opaque origin, and host-origin script execution additionally requires the application to serve attacker-controlled content from a same-origin path.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow object, or define a custom scrubber that omits it.

A Content-Security-Policy of object-src 'none' blocks an injected <object> from loading, and hosting user uploads on a separate origin removes the escalation path.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the object element, and the sanitized output must be rendered to other users.

Script execution in the host origin additionally requires the application to serve attacker-controlled HTML from a same-origin path, such as an uploads directory served as text/html.

Summary

Inefficient Algorithmic Complexity vulnerability in the traversal engine in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU and memory via a flat run of sibling elements in sanitized HTML. The list clause of HtmlSanitizeEx.Traverser.traverse/2 recurses on the tail of a sibling list and then evaluates List.flatten([head] ++ tail) over the already flattened result, so every one of n siblings copies and re-walks the entire remaining tail. The flattening is only needed for the rare case where scrub returns several replacement nodes for one node, but the cost is paid across the whole tail at every step, making traversal quadratic in sibling count.

The traverser sits on every public entry point, so no particular scrubber or configuration is required and the payload needs only allowed tags. A 160 KB body of 20,000 sibling elements occupies a scheduler for roughly 1.7 seconds, and the cost grows faster than the body does.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Cap the size of user-supplied HTML, and in particular the node count, before it reaches the sanitizer. The quadratic growth means the cap has to be small to be effective.

Summary

Inefficient Regular Expression Complexity vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU via a long CSS declaration in sanitized HTML. The declaration regex in HtmlSanitizeEx.Scrubber.CSS.scrub/1 matches the property name with an unbounded greedy [-\w]+ followed by a mandatory :, so a long run of word characters not followed by a colon makes the engine give back one character at a time and retry the colon at every start offset. The work is quadratic in the length of the run, and no length cap is applied to the CSS handed to the scrubber. An 80 KB <style> body costs roughly 2.4 seconds of scheduler time, so a few concurrent requests saturate the BEAM scheduler pool and make the application unresponsive.

The impact is CPU exhaustion only. Nothing is read, modified or disclosed.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which reach the CSS scrubber, or define a custom scrubber that allows neither <style> elements nor style attributes.

Capping the size of user-supplied HTML before it reaches the sanitizer bounds the cost, though the quadratic growth means the cap has to be small to be effective.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, route input into the CSS scrubber, by way of <style> element bodies and style attributes. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to inject CSS at-rules, including an import of a remote stylesheet, into a page served to other users. HtmlSanitizeEx.Scrubber.CSS.scrub/1 applies its property and value allowlist through a Regex.replace over substrings matching a property: value declaration pattern, so input that does not match that pattern is never inspected and is copied to the output unchanged. @import url(//attacker.example/style.css); survives, while the same URL inside a background: url(...) declaration is removed.

Element boundaries are resolved before the scrubber runs, so injected content does not escape the <style> element and no script executes.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.4.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow <style> elements, or define a custom scrubber that omits it.

A Content-Security-Policy style-src directive that permits no external stylesheet origins stops an injected @import from loading, though injected inline rules still apply.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, permit <style> elements, and the sanitized output must be rendered to other users. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to force visitors of a page to navigate to a site of the attacker's choosing via a <meta http-equiv="refresh"> element in sanitized HTML. HtmlSanitizeEx.html5/1 keeps attacker-supplied <meta> elements in its output. A meta element acts on the whole document rather than on the fragment it was embedded in, so it can also declare document-wide directives such as Content-Security-Policy.

This is not cross-site scripting. Browsers do not navigate a meta refresh to a javascript: URL, so the uppercase JAVASCRIPT: filter bypass yields no script execution and none was demonstrated.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow meta, or define a custom scrubber that omits it.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the meta element, and the sanitized output must be rendered to other users.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to retarget a form already on the rendering page and receive whatever the victim submits, including credentials, via the form and formaction attributes on an <input> element in sanitized HTML. HTML's form attribute associates an input with any form on the page by its id even when the input sits outside that form, and formaction on a submit control overrides the owning form's action. Neither attribute receives a scheme check, so an absolute cross-origin URL survives sanitizing.

No script executes. The scrubber allows neither form nor button, so the attacker cannot introduce a form of their own and the rendering page must already contain a form carrying an id.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow input, or define a custom scrubber that omits it.

Omitting the id attribute from the page's own forms, or giving them values an attacker cannot predict, removes the anchor the injected form attribute needs.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the input element, and the sanitized output must be rendered to other users.

The rendering page must also contain a form with an id, since that id is what the injected form attribute binds to.

Summary

Inclusion of Functionality from Untrusted Control Sphere vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to load a document of their choosing into a trusted page via the data attribute of an <object> element in sanitized HTML. object is the one URI-bearing element in lib/html_sanitize_ex/scrubber/html5.ex never registered through allow_tag_with_uri_attributes/3, and its only guard is a prefix match on lowercase "javascript:", so mixed-case variants, data: URIs, protocol-relative URLs and same-origin paths all survive.

This is not unconditional cross-site scripting. A javascript: URL does not execute through <object data> in current browsers, data: documents load in an opaque origin, and host-origin script execution additionally requires the application to serve attacker-controlled content from a same-origin path.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow object, or define a custom scrubber that omits it.

A Content-Security-Policy of object-src 'none' blocks an injected <object> from loading, and hosting user uploads on a separate origin removes the escalation path.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the object element, and the sanitized output must be rendered to other users.

Script execution in the host origin additionally requires the application to serve attacker-controlled HTML from a same-origin path, such as an uploads directory served as text/html.

Summary

Inefficient Algorithmic Complexity vulnerability in the traversal engine in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU and memory via a flat run of sibling elements in sanitized HTML. The list clause of HtmlSanitizeEx.Traverser.traverse/2 recurses on the tail of a sibling list and then evaluates List.flatten([head] ++ tail) over the already flattened result, so every one of n siblings copies and re-walks the entire remaining tail. The flattening is only needed for the rare case where scrub returns several replacement nodes for one node, but the cost is paid across the whole tail at every step, making traversal quadratic in sibling count.

The traverser sits on every public entry point, so no particular scrubber or configuration is required and the payload needs only allowed tags. A 160 KB body of 20,000 sibling elements occupies a scheduler for roughly 1.7 seconds, and the cost grows faster than the body does.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Cap the size of user-supplied HTML, and in particular the node count, before it reaches the sanitizer. The quadratic growth means the cap has to be small to be effective.

Summary

Inefficient Regular Expression Complexity vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU via a long CSS declaration in sanitized HTML. The declaration regex in HtmlSanitizeEx.Scrubber.CSS.scrub/1 matches the property name with an unbounded greedy [-\w]+ followed by a mandatory :, so a long run of word characters not followed by a colon makes the engine give back one character at a time and retry the colon at every start offset. The work is quadratic in the length of the run, and no length cap is applied to the CSS handed to the scrubber. An 80 KB <style> body costs roughly 2.4 seconds of scheduler time, so a few concurrent requests saturate the BEAM scheduler pool and make the application unresponsive.

The impact is CPU exhaustion only. Nothing is read, modified or disclosed.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which reach the CSS scrubber, or define a custom scrubber that allows neither <style> elements nor style attributes.

Capping the size of user-supplied HTML before it reaches the sanitizer bounds the cost, though the quadratic growth means the cap has to be small to be effective.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, route input into the CSS scrubber, by way of <style> element bodies and style attributes. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to inject CSS at-rules, including an import of a remote stylesheet, into a page served to other users. HtmlSanitizeEx.Scrubber.CSS.scrub/1 applies its property and value allowlist through a Regex.replace over substrings matching a property: value declaration pattern, so input that does not match that pattern is never inspected and is copied to the output unchanged. @import url(//attacker.example/style.css); survives, while the same URL inside a background: url(...) declaration is removed.

Element boundaries are resolved before the scrubber runs, so injected content does not escape the <style> element and no script executes.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.4.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow <style> elements, or define a custom scrubber that omits it.

A Content-Security-Policy style-src directive that permits no external stylesheet origins stops an injected @import from loading, though injected inline rules still apply.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, permit <style> elements, and the sanitized output must be rendered to other users. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to force visitors of a page to navigate to a site of the attacker's choosing via a <meta http-equiv="refresh"> element in sanitized HTML. HtmlSanitizeEx.html5/1 keeps attacker-supplied <meta> elements in its output. A meta element acts on the whole document rather than on the fragment it was embedded in, so it can also declare document-wide directives such as Content-Security-Policy.

This is not cross-site scripting. Browsers do not navigate a meta refresh to a javascript: URL, so the uppercase JAVASCRIPT: filter bypass yields no script execution and none was demonstrated.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow meta, or define a custom scrubber that omits it.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the meta element, and the sanitized output must be rendered to other users.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to retarget a form already on the rendering page and receive whatever the victim submits, including credentials, via the form and formaction attributes on an <input> element in sanitized HTML. HTML's form attribute associates an input with any form on the page by its id even when the input sits outside that form, and formaction on a submit control overrides the owning form's action. Neither attribute receives a scheme check, so an absolute cross-origin URL survives sanitizing.

No script executes. The scrubber allows neither form nor button, so the attacker cannot introduce a form of their own and the rendering page must already contain a form carrying an id.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow input, or define a custom scrubber that omits it.

Omitting the id attribute from the page's own forms, or giving them values an attacker cannot predict, removes the anchor the injected form attribute needs.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the input element, and the sanitized output must be rendered to other users.

The rendering page must also contain a form with an id, since that id is what the injected form attribute binds to.

Summary

Inclusion of Functionality from Untrusted Control Sphere vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to load a document of their choosing into a trusted page via the data attribute of an <object> element in sanitized HTML. object is the one URI-bearing element in lib/html_sanitize_ex/scrubber/html5.ex never registered through allow_tag_with_uri_attributes/3, and its only guard is a prefix match on lowercase "javascript:", so mixed-case variants, data: URIs, protocol-relative URLs and same-origin paths all survive.

This is not unconditional cross-site scripting. A javascript: URL does not execute through <object data> in current browsers, data: documents load in an opaque origin, and host-origin script execution additionally requires the application to serve attacker-controlled content from a same-origin path.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow object, or define a custom scrubber that omits it.

A Content-Security-Policy of object-src 'none' blocks an injected <object> from loading, and hosting user uploads on a separate origin removes the escalation path.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the object element, and the sanitized output must be rendered to other users.

Script execution in the host origin additionally requires the application to serve attacker-controlled HTML from a same-origin path, such as an uploads directory served as text/html.

Summary

Inefficient Algorithmic Complexity vulnerability in the traversal engine in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU and memory via a flat run of sibling elements in sanitized HTML. The list clause of HtmlSanitizeEx.Traverser.traverse/2 recurses on the tail of a sibling list and then evaluates List.flatten([head] ++ tail) over the already flattened result, so every one of n siblings copies and re-walks the entire remaining tail. The flattening is only needed for the rare case where scrub returns several replacement nodes for one node, but the cost is paid across the whole tail at every step, making traversal quadratic in sibling count.

The traverser sits on every public entry point, so no particular scrubber or configuration is required and the payload needs only allowed tags. A 160 KB body of 20,000 sibling elements occupies a scheduler for roughly 1.7 seconds, and the cost grows faster than the body does.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Cap the size of user-supplied HTML, and in particular the node count, before it reaches the sanitizer. The quadratic growth means the cap has to be small to be effective.

Summary

Inefficient Regular Expression Complexity vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU via a long CSS declaration in sanitized HTML. The declaration regex in HtmlSanitizeEx.Scrubber.CSS.scrub/1 matches the property name with an unbounded greedy [-\w]+ followed by a mandatory :, so a long run of word characters not followed by a colon makes the engine give back one character at a time and retry the colon at every start offset. The work is quadratic in the length of the run, and no length cap is applied to the CSS handed to the scrubber. An 80 KB <style> body costs roughly 2.4 seconds of scheduler time, so a few concurrent requests saturate the BEAM scheduler pool and make the application unresponsive.

The impact is CPU exhaustion only. Nothing is read, modified or disclosed.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which reach the CSS scrubber, or define a custom scrubber that allows neither <style> elements nor style attributes.

Capping the size of user-supplied HTML before it reaches the sanitizer bounds the cost, though the quadratic growth means the cap has to be small to be effective.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, route input into the CSS scrubber, by way of <style> element bodies and style attributes. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to inject CSS at-rules, including an import of a remote stylesheet, into a page served to other users. HtmlSanitizeEx.Scrubber.CSS.scrub/1 applies its property and value allowlist through a Regex.replace over substrings matching a property: value declaration pattern, so input that does not match that pattern is never inspected and is copied to the output unchanged. @import url(//attacker.example/style.css); survives, while the same URL inside a background: url(...) declaration is removed.

Element boundaries are resolved before the scrubber runs, so injected content does not escape the <style> element and no script executes.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.4.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow <style> elements, or define a custom scrubber that omits it.

A Content-Security-Policy style-src directive that permits no external stylesheet origins stops an injected @import from loading, though injected inline rules still apply.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, permit <style> elements, and the sanitized output must be rendered to other users. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to force visitors of a page to navigate to a site of the attacker's choosing via a <meta http-equiv="refresh"> element in sanitized HTML. HtmlSanitizeEx.html5/1 keeps attacker-supplied <meta> elements in its output. A meta element acts on the whole document rather than on the fragment it was embedded in, so it can also declare document-wide directives such as Content-Security-Policy.

This is not cross-site scripting. Browsers do not navigate a meta refresh to a javascript: URL, so the uppercase JAVASCRIPT: filter bypass yields no script execution and none was demonstrated.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow meta, or define a custom scrubber that omits it.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the meta element, and the sanitized output must be rendered to other users.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to retarget a form already on the rendering page and receive whatever the victim submits, including credentials, via the form and formaction attributes on an <input> element in sanitized HTML. HTML's form attribute associates an input with any form on the page by its id even when the input sits outside that form, and formaction on a submit control overrides the owning form's action. Neither attribute receives a scheme check, so an absolute cross-origin URL survives sanitizing.

No script executes. The scrubber allows neither form nor button, so the attacker cannot introduce a form of their own and the rendering page must already contain a form carrying an id.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow input, or define a custom scrubber that omits it.

Omitting the id attribute from the page's own forms, or giving them values an attacker cannot predict, removes the anchor the injected form attribute needs.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the input element, and the sanitized output must be rendered to other users.

The rendering page must also contain a form with an id, since that id is what the injected form attribute binds to.

Summary

Inclusion of Functionality from Untrusted Control Sphere vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to load a document of their choosing into a trusted page via the data attribute of an <object> element in sanitized HTML. object is the one URI-bearing element in lib/html_sanitize_ex/scrubber/html5.ex never registered through allow_tag_with_uri_attributes/3, and its only guard is a prefix match on lowercase "javascript:", so mixed-case variants, data: URIs, protocol-relative URLs and same-origin paths all survive.

This is not unconditional cross-site scripting. A javascript: URL does not execute through <object data> in current browsers, data: documents load in an opaque origin, and host-origin script execution additionally requires the application to serve attacker-controlled content from a same-origin path.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow object, or define a custom scrubber that omits it.

A Content-Security-Policy of object-src 'none' blocks an injected <object> from loading, and hosting user uploads on a separate origin removes the escalation path.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the object element, and the sanitized output must be rendered to other users.

Script execution in the host origin additionally requires the application to serve attacker-controlled HTML from a same-origin path, such as an uploads directory served as text/html.

Summary

Inefficient Algorithmic Complexity vulnerability in the traversal engine in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU and memory via a flat run of sibling elements in sanitized HTML. The list clause of HtmlSanitizeEx.Traverser.traverse/2 recurses on the tail of a sibling list and then evaluates List.flatten([head] ++ tail) over the already flattened result, so every one of n siblings copies and re-walks the entire remaining tail. The flattening is only needed for the rare case where scrub returns several replacement nodes for one node, but the cost is paid across the whole tail at every step, making traversal quadratic in sibling count.

The traverser sits on every public entry point, so no particular scrubber or configuration is required and the payload needs only allowed tags. A 160 KB body of 20,000 sibling elements occupies a scheduler for roughly 1.7 seconds, and the cost grows faster than the body does.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Cap the size of user-supplied HTML, and in particular the node count, before it reaches the sanitizer. The quadratic growth means the cap has to be small to be effective.

Summary

Inefficient Regular Expression Complexity vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU via a long CSS declaration in sanitized HTML. The declaration regex in HtmlSanitizeEx.Scrubber.CSS.scrub/1 matches the property name with an unbounded greedy [-\w]+ followed by a mandatory :, so a long run of word characters not followed by a colon makes the engine give back one character at a time and retry the colon at every start offset. The work is quadratic in the length of the run, and no length cap is applied to the CSS handed to the scrubber. An 80 KB <style> body costs roughly 2.4 seconds of scheduler time, so a few concurrent requests saturate the BEAM scheduler pool and make the application unresponsive.

The impact is CPU exhaustion only. Nothing is read, modified or disclosed.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which reach the CSS scrubber, or define a custom scrubber that allows neither <style> elements nor style attributes.

Capping the size of user-supplied HTML before it reaches the sanitizer bounds the cost, though the quadratic growth means the cap has to be small to be effective.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, route input into the CSS scrubber, by way of <style> element bodies and style attributes. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to inject CSS at-rules, including an import of a remote stylesheet, into a page served to other users. HtmlSanitizeEx.Scrubber.CSS.scrub/1 applies its property and value allowlist through a Regex.replace over substrings matching a property: value declaration pattern, so input that does not match that pattern is never inspected and is copied to the output unchanged. @import url(//attacker.example/style.css); survives, while the same URL inside a background: url(...) declaration is removed.

Element boundaries are resolved before the scrubber runs, so injected content does not escape the <style> element and no script executes.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.4.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow <style> elements, or define a custom scrubber that omits it.

A Content-Security-Policy style-src directive that permits no external stylesheet origins stops an injected @import from loading, though injected inline rules still apply.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, permit <style> elements, and the sanitized output must be rendered to other users. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to force visitors of a page to navigate to a site of the attacker's choosing via a <meta http-equiv="refresh"> element in sanitized HTML. HtmlSanitizeEx.html5/1 keeps attacker-supplied <meta> elements in its output. A meta element acts on the whole document rather than on the fragment it was embedded in, so it can also declare document-wide directives such as Content-Security-Policy.

This is not cross-site scripting. Browsers do not navigate a meta refresh to a javascript: URL, so the uppercase JAVASCRIPT: filter bypass yields no script execution and none was demonstrated.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow meta, or define a custom scrubber that omits it.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the meta element, and the sanitized output must be rendered to other users.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to retarget a form already on the rendering page and receive whatever the victim submits, including credentials, via the form and formaction attributes on an <input> element in sanitized HTML. HTML's form attribute associates an input with any form on the page by its id even when the input sits outside that form, and formaction on a submit control overrides the owning form's action. Neither attribute receives a scheme check, so an absolute cross-origin URL survives sanitizing.

No script executes. The scrubber allows neither form nor button, so the attacker cannot introduce a form of their own and the rendering page must already contain a form carrying an id.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow input, or define a custom scrubber that omits it.

Omitting the id attribute from the page's own forms, or giving them values an attacker cannot predict, removes the anchor the injected form attribute needs.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the input element, and the sanitized output must be rendered to other users.

The rendering page must also contain a form with an id, since that id is what the injected form attribute binds to.

Summary

Inclusion of Functionality from Untrusted Control Sphere vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to load a document of their choosing into a trusted page via the data attribute of an <object> element in sanitized HTML. object is the one URI-bearing element in lib/html_sanitize_ex/scrubber/html5.ex never registered through allow_tag_with_uri_attributes/3, and its only guard is a prefix match on lowercase "javascript:", so mixed-case variants, data: URIs, protocol-relative URLs and same-origin paths all survive.

This is not unconditional cross-site scripting. A javascript: URL does not execute through <object data> in current browsers, data: documents load in an opaque origin, and host-origin script execution additionally requires the application to serve attacker-controlled content from a same-origin path.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow object, or define a custom scrubber that omits it.

A Content-Security-Policy of object-src 'none' blocks an injected <object> from loading, and hosting user uploads on a separate origin removes the escalation path.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the object element, and the sanitized output must be rendered to other users.

Script execution in the host origin additionally requires the application to serve attacker-controlled HTML from a same-origin path, such as an uploads directory served as text/html.

Summary

Inefficient Algorithmic Complexity vulnerability in the traversal engine in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU and memory via a flat run of sibling elements in sanitized HTML. The list clause of HtmlSanitizeEx.Traverser.traverse/2 recurses on the tail of a sibling list and then evaluates List.flatten([head] ++ tail) over the already flattened result, so every one of n siblings copies and re-walks the entire remaining tail. The flattening is only needed for the rare case where scrub returns several replacement nodes for one node, but the cost is paid across the whole tail at every step, making traversal quadratic in sibling count.

The traverser sits on every public entry point, so no particular scrubber or configuration is required and the payload needs only allowed tags. A 160 KB body of 20,000 sibling elements occupies a scheduler for roughly 1.7 seconds, and the cost grows faster than the body does.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Cap the size of user-supplied HTML, and in particular the node count, before it reaches the sanitizer. The quadratic growth means the cap has to be small to be effective.

Summary

Inefficient Regular Expression Complexity vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU via a long CSS declaration in sanitized HTML. The declaration regex in HtmlSanitizeEx.Scrubber.CSS.scrub/1 matches the property name with an unbounded greedy [-\w]+ followed by a mandatory :, so a long run of word characters not followed by a colon makes the engine give back one character at a time and retry the colon at every start offset. The work is quadratic in the length of the run, and no length cap is applied to the CSS handed to the scrubber. An 80 KB <style> body costs roughly 2.4 seconds of scheduler time, so a few concurrent requests saturate the BEAM scheduler pool and make the application unresponsive.

The impact is CPU exhaustion only. Nothing is read, modified or disclosed.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which reach the CSS scrubber, or define a custom scrubber that allows neither <style> elements nor style attributes.

Capping the size of user-supplied HTML before it reaches the sanitizer bounds the cost, though the quadratic growth means the cap has to be small to be effective.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, route input into the CSS scrubber, by way of <style> element bodies and style attributes. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to inject CSS at-rules, including an import of a remote stylesheet, into a page served to other users. HtmlSanitizeEx.Scrubber.CSS.scrub/1 applies its property and value allowlist through a Regex.replace over substrings matching a property: value declaration pattern, so input that does not match that pattern is never inspected and is copied to the output unchanged. @import url(//attacker.example/style.css); survives, while the same URL inside a background: url(...) declaration is removed.

Element boundaries are resolved before the scrubber runs, so injected content does not escape the <style> element and no script executes.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.4.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow <style> elements, or define a custom scrubber that omits it.

A Content-Security-Policy style-src directive that permits no external stylesheet origins stops an injected @import from loading, though injected inline rules still apply.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, permit <style> elements, and the sanitized output must be rendered to other users. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to force visitors of a page to navigate to a site of the attacker's choosing via a <meta http-equiv="refresh"> element in sanitized HTML. HtmlSanitizeEx.html5/1 keeps attacker-supplied <meta> elements in its output. A meta element acts on the whole document rather than on the fragment it was embedded in, so it can also declare document-wide directives such as Content-Security-Policy.

This is not cross-site scripting. Browsers do not navigate a meta refresh to a javascript: URL, so the uppercase JAVASCRIPT: filter bypass yields no script execution and none was demonstrated.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow meta, or define a custom scrubber that omits it.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the meta element, and the sanitized output must be rendered to other users.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to retarget a form already on the rendering page and receive whatever the victim submits, including credentials, via the form and formaction attributes on an <input> element in sanitized HTML. HTML's form attribute associates an input with any form on the page by its id even when the input sits outside that form, and formaction on a submit control overrides the owning form's action. Neither attribute receives a scheme check, so an absolute cross-origin URL survives sanitizing.

No script executes. The scrubber allows neither form nor button, so the attacker cannot introduce a form of their own and the rendering page must already contain a form carrying an id.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow input, or define a custom scrubber that omits it.

Omitting the id attribute from the page's own forms, or giving them values an attacker cannot predict, removes the anchor the injected form attribute needs.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the input element, and the sanitized output must be rendered to other users.

The rendering page must also contain a form with an id, since that id is what the injected form attribute binds to.

Summary

Inclusion of Functionality from Untrusted Control Sphere vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to load a document of their choosing into a trusted page via the data attribute of an <object> element in sanitized HTML. object is the one URI-bearing element in lib/html_sanitize_ex/scrubber/html5.ex never registered through allow_tag_with_uri_attributes/3, and its only guard is a prefix match on lowercase "javascript:", so mixed-case variants, data: URIs, protocol-relative URLs and same-origin paths all survive.

This is not unconditional cross-site scripting. A javascript: URL does not execute through <object data> in current browsers, data: documents load in an opaque origin, and host-origin script execution additionally requires the application to serve attacker-controlled content from a same-origin path.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow object, or define a custom scrubber that omits it.

A Content-Security-Policy of object-src 'none' blocks an injected <object> from loading, and hosting user uploads on a separate origin removes the escalation path.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the object element, and the sanitized output must be rendered to other users.

Script execution in the host origin additionally requires the application to serve attacker-controlled HTML from a same-origin path, such as an uploads directory served as text/html.

Summary

Inefficient Algorithmic Complexity vulnerability in the traversal engine in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU and memory via a flat run of sibling elements in sanitized HTML. The list clause of HtmlSanitizeEx.Traverser.traverse/2 recurses on the tail of a sibling list and then evaluates List.flatten([head] ++ tail) over the already flattened result, so every one of n siblings copies and re-walks the entire remaining tail. The flattening is only needed for the rare case where scrub returns several replacement nodes for one node, but the cost is paid across the whole tail at every step, making traversal quadratic in sibling count.

The traverser sits on every public entry point, so no particular scrubber or configuration is required and the payload needs only allowed tags. A 160 KB body of 20,000 sibling elements occupies a scheduler for roughly 1.7 seconds, and the cost grows faster than the body does.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Cap the size of user-supplied HTML, and in particular the node count, before it reaches the sanitizer. The quadratic growth means the cap has to be small to be effective.

Summary

Inefficient Regular Expression Complexity vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU via a long CSS declaration in sanitized HTML. The declaration regex in HtmlSanitizeEx.Scrubber.CSS.scrub/1 matches the property name with an unbounded greedy [-\w]+ followed by a mandatory :, so a long run of word characters not followed by a colon makes the engine give back one character at a time and retry the colon at every start offset. The work is quadratic in the length of the run, and no length cap is applied to the CSS handed to the scrubber. An 80 KB <style> body costs roughly 2.4 seconds of scheduler time, so a few concurrent requests saturate the BEAM scheduler pool and make the application unresponsive.

The impact is CPU exhaustion only. Nothing is read, modified or disclosed.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which reach the CSS scrubber, or define a custom scrubber that allows neither <style> elements nor style attributes.

Capping the size of user-supplied HTML before it reaches the sanitizer bounds the cost, though the quadratic growth means the cap has to be small to be effective.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, route input into the CSS scrubber, by way of <style> element bodies and style attributes. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to inject CSS at-rules, including an import of a remote stylesheet, into a page served to other users. HtmlSanitizeEx.Scrubber.CSS.scrub/1 applies its property and value allowlist through a Regex.replace over substrings matching a property: value declaration pattern, so input that does not match that pattern is never inspected and is copied to the output unchanged. @import url(//attacker.example/style.css); survives, while the same URL inside a background: url(...) declaration is removed.

Element boundaries are resolved before the scrubber runs, so injected content does not escape the <style> element and no script executes.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.4.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow <style> elements, or define a custom scrubber that omits it.

A Content-Security-Policy style-src directive that permits no external stylesheet origins stops an injected @import from loading, though injected inline rules still apply.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, permit <style> elements, and the sanitized output must be rendered to other users. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to force visitors of a page to navigate to a site of the attacker's choosing via a <meta http-equiv="refresh"> element in sanitized HTML. HtmlSanitizeEx.html5/1 keeps attacker-supplied <meta> elements in its output. A meta element acts on the whole document rather than on the fragment it was embedded in, so it can also declare document-wide directives such as Content-Security-Policy.

This is not cross-site scripting. Browsers do not navigate a meta refresh to a javascript: URL, so the uppercase JAVASCRIPT: filter bypass yields no script execution and none was demonstrated.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow meta, or define a custom scrubber that omits it.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the meta element, and the sanitized output must be rendered to other users.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to retarget a form already on the rendering page and receive whatever the victim submits, including credentials, via the form and formaction attributes on an <input> element in sanitized HTML. HTML's form attribute associates an input with any form on the page by its id even when the input sits outside that form, and formaction on a submit control overrides the owning form's action. Neither attribute receives a scheme check, so an absolute cross-origin URL survives sanitizing.

No script executes. The scrubber allows neither form nor button, so the attacker cannot introduce a form of their own and the rendering page must already contain a form carrying an id.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow input, or define a custom scrubber that omits it.

Omitting the id attribute from the page's own forms, or giving them values an attacker cannot predict, removes the anchor the injected form attribute needs.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the input element, and the sanitized output must be rendered to other users.

The rendering page must also contain a form with an id, since that id is what the injected form attribute binds to.

Summary

Inclusion of Functionality from Untrusted Control Sphere vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to load a document of their choosing into a trusted page via the data attribute of an <object> element in sanitized HTML. object is the one URI-bearing element in lib/html_sanitize_ex/scrubber/html5.ex never registered through allow_tag_with_uri_attributes/3, and its only guard is a prefix match on lowercase "javascript:", so mixed-case variants, data: URIs, protocol-relative URLs and same-origin paths all survive.

This is not unconditional cross-site scripting. A javascript: URL does not execute through <object data> in current browsers, data: documents load in an opaque origin, and host-origin script execution additionally requires the application to serve attacker-controlled content from a same-origin path.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow object, or define a custom scrubber that omits it.

A Content-Security-Policy of object-src 'none' blocks an injected <object> from loading, and hosting user uploads on a separate origin removes the escalation path.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the object element, and the sanitized output must be rendered to other users.

Script execution in the host origin additionally requires the application to serve attacker-controlled HTML from a same-origin path, such as an uploads directory served as text/html.

Summary

Inefficient Algorithmic Complexity vulnerability in the traversal engine in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU and memory via a flat run of sibling elements in sanitized HTML. The list clause of HtmlSanitizeEx.Traverser.traverse/2 recurses on the tail of a sibling list and then evaluates List.flatten([head] ++ tail) over the already flattened result, so every one of n siblings copies and re-walks the entire remaining tail. The flattening is only needed for the rare case where scrub returns several replacement nodes for one node, but the cost is paid across the whole tail at every step, making traversal quadratic in sibling count.

The traverser sits on every public entry point, so no particular scrubber or configuration is required and the payload needs only allowed tags. A 160 KB body of 20,000 sibling elements occupies a scheduler for roughly 1.7 seconds, and the cost grows faster than the body does.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Cap the size of user-supplied HTML, and in particular the node count, before it reaches the sanitizer. The quadratic growth means the cap has to be small to be effective.

Summary

Inefficient Regular Expression Complexity vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU via a long CSS declaration in sanitized HTML. The declaration regex in HtmlSanitizeEx.Scrubber.CSS.scrub/1 matches the property name with an unbounded greedy [-\w]+ followed by a mandatory :, so a long run of word characters not followed by a colon makes the engine give back one character at a time and retry the colon at every start offset. The work is quadratic in the length of the run, and no length cap is applied to the CSS handed to the scrubber. An 80 KB <style> body costs roughly 2.4 seconds of scheduler time, so a few concurrent requests saturate the BEAM scheduler pool and make the application unresponsive.

The impact is CPU exhaustion only. Nothing is read, modified or disclosed.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which reach the CSS scrubber, or define a custom scrubber that allows neither <style> elements nor style attributes.

Capping the size of user-supplied HTML before it reaches the sanitizer bounds the cost, though the quadratic growth means the cap has to be small to be effective.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, route input into the CSS scrubber, by way of <style> element bodies and style attributes. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to inject CSS at-rules, including an import of a remote stylesheet, into a page served to other users. HtmlSanitizeEx.Scrubber.CSS.scrub/1 applies its property and value allowlist through a Regex.replace over substrings matching a property: value declaration pattern, so input that does not match that pattern is never inspected and is copied to the output unchanged. @import url(//attacker.example/style.css); survives, while the same URL inside a background: url(...) declaration is removed.

Element boundaries are resolved before the scrubber runs, so injected content does not escape the <style> element and no script executes.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.4.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow <style> elements, or define a custom scrubber that omits it.

A Content-Security-Policy style-src directive that permits no external stylesheet origins stops an injected @import from loading, though injected inline rules still apply.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, permit <style> elements, and the sanitized output must be rendered to other users. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to force visitors of a page to navigate to a site of the attacker's choosing via a <meta http-equiv="refresh"> element in sanitized HTML. HtmlSanitizeEx.html5/1 keeps attacker-supplied <meta> elements in its output. A meta element acts on the whole document rather than on the fragment it was embedded in, so it can also declare document-wide directives such as Content-Security-Policy.

This is not cross-site scripting. Browsers do not navigate a meta refresh to a javascript: URL, so the uppercase JAVASCRIPT: filter bypass yields no script execution and none was demonstrated.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow meta, or define a custom scrubber that omits it.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the meta element, and the sanitized output must be rendered to other users.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to retarget a form already on the rendering page and receive whatever the victim submits, including credentials, via the form and formaction attributes on an <input> element in sanitized HTML. HTML's form attribute associates an input with any form on the page by its id even when the input sits outside that form, and formaction on a submit control overrides the owning form's action. Neither attribute receives a scheme check, so an absolute cross-origin URL survives sanitizing.

No script executes. The scrubber allows neither form nor button, so the attacker cannot introduce a form of their own and the rendering page must already contain a form carrying an id.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow input, or define a custom scrubber that omits it.

Omitting the id attribute from the page's own forms, or giving them values an attacker cannot predict, removes the anchor the injected form attribute needs.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the input element, and the sanitized output must be rendered to other users.

The rendering page must also contain a form with an id, since that id is what the injected form attribute binds to.

Summary

Inclusion of Functionality from Untrusted Control Sphere vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to load a document of their choosing into a trusted page via the data attribute of an <object> element in sanitized HTML. object is the one URI-bearing element in lib/html_sanitize_ex/scrubber/html5.ex never registered through allow_tag_with_uri_attributes/3, and its only guard is a prefix match on lowercase "javascript:", so mixed-case variants, data: URIs, protocol-relative URLs and same-origin paths all survive.

This is not unconditional cross-site scripting. A javascript: URL does not execute through <object data> in current browsers, data: documents load in an opaque origin, and host-origin script execution additionally requires the application to serve attacker-controlled content from a same-origin path.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow object, or define a custom scrubber that omits it.

A Content-Security-Policy of object-src 'none' blocks an injected <object> from loading, and hosting user uploads on a separate origin removes the escalation path.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the object element, and the sanitized output must be rendered to other users.

Script execution in the host origin additionally requires the application to serve attacker-controlled HTML from a same-origin path, such as an uploads directory served as text/html.

Summary

Inefficient Algorithmic Complexity vulnerability in the traversal engine in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU and memory via a flat run of sibling elements in sanitized HTML. The list clause of HtmlSanitizeEx.Traverser.traverse/2 recurses on the tail of a sibling list and then evaluates List.flatten([head] ++ tail) over the already flattened result, so every one of n siblings copies and re-walks the entire remaining tail. The flattening is only needed for the rare case where scrub returns several replacement nodes for one node, but the cost is paid across the whole tail at every step, making traversal quadratic in sibling count.

The traverser sits on every public entry point, so no particular scrubber or configuration is required and the payload needs only allowed tags. A 160 KB body of 20,000 sibling elements occupies a scheduler for roughly 1.7 seconds, and the cost grows faster than the body does.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Cap the size of user-supplied HTML, and in particular the node count, before it reaches the sanitizer. The quadratic growth means the cap has to be small to be effective.

Summary

Inefficient Regular Expression Complexity vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU via a long CSS declaration in sanitized HTML. The declaration regex in HtmlSanitizeEx.Scrubber.CSS.scrub/1 matches the property name with an unbounded greedy [-\w]+ followed by a mandatory :, so a long run of word characters not followed by a colon makes the engine give back one character at a time and retry the colon at every start offset. The work is quadratic in the length of the run, and no length cap is applied to the CSS handed to the scrubber. An 80 KB <style> body costs roughly 2.4 seconds of scheduler time, so a few concurrent requests saturate the BEAM scheduler pool and make the application unresponsive.

The impact is CPU exhaustion only. Nothing is read, modified or disclosed.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which reach the CSS scrubber, or define a custom scrubber that allows neither <style> elements nor style attributes.

Capping the size of user-supplied HTML before it reaches the sanitizer bounds the cost, though the quadratic growth means the cap has to be small to be effective.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, route input into the CSS scrubber, by way of <style> element bodies and style attributes. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to inject CSS at-rules, including an import of a remote stylesheet, into a page served to other users. HtmlSanitizeEx.Scrubber.CSS.scrub/1 applies its property and value allowlist through a Regex.replace over substrings matching a property: value declaration pattern, so input that does not match that pattern is never inspected and is copied to the output unchanged. @import url(//attacker.example/style.css); survives, while the same URL inside a background: url(...) declaration is removed.

Element boundaries are resolved before the scrubber runs, so injected content does not escape the <style> element and no script executes.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.4.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow <style> elements, or define a custom scrubber that omits it.

A Content-Security-Policy style-src directive that permits no external stylesheet origins stops an injected @import from loading, though injected inline rules still apply.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, permit <style> elements, and the sanitized output must be rendered to other users. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to force visitors of a page to navigate to a site of the attacker's choosing via a <meta http-equiv="refresh"> element in sanitized HTML. HtmlSanitizeEx.html5/1 keeps attacker-supplied <meta> elements in its output. A meta element acts on the whole document rather than on the fragment it was embedded in, so it can also declare document-wide directives such as Content-Security-Policy.

This is not cross-site scripting. Browsers do not navigate a meta refresh to a javascript: URL, so the uppercase JAVASCRIPT: filter bypass yields no script execution and none was demonstrated.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow meta, or define a custom scrubber that omits it.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the meta element, and the sanitized output must be rendered to other users.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to retarget a form already on the rendering page and receive whatever the victim submits, including credentials, via the form and formaction attributes on an <input> element in sanitized HTML. HTML's form attribute associates an input with any form on the page by its id even when the input sits outside that form, and formaction on a submit control overrides the owning form's action. Neither attribute receives a scheme check, so an absolute cross-origin URL survives sanitizing.

No script executes. The scrubber allows neither form nor button, so the attacker cannot introduce a form of their own and the rendering page must already contain a form carrying an id.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow input, or define a custom scrubber that omits it.

Omitting the id attribute from the page's own forms, or giving them values an attacker cannot predict, removes the anchor the injected form attribute needs.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the input element, and the sanitized output must be rendered to other users.

The rendering page must also contain a form with an id, since that id is what the injected form attribute binds to.

Summary

Inclusion of Functionality from Untrusted Control Sphere vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to load a document of their choosing into a trusted page via the data attribute of an <object> element in sanitized HTML. object is the one URI-bearing element in lib/html_sanitize_ex/scrubber/html5.ex never registered through allow_tag_with_uri_attributes/3, and its only guard is a prefix match on lowercase "javascript:", so mixed-case variants, data: URIs, protocol-relative URLs and same-origin paths all survive.

This is not unconditional cross-site scripting. A javascript: URL does not execute through <object data> in current browsers, data: documents load in an opaque origin, and host-origin script execution additionally requires the application to serve attacker-controlled content from a same-origin path.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow object, or define a custom scrubber that omits it.

A Content-Security-Policy of object-src 'none' blocks an injected <object> from loading, and hosting user uploads on a separate origin removes the escalation path.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the object element, and the sanitized output must be rendered to other users.

Script execution in the host origin additionally requires the application to serve attacker-controlled HTML from a same-origin path, such as an uploads directory served as text/html.

Summary

Inefficient Algorithmic Complexity vulnerability in the traversal engine in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU and memory via a flat run of sibling elements in sanitized HTML. The list clause of HtmlSanitizeEx.Traverser.traverse/2 recurses on the tail of a sibling list and then evaluates List.flatten([head] ++ tail) over the already flattened result, so every one of n siblings copies and re-walks the entire remaining tail. The flattening is only needed for the rare case where scrub returns several replacement nodes for one node, but the cost is paid across the whole tail at every step, making traversal quadratic in sibling count.

The traverser sits on every public entry point, so no particular scrubber or configuration is required and the payload needs only allowed tags. A 160 KB body of 20,000 sibling elements occupies a scheduler for roughly 1.7 seconds, and the cost grows faster than the body does.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Cap the size of user-supplied HTML, and in particular the node count, before it reaches the sanitizer. The quadratic growth means the cap has to be small to be effective.

Summary

Inefficient Regular Expression Complexity vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU via a long CSS declaration in sanitized HTML. The declaration regex in HtmlSanitizeEx.Scrubber.CSS.scrub/1 matches the property name with an unbounded greedy [-\w]+ followed by a mandatory :, so a long run of word characters not followed by a colon makes the engine give back one character at a time and retry the colon at every start offset. The work is quadratic in the length of the run, and no length cap is applied to the CSS handed to the scrubber. An 80 KB <style> body costs roughly 2.4 seconds of scheduler time, so a few concurrent requests saturate the BEAM scheduler pool and make the application unresponsive.

The impact is CPU exhaustion only. Nothing is read, modified or disclosed.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which reach the CSS scrubber, or define a custom scrubber that allows neither <style> elements nor style attributes.

Capping the size of user-supplied HTML before it reaches the sanitizer bounds the cost, though the quadratic growth means the cap has to be small to be effective.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, route input into the CSS scrubber, by way of <style> element bodies and style attributes. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to inject CSS at-rules, including an import of a remote stylesheet, into a page served to other users. HtmlSanitizeEx.Scrubber.CSS.scrub/1 applies its property and value allowlist through a Regex.replace over substrings matching a property: value declaration pattern, so input that does not match that pattern is never inspected and is copied to the output unchanged. @import url(//attacker.example/style.css); survives, while the same URL inside a background: url(...) declaration is removed.

Element boundaries are resolved before the scrubber runs, so injected content does not escape the <style> element and no script executes.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.4.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow <style> elements, or define a custom scrubber that omits it.

A Content-Security-Policy style-src directive that permits no external stylesheet origins stops an injected @import from loading, though injected inline rules still apply.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, permit <style> elements, and the sanitized output must be rendered to other users. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to force visitors of a page to navigate to a site of the attacker's choosing via a <meta http-equiv="refresh"> element in sanitized HTML. HtmlSanitizeEx.html5/1 keeps attacker-supplied <meta> elements in its output. A meta element acts on the whole document rather than on the fragment it was embedded in, so it can also declare document-wide directives such as Content-Security-Policy.

This is not cross-site scripting. Browsers do not navigate a meta refresh to a javascript: URL, so the uppercase JAVASCRIPT: filter bypass yields no script execution and none was demonstrated.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow meta, or define a custom scrubber that omits it.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the meta element, and the sanitized output must be rendered to other users.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to retarget a form already on the rendering page and receive whatever the victim submits, including credentials, via the form and formaction attributes on an <input> element in sanitized HTML. HTML's form attribute associates an input with any form on the page by its id even when the input sits outside that form, and formaction on a submit control overrides the owning form's action. Neither attribute receives a scheme check, so an absolute cross-origin URL survives sanitizing.

No script executes. The scrubber allows neither form nor button, so the attacker cannot introduce a form of their own and the rendering page must already contain a form carrying an id.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow input, or define a custom scrubber that omits it.

Omitting the id attribute from the page's own forms, or giving them values an attacker cannot predict, removes the anchor the injected form attribute needs.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the input element, and the sanitized output must be rendered to other users.

The rendering page must also contain a form with an id, since that id is what the injected form attribute binds to.

Summary

Inclusion of Functionality from Untrusted Control Sphere vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to load a document of their choosing into a trusted page via the data attribute of an <object> element in sanitized HTML. object is the one URI-bearing element in lib/html_sanitize_ex/scrubber/html5.ex never registered through allow_tag_with_uri_attributes/3, and its only guard is a prefix match on lowercase "javascript:", so mixed-case variants, data: URIs, protocol-relative URLs and same-origin paths all survive.

This is not unconditional cross-site scripting. A javascript: URL does not execute through <object data> in current browsers, data: documents load in an opaque origin, and host-origin script execution additionally requires the application to serve attacker-controlled content from a same-origin path.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow object, or define a custom scrubber that omits it.

A Content-Security-Policy of object-src 'none' blocks an injected <object> from loading, and hosting user uploads on a separate origin removes the escalation path.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the object element, and the sanitized output must be rendered to other users.

Script execution in the host origin additionally requires the application to serve attacker-controlled HTML from a same-origin path, such as an uploads directory served as text/html.

Summary

Inefficient Algorithmic Complexity vulnerability in the traversal engine in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU and memory via a flat run of sibling elements in sanitized HTML. The list clause of HtmlSanitizeEx.Traverser.traverse/2 recurses on the tail of a sibling list and then evaluates List.flatten([head] ++ tail) over the already flattened result, so every one of n siblings copies and re-walks the entire remaining tail. The flattening is only needed for the rare case where scrub returns several replacement nodes for one node, but the cost is paid across the whole tail at every step, making traversal quadratic in sibling count.

The traverser sits on every public entry point, so no particular scrubber or configuration is required and the payload needs only allowed tags. A 160 KB body of 20,000 sibling elements occupies a scheduler for roughly 1.7 seconds, and the cost grows faster than the body does.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Cap the size of user-supplied HTML, and in particular the node count, before it reaches the sanitizer. The quadratic growth means the cap has to be small to be effective.

Summary

Inefficient Regular Expression Complexity vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU via a long CSS declaration in sanitized HTML. The declaration regex in HtmlSanitizeEx.Scrubber.CSS.scrub/1 matches the property name with an unbounded greedy [-\w]+ followed by a mandatory :, so a long run of word characters not followed by a colon makes the engine give back one character at a time and retry the colon at every start offset. The work is quadratic in the length of the run, and no length cap is applied to the CSS handed to the scrubber. An 80 KB <style> body costs roughly 2.4 seconds of scheduler time, so a few concurrent requests saturate the BEAM scheduler pool and make the application unresponsive.

The impact is CPU exhaustion only. Nothing is read, modified or disclosed.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which reach the CSS scrubber, or define a custom scrubber that allows neither <style> elements nor style attributes.

Capping the size of user-supplied HTML before it reaches the sanitizer bounds the cost, though the quadratic growth means the cap has to be small to be effective.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, route input into the CSS scrubber, by way of <style> element bodies and style attributes. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to inject CSS at-rules, including an import of a remote stylesheet, into a page served to other users. HtmlSanitizeEx.Scrubber.CSS.scrub/1 applies its property and value allowlist through a Regex.replace over substrings matching a property: value declaration pattern, so input that does not match that pattern is never inspected and is copied to the output unchanged. @import url(//attacker.example/style.css); survives, while the same URL inside a background: url(...) declaration is removed.

Element boundaries are resolved before the scrubber runs, so injected content does not escape the <style> element and no script executes.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.4.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow <style> elements, or define a custom scrubber that omits it.

A Content-Security-Policy style-src directive that permits no external stylesheet origins stops an injected @import from loading, though injected inline rules still apply.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, permit <style> elements, and the sanitized output must be rendered to other users. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to force visitors of a page to navigate to a site of the attacker's choosing via a <meta http-equiv="refresh"> element in sanitized HTML. HtmlSanitizeEx.html5/1 keeps attacker-supplied <meta> elements in its output. A meta element acts on the whole document rather than on the fragment it was embedded in, so it can also declare document-wide directives such as Content-Security-Policy.

This is not cross-site scripting. Browsers do not navigate a meta refresh to a javascript: URL, so the uppercase JAVASCRIPT: filter bypass yields no script execution and none was demonstrated.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow meta, or define a custom scrubber that omits it.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the meta element, and the sanitized output must be rendered to other users.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to retarget a form already on the rendering page and receive whatever the victim submits, including credentials, via the form and formaction attributes on an <input> element in sanitized HTML. HTML's form attribute associates an input with any form on the page by its id even when the input sits outside that form, and formaction on a submit control overrides the owning form's action. Neither attribute receives a scheme check, so an absolute cross-origin URL survives sanitizing.

No script executes. The scrubber allows neither form nor button, so the attacker cannot introduce a form of their own and the rendering page must already contain a form carrying an id.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow input, or define a custom scrubber that omits it.

Omitting the id attribute from the page's own forms, or giving them values an attacker cannot predict, removes the anchor the injected form attribute needs.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the input element, and the sanitized output must be rendered to other users.

The rendering page must also contain a form with an id, since that id is what the injected form attribute binds to.

Summary

Inclusion of Functionality from Untrusted Control Sphere vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to load a document of their choosing into a trusted page via the data attribute of an <object> element in sanitized HTML. object is the one URI-bearing element in lib/html_sanitize_ex/scrubber/html5.ex never registered through allow_tag_with_uri_attributes/3, and its only guard is a prefix match on lowercase "javascript:", so mixed-case variants, data: URIs, protocol-relative URLs and same-origin paths all survive.

This is not unconditional cross-site scripting. A javascript: URL does not execute through <object data> in current browsers, data: documents load in an opaque origin, and host-origin script execution additionally requires the application to serve attacker-controlled content from a same-origin path.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow object, or define a custom scrubber that omits it.

A Content-Security-Policy of object-src 'none' blocks an injected <object> from loading, and hosting user uploads on a separate origin removes the escalation path.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the object element, and the sanitized output must be rendered to other users.

Script execution in the host origin additionally requires the application to serve attacker-controlled HTML from a same-origin path, such as an uploads directory served as text/html.

Summary

Inefficient Algorithmic Complexity vulnerability in the traversal engine in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU and memory via a flat run of sibling elements in sanitized HTML. The list clause of HtmlSanitizeEx.Traverser.traverse/2 recurses on the tail of a sibling list and then evaluates List.flatten([head] ++ tail) over the already flattened result, so every one of n siblings copies and re-walks the entire remaining tail. The flattening is only needed for the rare case where scrub returns several replacement nodes for one node, but the cost is paid across the whole tail at every step, making traversal quadratic in sibling count.

The traverser sits on every public entry point, so no particular scrubber or configuration is required and the payload needs only allowed tags. A 160 KB body of 20,000 sibling elements occupies a scheduler for roughly 1.7 seconds, and the cost grows faster than the body does.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Cap the size of user-supplied HTML, and in particular the node count, before it reaches the sanitizer. The quadratic growth means the cap has to be small to be effective.

Summary

Inefficient Regular Expression Complexity vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU via a long CSS declaration in sanitized HTML. The declaration regex in HtmlSanitizeEx.Scrubber.CSS.scrub/1 matches the property name with an unbounded greedy [-\w]+ followed by a mandatory :, so a long run of word characters not followed by a colon makes the engine give back one character at a time and retry the colon at every start offset. The work is quadratic in the length of the run, and no length cap is applied to the CSS handed to the scrubber. An 80 KB <style> body costs roughly 2.4 seconds of scheduler time, so a few concurrent requests saturate the BEAM scheduler pool and make the application unresponsive.

The impact is CPU exhaustion only. Nothing is read, modified or disclosed.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which reach the CSS scrubber, or define a custom scrubber that allows neither <style> elements nor style attributes.

Capping the size of user-supplied HTML before it reaches the sanitizer bounds the cost, though the quadratic growth means the cap has to be small to be effective.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, route input into the CSS scrubber, by way of <style> element bodies and style attributes. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to inject CSS at-rules, including an import of a remote stylesheet, into a page served to other users. HtmlSanitizeEx.Scrubber.CSS.scrub/1 applies its property and value allowlist through a Regex.replace over substrings matching a property: value declaration pattern, so input that does not match that pattern is never inspected and is copied to the output unchanged. @import url(//attacker.example/style.css); survives, while the same URL inside a background: url(...) declaration is removed.

Element boundaries are resolved before the scrubber runs, so injected content does not escape the <style> element and no script executes.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.4.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow <style> elements, or define a custom scrubber that omits it.

A Content-Security-Policy style-src directive that permits no external stylesheet origins stops an injected @import from loading, though injected inline rules still apply.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, permit <style> elements, and the sanitized output must be rendered to other users. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to force visitors of a page to navigate to a site of the attacker's choosing via a <meta http-equiv="refresh"> element in sanitized HTML. HtmlSanitizeEx.html5/1 keeps attacker-supplied <meta> elements in its output. A meta element acts on the whole document rather than on the fragment it was embedded in, so it can also declare document-wide directives such as Content-Security-Policy.

This is not cross-site scripting. Browsers do not navigate a meta refresh to a javascript: URL, so the uppercase JAVASCRIPT: filter bypass yields no script execution and none was demonstrated.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow meta, or define a custom scrubber that omits it.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the meta element, and the sanitized output must be rendered to other users.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to retarget a form already on the rendering page and receive whatever the victim submits, including credentials, via the form and formaction attributes on an <input> element in sanitized HTML. HTML's form attribute associates an input with any form on the page by its id even when the input sits outside that form, and formaction on a submit control overrides the owning form's action. Neither attribute receives a scheme check, so an absolute cross-origin URL survives sanitizing.

No script executes. The scrubber allows neither form nor button, so the attacker cannot introduce a form of their own and the rendering page must already contain a form carrying an id.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow input, or define a custom scrubber that omits it.

Omitting the id attribute from the page's own forms, or giving them values an attacker cannot predict, removes the anchor the injected form attribute needs.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the input element, and the sanitized output must be rendered to other users.

The rendering page must also contain a form with an id, since that id is what the injected form attribute binds to.

Summary

Inclusion of Functionality from Untrusted Control Sphere vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to load a document of their choosing into a trusted page via the data attribute of an <object> element in sanitized HTML. object is the one URI-bearing element in lib/html_sanitize_ex/scrubber/html5.ex never registered through allow_tag_with_uri_attributes/3, and its only guard is a prefix match on lowercase "javascript:", so mixed-case variants, data: URIs, protocol-relative URLs and same-origin paths all survive.

This is not unconditional cross-site scripting. A javascript: URL does not execute through <object data> in current browsers, data: documents load in an opaque origin, and host-origin script execution additionally requires the application to serve attacker-controlled content from a same-origin path.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow object, or define a custom scrubber that omits it.

A Content-Security-Policy of object-src 'none' blocks an injected <object> from loading, and hosting user uploads on a separate origin removes the escalation path.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the object element, and the sanitized output must be rendered to other users.

Script execution in the host origin additionally requires the application to serve attacker-controlled HTML from a same-origin path, such as an uploads directory served as text/html.

Summary

Inefficient Algorithmic Complexity vulnerability in the traversal engine in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU and memory via a flat run of sibling elements in sanitized HTML. The list clause of HtmlSanitizeEx.Traverser.traverse/2 recurses on the tail of a sibling list and then evaluates List.flatten([head] ++ tail) over the already flattened result, so every one of n siblings copies and re-walks the entire remaining tail. The flattening is only needed for the rare case where scrub returns several replacement nodes for one node, but the cost is paid across the whole tail at every step, making traversal quadratic in sibling count.

The traverser sits on every public entry point, so no particular scrubber or configuration is required and the payload needs only allowed tags. A 160 KB body of 20,000 sibling elements occupies a scheduler for roughly 1.7 seconds, and the cost grows faster than the body does.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Cap the size of user-supplied HTML, and in particular the node count, before it reaches the sanitizer. The quadratic growth means the cap has to be small to be effective.

Summary

Inefficient Regular Expression Complexity vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to exhaust server CPU via a long CSS declaration in sanitized HTML. The declaration regex in HtmlSanitizeEx.Scrubber.CSS.scrub/1 matches the property name with an unbounded greedy [-\w]+ followed by a mandatory :, so a long run of word characters not followed by a colon makes the engine give back one character at a time and retry the colon at every start offset. The work is quadratic in the length of the run, and no length cap is applied to the CSS handed to the scrubber. An 80 KB <style> body costs roughly 2.4 seconds of scheduler time, so a few concurrent requests saturate the BEAM scheduler pool and make the application unresponsive.

The impact is CPU exhaustion only. Nothing is read, modified or disclosed.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which reach the CSS scrubber, or define a custom scrubber that allows neither <style> elements nor style attributes.

Capping the size of user-supplied HTML before it reaches the sanitizer bounds the cost, though the quadratic growth means the cap has to be small to be effective.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, route input into the CSS scrubber, by way of <style> element bodies and style attributes. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in the CSS scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to inject CSS at-rules, including an import of a remote stylesheet, into a page served to other users. HtmlSanitizeEx.Scrubber.CSS.scrub/1 applies its property and value allowlist through a Regex.replace over substrings matching a property: value declaration pattern, so input that does not match that pattern is never inspected and is copied to the output unchanged. @import url(//attacker.example/style.css); survives, while the same URL inside a background: url(...) declaration is removed.

Element boundaries are resolved before the scrubber runs, so injected content does not escape the <style> element and no script executes.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.4.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow <style> elements, or define a custom scrubber that omits it.

A Content-Security-Policy style-src directive that permits no external stylesheet origins stops an injected @import from loading, though injected inline rules still apply.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, permit <style> elements, and the sanitized output must be rendered to other users. Applications calling HtmlSanitizeEx.Scrubber.CSS.scrub/1 directly are also affected.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows a remote attacker to force visitors of a page to navigate to a site of the attacker's choosing via a <meta http-equiv="refresh"> element in sanitized HTML. HtmlSanitizeEx.html5/1 keeps attacker-supplied <meta> elements in its output. A meta element acts on the whole document rather than on the fragment it was embedded in, so it can also declare document-wide directives such as Content-Security-Policy.

This is not cross-site scripting. Browsers do not navigate a meta refresh to a javascript: URL, so the uppercase JAVASCRIPT: filter bypass yields no script execution and none was demonstrated.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow meta, or define a custom scrubber that omits it.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the meta element, and the sanitized output must be rendered to other users.

Summary

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in the HTML5 scrubber in rrrene html_sanitize_ex allows an unauthenticated remote attacker to retarget a form already on the rendering page and receive whatever the victim submits, including credentials, via the form and formaction attributes on an <input> element in sanitized HTML. HTML's form attribute associates an input with any form on the page by its id even when the input sits outside that form, and formaction on a submit control overrides the owning form's action. Neither attribute receives a scheme check, so an absolute cross-origin URL survives sanitizing.

No script executes. The scrubber allows neither form nor button, so the attacker cannot introduce a form of their own and the rendering page must already contain a form carrying an id.

This issue affects html_sanitize_ex: from 0.3.1 before 1.4.5 and from 1.5.0-rc.0 before 1.5.3.

Workarounds

Sanitize with basic_html/1, markdown_html/1 or strip_tags/1, none of which allow input, or define a custom scrubber that omits it.

Omitting the id attribute from the page's own forms, or giving them values an attacker cannot predict, removes the anchor the injected form attribute needs.

Configurations

Only HtmlSanitizeEx.html5/1, and custom scrubbers declared with use HtmlSanitizeEx, extend: :html5, allow the input element, and the sanitized output must be rendered to other users.

The rendering page must also contain a form with an id, since that id is what the injected form attribute binds to.