Rewrite security section #692

npm1 · 2025-01-15T21:06:31Z

Improves the security section by adding a brief introduction and mostly talking about threats and attacks as well as the mitigations for each. See #652

Preview | Diff

npm1 · 2025-01-15T21:06:44Z

Can you take a look @philsmart

philsmart

Hi @npm1, the new structuring of the threats looks good to me, thanks. I've added some comments to the PR (mostly clarifications and suggestions where mitigations might layer or overlap).

if we want to conform to the suggested Security Consideration section structuring in security-questionnaire#181, I think the spec might still need a 'Security Assumptions' section, but would ask for @simoneonofri's advice on that. If it does, some ideas (wording/terminology is probably poor):

The user agent is not, itself, acting maliciously and therefore the FedCM API is well-behaved.
- While the site may behave maliciously if compromised, the user agent implementing FedCM will not.
- Therefore, fetches to HTTP endpoints are performed through this well-behaved user agent (either via FedCM, or if attempted directly via nefarious JavaScript).
  - Otherwise, we would have to assume the attacker has access to public IdP HTTP endpoints e.g. using a different user agent which allows the user/scripts to set security headers etc.
An attacker will not have physical access to a victim user's active session on their user agent.
- Probably an implicit assumption anyway.
(If IdP Registration API is in scope) There is no guarantee of pre-established trust (technical or otherwise) between RPs and IdPs. For example, an attacker can register their own IdP to use at RPs that support the IdP registration API.
The messages carried via FedCM are based on an established, secure, identity protocol.
Communication between FedCM and the IdP occurs over a secure channel e.g. TLS.
...

Maybe @simoneonofri and @TallTed would be kind enough to give this PR are scan as well, before it goes out for wider review.

spec/index.bs

simoneonofri · 2025-01-21T14:02:26Z

Thank you. I will review it this week, and the security assumptions make sense.

One of the reasons security assumption exists is to put the scope.

It is a good point that we assume the UA is 'good' to understand whether we are considering a malicious extension in scope or not.

And in general it should me useful to find a mitigation to that point.

npm1 · 2025-01-21T16:28:42Z

I do not want to add obvious things to the spec just for the sake of adding them. Pretty much all web platform APIs assume that the 'UA is good', no? Is there any example of a spec where it considers the UA as an attacker?

TallTed

This is not exhaustive, but these tweaks should make some parts clearer.

spec/index.bs

TallTed

Small fixes

spec/index.bs

philsmart

I've left two further minor text adjustment suggestions. Otherwise, this all looks good to me.

spec/index.bs

philsmart · 2025-01-24T10:04:51Z

spec/index.bs

+<!-- ============================================================ -->
+
+An attacker who has some knowledge about the user via previous tracking could try to impersonate a
+real [=IDP=] by registering itself as a FedCM provider and invoking the FedCM API. However, this


I see, the rename makes sense.

spec/index.bs

philsmart · 2025-01-24T11:01:32Z

spec/index.bs

+that the request was originated by the FedCM browser rather than sent by a websites trying to run an
+XSS attack. An [=IDP=] needs to check for this header's value in the credentialed requests it
+receives, which ensures that the request was initiated by the user agent, based on the FedCM API.
+This protects the new [=IDP=] endpoints from unauthorized fetches.


Text additions LGTM

spec/index.bs

npm1 · 2025-01-27T17:30:13Z

I think I have addressed the comments, ptal

philsmart · 2025-01-27T17:34:27Z

LGTM, thanks.

simoneonofri · 2025-02-03T21:51:49Z

spec/index.bs

@@ -2559,49 +2559,65 @@ The [=remote end steps=] are:
 This section provides a few of the security considerations for the FedCM API. Note that there is a
 separate section for [[#privacy]] considerations.

+In FedCM, there are various assets that need to be protected. All of the endpoints need basic
+protections, and the credentialed ones need protections from various kinds of attacks and threats.


Suggested change

protections, and the credentialed ones need protections from various kinds of attacks and threats.

protections, and the credentialed ones need protections from various kinds of attacks and threats.



## Security Assumptions ## {#security-assumptions}



The design of FedCM relies on several key security assumptions:



### Trusted User Agent ### {#trusted-user-agent}



The user agent (i.e., the browser) is assumed to be a trusted entity. It is expected to faithfully

enforce same-origin policies, execute CSP and CORS checks, and present a secure, non-forgeable UI

that users can trust, and to not contains or executes malicious third parties scripts. The browser

is responsible for mediating the flow and preventing unauthorized access to credentials.



### Secure Network and Transport ### {#secure-network-transport}



All network requests — especially those carrying sensitive information such as tokens — occur over

secure channels (e.g. HTTPS). The specification assumes that the transport layer prevents

man-in-the-middle and other network attacks.



### Proper Implementation of Security Headers ### {#proper-implementation-headers}



[=IDP=] and [=RP=] implement and enforce appropriate security headers (such as CSP, CORS,

and the mandatory use of the `Sec-Fetch-Dest: webidentity` header). These headers are key to

distinguishing browser-initiated FedCM flows from arbitrary requests.



### IDP and RP Integrity ### {#proper-implementation-headers}



IDP and RP endpoints are implemented correctly and do not contain vulnerabilities that could

allow an attacker to bypass the FedCM flow or extract sensitive data.



## Threats and Attacks ## {#security-threats-aattacks}



Adding some assumptions. I have been thinking about this for a long time, and it makes sense that some assumptions may seem obvious to us (precisely because they are things we take for granted), but they are useful in defining the scope of the specification, even “outside” of what is the environment we consider within the trust boundaries.

simoneonofri

Thank you for all the effort in the Security Consideration section.

I've just proposed some assumptions and a formatting for the pairs threats/mitigations

simoneonofri · 2025-02-03T21:53:11Z

spec/index.bs

 <!-- ============================================================ -->
-## Content Security Policy ## {#content-security-policy}
+## Cross-Site Scripting ## {#cross-site-scripting}
 <!-- ============================================================ -->



Suggested change

**Threat**:

Suggested change

**Threat**

simoneonofri · 2025-02-03T21:54:28Z

spec/index.bs

+API calls to a legitimate [=IDP=]. If the call is successful, this would introduce some browser UI
+where all parties might look legitimate to the user. If the user logs in using the FedCM API in this
+scenario, their credentials are then received by the malicious script, which can then send it to its
+own server. The protection against this attack is to sanitize all user input to prevent script


Suggested change

own server. The protection against this attack is to sanitize all user input to prevent script

own server.

**Mitigation**:

The protection against this attack is to sanitize all user input to prevent script

Suggested change

own server. The protection against this attack is to sanitize all user input to prevent script

own server.

**Mitigation**

The protection against this attack is to sanitize all user input to prevent script

simoneonofri · 2025-02-03T21:55:05Z

spec/index.bs

+scenario, their credentials are then received by the malicious script, which can then send it to its
+own server. The protection against this attack is to sanitize all user input to prevent script
+injection, and to use [[!CSP]] to restrict the execution of inline scripts.
+


Suggested change

**Threat**:

Suggested change

**Threat**

simoneonofri · 2025-02-03T21:55:45Z

spec/index.bs

+
+A script could also instead use the FedCM API to request credentials from some [=IDP=] that is not
+approved by the [=RP=]. If the user went through this flow, these credentials could also be stolen,
+or the [=RP=]'s reputation could be harmed. An additional protection for this scenario is that the


Suggested change

or the [=RP=]'s reputation could be harmed. An additional protection for this scenario is that the

or the [=RP=]'s reputation could be harmed.

**Mitigation**:

An additional protection for this scenario is that the

Suggested change

or the [=RP=]'s reputation could be harmed. An additional protection for this scenario is that the

or the [=RP=]'s reputation could be harmed.

**Mitigation**

An additional protection for this scenario is that the

simoneonofri · 2025-02-03T21:56:26Z

spec/index.bs


 <!-- ============================================================ -->
-## Sec-Fetch-Dest Header ## {#sec-fetch-dest-header}
+## Unauthorized Fetching ## {#unauthorized-fetching}
 <!-- ============================================================ -->



Suggested change

**Threat**:

Suggested change

**Threat**

simoneonofri · 2025-02-03T22:06:25Z

spec/index.bs

+## Clickbait ## {#clickbait}
+<!-- ============================================================ -->
+
+An attacker controlled [=IDP=] could attempt to trick the user into going through the FedCM UI by


Suggested change

An attacker controlled [=IDP=] could attempt to trick the user into going through the FedCM UI by

**Threat**:

An attacker controlled [=IDP=] could attempt to trick the user into going through the FedCM UI by

Suggested change

An attacker controlled [=IDP=] could attempt to trick the user into going through the FedCM UI by

**Threat**

An attacker controlled [=IDP=] could attempt to trick the user into going through the FedCM UI by

simoneonofri · 2025-02-03T22:07:14Z

spec/index.bs

+visible in the UI. For example, they could enter text such as "Click here to win $100!". As this
+requires the attacker to control the [=IDP=], the gain would be minimal, i.e. access to user
+tracking within the [=RP=]. No sensitive information would be shared with the attacker in this case.
+To mitigate this, the user agent can add [=IDP=]-independent text to ensure that the user has some


Suggested change

To mitigate this, the user agent can add [=IDP=]-independent text to ensure that the user has some

**Mitigation**:

To mitigate this, the user agent can add [=IDP=]-independent text to ensure that the user has some

Suggested change

To mitigate this, the user agent can add [=IDP=]-independent text to ensure that the user has some

**Mitigation**

To mitigate this, the user agent can add [=IDP=]-independent text to ensure that the user has some

simoneonofri · 2025-02-03T22:07:50Z

spec/index.bs

+## Clickjacking ## {#clickjacking}
+<!-- ============================================================ -->
+
+An attacker could surface UI to try to force the user into accidentally consenting to the FedCM


Suggested change

An attacker could surface UI to try to force the user into accidentally consenting to the FedCM

**Threat**:

An attacker could surface UI to try to force the user into accidentally consenting to the FedCM

Suggested change

An attacker could surface UI to try to force the user into accidentally consenting to the FedCM

**Threat**

An attacker could surface UI to try to force the user into accidentally consenting to the FedCM

simoneonofri · 2025-02-03T22:09:36Z

spec/index.bs

+user information from a real [=IDP=]. For example, an attacker could have a button 'click here 4
+times' which would surface the FedCM dialog the first time it is clicked. If the timing and the
+location of this button works out, an unsuspecting user would click on their account in the FedCM
+dialog when it appears. There are a couple of possible mitigations to this. One is the user agent


Suggested change

dialog when it appears. There are a couple of possible mitigations to this. One is the user agent

dialog when it appears.

**Mitigation**:

There are a couple of possible mitigations to this. One is the user agent

Suggested change

dialog when it appears. There are a couple of possible mitigations to this. One is the user agent

dialog when it appears.

**Mitigation**

There are a couple of possible mitigations to this. One is the user agent

simoneonofri · 2025-02-03T22:10:30Z

spec/index.bs

+enhanced protection. To enable this, we impose the requirement that the [=IDP=] explicitly consents
+to this sharing taking place by using the "cors" [=request/mode=] when fetching this endpoint. This
+also helps with servers that may accidentally ignore the <a http-header>Sec-Fetch-Dest</a>: they
+cannot ignore CORS, as without it the fetch will fail.

 <!-- ============================================================ -->
 ## Browser Surface Impersonation ## {#browser-surface-impersonation}


on this, for some reason I cannot propose the threat/mitigation schema

TallTed · 2025-02-04T18:21:44Z

For better readability, I strongly advise that **Mitigation**: and similar headings either drop the colons (preferred), e.g., **Mitigation**, or include the colons in the bold, e.g., **Mitigation:**.

simoneonofri · 2025-02-04T20:02:15Z

Hi Ted, it is ok for me as you proposed

TallTed · 2025-02-04T23:35:21Z

spec/index.bs

 <!-- ============================================================ -->
-## Content Security Policy ## {#content-security-policy}
+## Cross-Site Scripting ## {#cross-site-scripting}
 <!-- ============================================================ -->



Suggested change

**Threat**

TallTed · 2025-02-04T23:35:57Z

spec/index.bs

+API calls to a legitimate [=IDP=]. If the call is successful, this would introduce some browser UI
+where all parties might look legitimate to the user. If the user logs in using the FedCM API in this
+scenario, their credentials are then received by the malicious script, which can then send it to its
+own server. The protection against this attack is to sanitize all user input to prevent script


Suggested change

own server. The protection against this attack is to sanitize all user input to prevent script

own server.

**Mitigation**

The protection against this attack is to sanitize all user input to prevent script

TallTed · 2025-02-04T23:36:48Z

spec/index.bs

+scenario, their credentials are then received by the malicious script, which can then send it to its
+own server. The protection against this attack is to sanitize all user input to prevent script
+injection, and to use [[!CSP]] to restrict the execution of inline scripts.
+


Suggested change

**Threat**

TallTed · 2025-02-04T23:37:48Z

spec/index.bs

+
+A script could also instead use the FedCM API to request credentials from some [=IDP=] that is not
+approved by the [=RP=]. If the user went through this flow, these credentials could also be stolen,
+or the [=RP=]'s reputation could be harmed. An additional protection for this scenario is that the


Suggested change

or the [=RP=]'s reputation could be harmed. An additional protection for this scenario is that the

or the [=RP=]'s reputation could be harmed.

**Mitigation**

An additional protection for this scenario is that the

TallTed · 2025-02-04T23:38:11Z

spec/index.bs


 <!-- ============================================================ -->
-## Sec-Fetch-Dest Header ## {#sec-fetch-dest-header}
+## Unauthorized Fetching ## {#unauthorized-fetching}
 <!-- ============================================================ -->



Suggested change

**Threat**

TallTed · 2025-02-04T23:40:54Z

spec/index.bs

+real [=IDP=] by pretending to be an [=IDP=] and invoking the FedCM API. However, this does not grant
+much more power to the attacker: if the user logs in via FedCM to the attacker, the attacker can now
+track the user more easily within the [=RP=], but the attacker was already tracking the user in
+order to surface a meaningful dialog. That said, [=IDP=] impersonation would still be poor UX for


Suggested change

order to surface a meaningful dialog. That said, [=IDP=] impersonation would still be poor UX for

order to surface a meaningful dialog.

**Mitigation**

That said, [=IDP=] impersonation would still be poor UX for

TallTed · 2025-02-04T23:41:35Z

spec/index.bs

+## Clickbait ## {#clickbait}
+<!-- ============================================================ -->
+
+An attacker controlled [=IDP=] could attempt to trick the user into going through the FedCM UI by


Suggested change

An attacker controlled [=IDP=] could attempt to trick the user into going through the FedCM UI by

**Threat**

An attacker controlled [=IDP=] could attempt to trick the user into going through the FedCM UI by

TallTed · 2025-02-04T23:41:57Z

spec/index.bs

+visible in the UI. For example, they could enter text such as "Click here to win $100!". As this
+requires the attacker to control the [=IDP=], the gain would be minimal, i.e. access to user
+tracking within the [=RP=]. No sensitive information would be shared with the attacker in this case.
+To mitigate this, the user agent can add [=IDP=]-independent text to ensure that the user has some


Suggested change

To mitigate this, the user agent can add [=IDP=]-independent text to ensure that the user has some

**Mitigation**

To mitigate this, the user agent can add [=IDP=]-independent text to ensure that the user has some

TallTed · 2025-02-04T23:42:24Z

spec/index.bs

+## Clickjacking ## {#clickjacking}
+<!-- ============================================================ -->
+
+An attacker could surface UI to try to force the user into accidentally consenting to the FedCM


Suggested change

An attacker could surface UI to try to force the user into accidentally consenting to the FedCM

**Threat**

An attacker could surface UI to try to force the user into accidentally consenting to the FedCM

TallTed · 2025-02-04T23:42:43Z

spec/index.bs

+user information from a real [=IDP=]. For example, an attacker could have a button 'click here 4
+times' which would surface the FedCM dialog the first time it is clicked. If the timing and the
+location of this button works out, an unsuspecting user would click on their account in the FedCM
+dialog when it appears. There are a couple of possible mitigations to this. One is the user agent


Suggested change

dialog when it appears. There are a couple of possible mitigations to this. One is the user agent

dialog when it appears.

**Mitigation**

There are a couple of possible mitigations to this. One is the user agent

security

aabc3ef

npm1 mentioned this pull request Jan 16, 2025

Horizontal Review preparation #652

Open

5 tasks

philsmart reviewed Jan 21, 2025

View reviewed changes

TallTed suggested changes Jan 21, 2025

View reviewed changes

spec/index.bs Outdated Show resolved Hide resolved

spec/index.bs Outdated Show resolved Hide resolved

spec/index.bs Outdated Show resolved Hide resolved

spec/index.bs Outdated Show resolved Hide resolved

spec/index.bs Outdated Show resolved Hide resolved

comments

5fc6e04

TallTed suggested changes Jan 23, 2025

View reviewed changes

spec/index.bs Outdated Show resolved Hide resolved

spec/index.bs Outdated Show resolved Hide resolved

nits

f686656

philsmart reviewed Jan 24, 2025

View reviewed changes

nits

f0808a1

philsmart mentioned this pull request Jan 30, 2025

Clarify the necessity to protect against device exfil attacks #664

Open

npm1 requested a review from simoneonofri January 30, 2025 16:14

simoneonofri reviewed Feb 3, 2025

View reviewed changes

simoneonofri requested changes Feb 3, 2025

View reviewed changes

philsmart mentioned this pull request Feb 4, 2025

Security considerations should be consistently organised by security risk? #685

Closed

TallTed suggested changes Feb 4, 2025

View reviewed changes

-protections, and the credentialed ones need protections from various kinds of attacks and threats.
+protections, and the credentialed ones need protections from various kinds of attacks and threats.
+<!-- ============================================================ -->
+## Security Assumptions ## {#security-assumptions}
+<!-- ============================================================ -->
+The design of FedCM relies on several key security assumptions:
+<!-- ============================================================ -->
+### Trusted User Agent ### {#trusted-user-agent}
+<!-- ============================================================ -->
+The user agent (i.e., the browser) is assumed to be a trusted entity. It is expected to faithfully
+enforce same-origin policies, execute CSP and CORS checks, and present a secure, non-forgeable UI
+that users can trust, and to not contains or executes malicious third parties scripts. The browser
+is responsible for mediating the flow and preventing unauthorized access to credentials.
+<!-- ============================================================ -->
+### Secure Network and Transport ### {#secure-network-transport}
+<!-- ============================================================ -->
+All network requests — especially those carrying sensitive information such as tokens — occur over
+secure channels (e.g. HTTPS). The specification assumes that the transport layer prevents
+man-in-the-middle and other network attacks.
+<!-- ============================================================ -->
+### Proper Implementation of Security Headers ### {#proper-implementation-headers}
+<!-- ============================================================ -->
+[=IDP=] and [=RP=] implement and enforce appropriate security headers (such as CSP, CORS,
+and the mandatory use of the `Sec-Fetch-Dest: webidentity` header). These headers are key to
+distinguishing browser-initiated FedCM flows from arbitrary requests.
+<!-- ============================================================ -->
+### IDP and RP Integrity ### {#proper-implementation-headers}
+<!-- ============================================================ -->
+ IDP and RP endpoints are implemented correctly and do not contain vulnerabilities that could
+ allow an attacker to bypass the FedCM flow or extract sensitive data.
+<!-- ============================================================ -->
+## Threats and Attacks ## {#security-threats-aattacks}
+<!-- ============================================================ -->

Rewrite security section #692

Are you sure you want to change the base?

Rewrite security section #692

Conversation

npm1 commented Jan 15, 2025 • edited by pr-preview bot Loading

npm1 commented Jan 15, 2025

philsmart left a comment • edited Loading

Choose a reason for hiding this comment

simoneonofri commented Jan 21, 2025

npm1 commented Jan 21, 2025

TallTed left a comment

Choose a reason for hiding this comment

TallTed left a comment

Choose a reason for hiding this comment

philsmart left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

npm1 commented Jan 27, 2025

philsmart commented Jan 27, 2025

Choose a reason for hiding this comment

simoneonofri left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TallTed commented Feb 4, 2025

simoneonofri commented Feb 4, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

npm1 commented Jan 15, 2025 •

edited by pr-preview bot

Loading

philsmart left a comment •

edited

Loading