Showing content from https://github.com/w3c-fedid/FedCM/issues/230 below:
User identity associated with the RP should not be sent to the IDP before explicit consent is gathered · Issue #230 · w3c-fedid/FedCM · GitHub
There is a potential attack that discloses that a user visited an RP to an IDP without explicit consent.
- RP creates a credential, specifying the IDP in the
federated parameter and required mode.
- The browser begins executing the create-credential algorithm.
- The browser fetches the manifest from the IDP. As specified, this sends a Referer header with value of the RP.
- The IDP returns a unique account-list url in the manifest and remembers the tuple (account-list url, RP from referer).
- The browser requests the account list via the url in the manifest, sending its IDP cookie.
- The IDP checks for the account-list url among its tuples. Upon finding one, it creates a new tuple (IDP cookie from account-list request, Referer header from manifest request).
- The IDP and RP have won.
There are two features that enable this attack: arbitrary URLs allowed in the manifest and the Referer header being sent with the manifest. Neither is explicitly permitted, but since they are explicitly forbidden in other API call in the spec I assume that they are allowed behaviors. Let me know if I'm misreading this at all!
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4