Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the security team.

Overview: A parser differential exists in Android WebView’s WebAddressParser due to an incorrect regex handling URLs with empty passwords. This flaw incorrectly transforms URLs like ‘https://victim.com:@evil.com/' into ‘https://victim.com/@evil.com/'. Attackers can exploit this parser differential in applications with WebView cookie bridges to bypass validation and steal cross-origin cookies.

Affected files:

• android_webview/java/src/org/chromium/android_webview/WebAddressParser.java
• android_webview/glue/java/src/com/android/webview/chromium/CookieManagerAdapter.java

Estimated timestamp from git blame: 2021-09-10

Summary

A potential vulnerability exists in WebAddressParser.java within Android WebView due to an incorrect regular expression used to parse the authority component of a URL. This flaw creates a parser differential that can allow an attacker to bypass application-level host validations and access cross-origin cookies via the CookieManager API.

Technical Details

In WebAddressParser.java, the AUTHORITY regex is defined as:

private static final String AUTHORITY = "(?:([^/?#:]+(?::[^/?#]+)?)@)?";

When parsing a URL with an empty password (e.g., https://victim.com:@evil.com/), the AUTHORITY regex fails to match. The inner password sub-pattern (?::[^/?#]+)? greedily consumes the :@evil.com portion because the character class [^/?#] does not exclude the @ symbol. Consequently, the mandatory trailing @ for the outer AUTHORITY group cannot be satisfied, causing the entire group match to fail and be skipped.

Because AUTHORITY fails, the parser falls back to evaluating the remaining URL components:

1. HOST: Matches victim.com (stopping at the invalid : character).
2. PORT: Matches the : but captures an empty string, effectively dropping the colon.
3. PATH: Matches the remainder, becoming /@evil.com/.

The toString() method then reconstructs the URL as https://victim.com/@evil.com/.

This transformation is a significant security risk. Standard parsers like java.net.URL identify the host of the original payload (https://victim.com:@evil.com/) as evil.com. However, the native Chromium CookieManager uses GURL, which interprets the transformed URL (https://victim.com/@evil.com/) as having the host victim.com.

Potential Attacker Steps

Note: These are suggested steps to trigger the vulnerability, as our automated tooling cannot execute proof-of-concept code yet.

1. An Android application implements a JavaScript bridge to allow WebView content to interact with the CookieManager (e.g., to get/set cookies) to support its web functionality.
2. To secure this bridge, the application validates the requested URL using java.net.URL(url).getHost() and ensures the host is in an allowlist of trusted domains.
3. An attacker navigates the user to a malicious page (evil.com, assuming it is allowlisted or the attacker controls the starting domain) within the WebView.
4. The malicious page calls the exposed bridge with the payload https://victim.com:@evil.com/.
5. The application’s validation succeeds because java.net.URL correctly parses the host as evil.com.
6. The application passes the raw payload to CookieManager.getCookie(url).
7. The WebView glue layer’s CookieManagerAdapter.fixupUrl() processes the payload using WebAddressParser, silently transforming it to https://victim.com/@evil.com/.
8. The native AwCookieManager queries victim.com cookies and returns them, allowing the attacker to steal cross-origin session cookies.

Suggested Fix

The most robust fix is to deprecate and remove the custom regex-based WebAddressParser entirely, replacing it with Chromium’s native GURL parser via JNI or a standard robust Java parser.

If a quick regex fix is required, modify the password sub-pattern to explicitly exclude the @ symbol:

private static final String AUTHORITY = "(?:([^/?#:]+(?::[^/?#@]+)?)@)?";

This prevents the password group from greedily consuming the host portion when an empty password is provided.

Evaluated with Chrome root at commit: f200f57a19490707ff8bc7aa5de3cbc443a3afad

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.