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 Chrome Security team.

Overview: In release builds, PaymentManifestVerifier uses GURL.toString() as a cache key, which falls back to Object.toString() and outputs a string containing the URL’s 32-bit Java hash code. An attacker can exploit this easily computable hash collision to poison the payment manifest cache. This potentially allows a malicious Android app to bypass verification and intercept payment data for legitimate, unassociated payment methods.

Affected files:

• components/payments/content/android/java/src/org/chromium/components/payments/PaymentManifestVerifier.java
• url/android/java/src/org/chromium/url/GURL.java
• components/payments/content/android/java/src/org/chromium/components/payments/AndroidPaymentAppFinder.java
• components/payments/content/web_payments_table.cc
• components/payments/content/android/web_payments_web_data_service_android.cc

Estimated timestamp from git blame: 2017-08-01

The PaymentManifestVerifier in Chrome for Android utilizes a persistent SQLite-backed cache (via WebPaymentsWebDataService) to store validated payment method manifests. This cache prevents Chrome from needing to download and parse manifest files every time a payment request is initiated.

The Vulnerability

There is a flaw in how the cache key is generated for payment method manifests in PaymentManifestVerifier.java. Both when reading from the cache (line 267) and when writing to the cache (line 458), the verifier uses mMethodName.toString() as the cache key, where mMethodName is a GURL object.

In official Android release builds (where BuildConfig.ENABLE_ASSERTS is false), org.chromium.url.GURL.toString() is implemented to return super.toString(). Since GURL does not explicitly extend another class, this resolves to java.lang.Object.toString(), which returns getClass().getName() + "@" + Integer.toHexString(hashCode()).

Because GURL overrides hashCode() to return the 32-bit Java String.hashCode() of the URL spec, the resulting cache key string is org.chromium.url.GURL@ followed by the hex representation of the URL’s 32-bit string hash.

Java’s String.hashCode() algorithm uses a small multiplier (31) and a 32-bit space, making it highly susceptible to trivial preimage attacks (hash collisions). This means an attacker can easily find an arbitrary URL whose hash matches the hash of a target legitimate payment method URL.

Potential Attack Scenario

(Note: These are suggested steps; our tooling agent cannot execute code to verify this end-to-end.)

1. Preconditions: An attacker computes an attacker_url (e.g., https://attacker.com/collision) that hash-collides with a target payment method (e.g., https://bank.com/pay). The attacker induces a user to install two malicious apps: App A (registered for attacker_url) and App B (registered for target_url and designed to steal payment data).
2. Cache Poisoning: The user visits an attacker-controlled HTTPS page that initiates a PaymentRequest for the attacker_url. Chrome creates a verifier, downloads the attacker’s manifest, and validates App B as a related application. Crucially, the verifier writes this verification result to the SQLite cache using mMethodName.toString() as the key. Because of the hash collision, this poisoned key is identical to the key that will be used for the target URL.
3. Exploitation: When the user later visits a legitimate merchant that requests the target_url payment method, PaymentManifestVerifier queries the cache using target_url.toString(). Due to the collision, it retrieves the attacker’s poisoned entry. The verifier then incorrectly validates the attacker’s App B against the poisoned manifest cache, authorizing it as a legitimate handler for the target payment method.

Impact

An attacker can successfully bypass the W3C Payment Method Manifest verification mechanism. This allows a malicious application to be presented as a valid payment handler on a legitimate merchant’s site, enabling the app to receive the merchant’s payment intent, including sensitive cross-origin data such as the topLevelOrigin, paymentRequestOrigin, and the merchant’s specific PaymentMethodData.

Suggested Fix

In PaymentManifestVerifier.java, modify all cache interactions to use the actual URL string rather than toString().

Change lines 267 and 458 to use mMethodName.getSpec() instead of mMethodName.toString().

For example, line 267 should be: if (!mCache.getPaymentMethodManifest(mMethodName.getSpec(), this)) {

And line 457-458 should be: mCache.addPaymentMethodManifest(mMethodName.getSpec(), ...)

This ensures the exact URL string is used as the unique key in the SQLite database, preventing hash collision attacks.

Evaluated with Chrome root at commit: 096fc8fdbfacf2546485756d03f160a3d04fcc9b

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.