[6] CSP Port-Matching Bypass via Unconditional Port-Equivalence Relaxation

Severity: Medium | Component: WebCore CSP | c82619c

Rated Medium because the observable effect is a CSP policy bypass allowing resources from port 443 to match a source expression intended to restrict to port 80, but the practical impact is limited by the rarity of CSP configurations that specify port 80 on an HTTPS source expression. Confidence is 0.92 based on the clearly demonstrated information-loss mechanism in schemeMatches → portMatches.

Patch Details

The patch refactors schemeMatches() to return a SchemeMatchResult enum (NoMatch, Match, InsecureUpgradeMatch) instead of a plain bool, and threads this information into portMatches() via a ShouldUpgradePorts parameter. The port-equivalence logic (treating port 80 and 443 as interchangeable defaults) now only fires when an actual insecure-to-secure scheme upgrade occurred.

Source/WebCore/page/csp/ContentSecurityPolicySource.cpp

LayoutTests/.../script-src-parsing-implicit-and-explicit-port-number.html

Lost information flow between scheme matching and port matching causes a CSP port-equivalence relaxation to fire outside its intended precondition.

Background

Content Security Policy (CSP) source expressions specify allowed origins for resource loading. A directive like script-src https://host:80 should only allow scripts from that exact host and port. WebKit implements "scheme upgrade" logic per the CSP3 spec: when a CSP source uses an insecure scheme (http) but the URL uses the secure equivalent (https), the match is allowed and default ports are treated as equivalent (80↔443) since they differ across schemes. This port equivalence should only apply when an actual insecure-to-secure scheme transition occurs. ContentSecurityPolicySource::matches() calls schemeMatches(), hostMatches(), portMatches(), and pathMatches() in sequence.

Analysis

Before the fix, portMatches() unconditionally applied port upgrade logic whenever the URL used a secure scheme and the source expression's port looked "upgradable." The critical flaw was in isCurrentUpgradable: its first disjunct (m_port == defaultInsecurePort) checked only the port value with no scheme constraint. Any source expression with port 80 was considered upgradable — including https://host:80 where no scheme upgrade occurred. Because schemeMatches() returned a plain bool, the information about whether the match was exact (https↔https) or an insecure→secure upgrade (http→https) was lost before portMatches() ran.

Concrete bypass: source expression https://host:80 against URL https://host:443. schemeMatches() returns true (exact match). In portMatches(): isUpgradeSecure = true (port 443 == defaultSecurePort), isCurrentUpgradable = true (m_port 80 == defaultInsecurePort — first disjunct, no scheme check). Result: match, despite port 80 ≠ 443 and no scheme upgrade having occurred.

Audit directions