Summary
Loofah::HTML5::Scrub.allowed_uri? does not correctly reject javascript: or vbscript: URIs when the scheme is split by a numeric character reference that has no trailing semicolon. A browser decodes such references and resolves the URL to an executable javascript: scheme, while allowed_uri? reports it safe.
This is a bypass of the fix for GHSA-46fp-8f5p-pf2m, which handled numeric character references with a trailing ; (	, , ) but did not cover the forms without semicolons.
Details
allowed_uri? decodes HTML entities with CGI.unescapeHTML, which decodes numeric character references only when they carry a trailing ;. A reference without a semicolon such as : (colon) or 	 (tab) is left literal, so the scheme-detection check finds no scheme, and the method falls through to its scheme-less path and returns true.
A browser, however, decodes numeric character references even without a trailing semicolon. An encoded colon such as : becomes the : scheme separator, so javascript:alert(1) resolves to javascript:alert(1). Encoded whitespace such as 	 (tab) is decoded and then stripped from the URL, rejoining the surrounding text, so java	script:alert(1) also resolves to javascript:alert(1). In both cases the URL executes while allowed_uri? approved it as safe.
Note that Loofah's default sanitize() path is not affected, because Nokogiri decodes or entity-escapes HTML entities during parsing before Loofah evaluates the URI protocol. This issue only affects callers of the public allowed_uri? string-level helper that pass it HTML-encoded strings.
Impact
Callers that validate a user-controlled URL with Loofah::HTML5::Scrub.allowed_uri? and then render the approved value into an href or other browser-interpreted URI attribute may be vulnerable to cross-site scripting (XSS). This includes applications that call allowed_uri? directly, as well as higher-level features built on top of it, such as Action Text 8.2's markdown link validation.
Mitigation
Upgrade to Loofah >= 2.25.2.
Credit
Responsibly reported by GitHub user @MoonFuji.
Summary
Loofah::HTML5::Scrub.allowed_uri?does not correctly rejectjavascript:orvbscript:URIs when the scheme is split by a numeric character reference that has no trailing semicolon. A browser decodes such references and resolves the URL to an executablejavascript:scheme, whileallowed_uri?reports it safe.This is a bypass of the fix for GHSA-46fp-8f5p-pf2m, which handled numeric character references with a trailing
;(	, , ) but did not cover the forms without semicolons.Details
allowed_uri?decodes HTML entities withCGI.unescapeHTML, which decodes numeric character references only when they carry a trailing;. A reference without a semicolon such as:(colon) or	(tab) is left literal, so the scheme-detection check finds no scheme, and the method falls through to its scheme-less path and returnstrue.A browser, however, decodes numeric character references even without a trailing semicolon. An encoded colon such as
:becomes the:scheme separator, sojavascript:alert(1)resolves tojavascript:alert(1). Encoded whitespace such as	(tab) is decoded and then stripped from the URL, rejoining the surrounding text, sojava	script:alert(1)also resolves tojavascript:alert(1). In both cases the URL executes whileallowed_uri?approved it as safe.Note that Loofah's default
sanitize()path is not affected, because Nokogiri decodes or entity-escapes HTML entities during parsing before Loofah evaluates the URI protocol. This issue only affects callers of the publicallowed_uri?string-level helper that pass it HTML-encoded strings.Impact
Callers that validate a user-controlled URL with
Loofah::HTML5::Scrub.allowed_uri?and then render the approved value into anhrefor other browser-interpreted URI attribute may be vulnerable to cross-site scripting (XSS). This includes applications that callallowed_uri?directly, as well as higher-level features built on top of it, such as Action Text 8.2's markdown link validation.Mitigation
Upgrade to Loofah >= 2.25.2.
Credit
Responsibly reported by GitHub user @MoonFuji.