When a Form in One Site Receives Another Site's Secret

The Android Autofill Framework's most serious web failure is not that a password manager offers an untidy list of suggestions. It is that the translated structure can make a field in one site look eligible for a credential belonging to another. This chapter diagnoses two related outcomes—Cross-Site Credential Leakage and Cross-Site Suggestions—so readers can distinguish an automatic secret-bearing write from a misleading offer that still requires user acceptance. In both cases, the browser's ordinary Same-Origin Policy can remain in place while the autofill path makes a different security decision.

The difference between the two attacks is a difference in control. In a leakage attack, credentials are placed into fields controlled by the wrong context. In a suggestion attack, the password manager presents a credential for the wrong site and the user may be persuaded to accept it. Both begin with a mismatch between the page the user sees and the context represented to the autofill service, but the last step and the attacker's required capabilities are not the same.

Cross-Site Credential Leakage: when the final write crosses the frame boundary

Cross-Site Credential Leakage, or XSCL, occurs when a top-level page and an embedded page belong to different sites but the autofill pipeline injects credentials intended for one into fields controlled by the other. The crucial word is “injects.” The problem is not merely that a password manager considered a wrong candidate. A returned credential reaches a field whose web context should have excluded it.

The AutoFail analysis identifies three conditions that make this possible. First, the browser can expose an excessive scope. Instead of describing only the focused form and its immediate companions, it can send a structure that includes fields from another document or from a wider part of the page. Second, the password manager can fill indiscriminately, ignoring the hierarchy or the boundary between sibling and non-sibling fields. Third, the browser can fail to validate the targets when it receives the password manager's response. Together, these conditions let an ambiguity travel all the way to a secret-bearing write.

Imagine a legitimate page containing a login form and a cross-site child frame. The user focuses the visible login form. The browser requests autofill and supplies a structure that includes the child frame's fields or does not clearly identify which document owns them. The password manager sees a domain value that matches one of its stored credentials and returns a response that covers more than the focused context. If the browser accepts that response without checking its destinations, the credential can be placed in fields inside the child frame.

Those fields do not need to be visible. An attacker controlling the child content can add a form whose fields are transparent or otherwise hidden from the user. The user believes they are logging in to the legitimate page, but the autofill write also populates the attacker's fields.