Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify the necessity to protect against device exfil attacks #664

Open
gioele-antoci opened this issue Oct 24, 2024 · 1 comment
Open

Comments

@gioele-antoci
Copy link

TL;DR: Should the FedCM specifications and/or documentation more emphatically warn against device exfiltration attacks?

Context:

  • FedCM does not take a stance on how Relying Parties (RPs) and Identity Providers (IDPs) secure the authentication exchange after the /assertion endpoint.
  • The /assertion endpoint returns a token to the front-end channel. The RP's front end is expected to submit the token to the RP's back end to ultimately open a session on the RP.
  • Passing the token through the front-end channel exposes it to device exfiltration attacks (e.g., a malicious script running on a compromised RP might monkey-patch fetch and steal the token).

RPs should be effectively guided towards implementing a nonce/PKCE flow while associating the authentication exchange with that specific device, for example, by using HttpOnly cookies.

Alternative Proposal:
Instead of returning the token from /assertion, should user agents invoke an RP's callback defined in the configuration file? This approach would alleviate some of the implementation complexity for FedCM RPs and IDPs.

Related to: #536 and #599

@samuelgoto
Copy link
Collaborator

RPs should be effectively guided towards implementing a nonce/PKCE flow while associating the authentication exchange with that specific device, for example, by using HttpOnly cookies.

Yeah, that makes sense. A couple of questions:

a) Can we do this as part of the #599 ? @aaronpk WDYT?
b) As @bvandersloot-mozilla suggested, is there anything that the browser can do to help? Would some opt-in validation help? E.g. maybe the browser could understand @aaronpk profile and throw errors when certain parameters aren't used?

Instead of returning the token from /assertion, should user agents invoke an RP's callback defined in the configuration file? This approach would alleviate some of the implementation complexity for FedCM RPs and IDPs.

I'd be happy to explore options where the browser can help make the system more secure. I'd still want to do that within the boundaries of what would show up in #599.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants