If an RP page has an XSS risk, how can we avoid token leakage in the FedCM login process?

[Yekongs]

If an RP page has an XSS risk, the attacker can execute navigator.credentials.get in its malicious code, and the attacker can obtain the token. At this time, the attacker can log in to all RPs under this IdP, which is a high risk.

Some SSO solutions solve this problem by redirecting to a third-party website and implanting cookies through browser redirection. There is basically no js code execution, so it is very easy to solve the problem that a certain RP has an xss risk and can directly attack and obtain the token.

For us FedCM, how to solve this problem? I see that there is a nonce parameter, but nonce also has the risk of being forged. So, I would like to ask if we have any suggestions, or any suggestions for the implementation of nonce, to avoid such XSS problems (How does the IdP ensure that the RP's identity is credible? Otherwise, token hijacking may occur.)

[Yekongs]

And I saw on the official website that nonce was supported only from Chrome 132. So if lower versions of Chrome don't have nonce, wouldn't the security be weaker? How can lower versions of Chrome solve the XSS problem that may occur in RP without nonce?

[wparad]

The only way is if browsers start sending a second token that is signed by the device on every request, but the browsers still are being quite lazy with baseline security in this way.

[Yekongs]

Sorry, I don't quite understand what you mean. How can I implement FedCM in my service to prevent an RP from having an XSS vulnerability, and then all RP tokens may be leaked?

You mentioned a concept similar to browser fingerprinting? But it seems that browser fingerprinting is not very accurate.

[wparad]

Are you speaking as a identity provider or as an RP?

As an identity provider, populate the AUD claim in the JWT. As an RP, trust the AUD claim, and complain to the browsers that they don't offer ways to protect against XSS on their own site

[Yekongs]

I am implementing my own IdP service, but many of my RPs are worried that if one of the other RPs has XSS risks, their security will also be affected. Therefore, they asked me to provide a secure access method. In the FedCM process, I am not sure how to do it, so I came to ask for help~

[Yekongs]

Sorry, my initial statement was wrong. RPs will not affect each other because of the existence of origin.
If a single RP is not logged in, if the RP has an XSS problem, then the login token may be obtained by malicious code, causing login status leakage. In addition to letting RP improve its own XSS protection level, is there any better way to encapsulate the FedCM login SDK for RP? Can I use RP / RP server / IdP server

[wparad]

So back to "how to prevent XSS attacks from using stolen tokens" this requires browsers to send device bound tokens, by using a second signature generated by the device. I don't really see an alternative

[johannhof]

This is the main reason why Storage Access API calls are automatically granted when there's a prior FedCM call. Some IdPs prefer / need to keep using cross-site cookies or storage for security reasons.

Would that work for your use case?

[Yekongs]

So back to "how to prevent XSS attacks from using stolen tokens" this requires browsers to send device bound tokens, by using a second signature generated by the device. I don't really see an alternative

Thank you, could you provide a detailed introduction?

[Yekongs]

This is the main reason why Storage Access API calls are automatically granted when there's a prior FedCM call. Some IdPs prefer / need to keep using cross-site cookies or storage for security reasons.

Would that work for your use case?

Thank you, Is there a corresponding demo for this?
When I was reading the document, I was confused about how the iframe IdP determines whether it is currently processing the FedCM active state
Also, I don’t quite understand how this method solves the RP XSS attack token leakage problem

[wparad]

So back to "how to prevent XSS attacks from using stolen tokens" this requires browsers to send device bound tokens, by using a second signature generated by the device. I don't really see an alternative

Thank you, could you provide a detailed introduction?

Unfortunately, Browsers don't do this today, so there is no current way to defend against it. Please lobby Mozilla and Google to update Firefox and Chromium to support utilizing TPM/HSMs to generate verifiable device signatures if you would like to see a solution to this problem. Right now they don't care.

[aaronpk]

At this time, the attacker can log in to all RPs under this IdP, which is a high risk

This is only true if all RPs accept the artifact from the IdP that was issued to any RP. In other words, RPs would already be vulnerable in the non-XSS case if this were possible via XSS.

In other words, the browser on a.example.com gets an assertion A from idp.example, and the same browser on b.example.org gets an assertion B from idp.example. If a.example.com accepts the assertion B to create a session and log the user in, then there is already an attack possible via non-XSS methods.

This is why websites need to only accept assertions that were issued to their own origin. Depending on what the output of the FedCM assertion endpoint is, this will be done in various ways.

An ID token sent from the assertion endpoint will have an aud claim, which must be verified by the RP to avoid accepting ID tokens issued to other origins. An OAuth authorization code will be bound to the instance using the PKCE code verifier.

In other words, there's nothing new about FedCM in relation to XSS. XSS attacks are still a problem within the same origin, which is described in great detail in the draft OAuth for Browser-Based Apps, but RPs already need to only accept assertions issued to themselves.

[Yekongs]

At this time, the attacker can log in to all RPs under this IdP, which is a high risk

This is only true if all RPs accept the artifact from the IdP that was issued to any RP. In other words, RPs would already be vulnerable in the non-XSS case if this were possible via XSS.

In other words, the browser on a.example.com gets an assertion A from idp.example, and the same browser on b.example.org gets an assertion B from idp.example. If a.example.com accepts the assertion B to create a session and log the user in, then there is already an attack possible via non-XSS methods.

This is why websites need to only accept assertions that were issued to their own origin. Depending on what the output of the FedCM assertion endpoint is, this will be done in various ways.

An ID token sent from the assertion endpoint will have an aud claim, which must be verified by the RP to avoid accepting ID tokens issued to other origins. An OAuth authorization code will be bound to the instance using the PKCE code verifier.

In other words, there's nothing new about FedCM in relation to XSS. XSS attacks are still a problem within the same origin, which is described in great detail in the draft OAuth for Browser-Based Apps, but RPs already need to only accept assertions issued to themselves.

You are right, my original statement was wrong. Due to the existence of origin, RPs will not affect each other.

However, for a single RP, if this RP has an XSS risk, then the attacker can directly obtain the token through FedCM, and there is a risk of login credentials leakage. I don’t know how to solve this problem.

[aaronpk]

The risk is not about login credentials leaking, as the user will have logged in on the IdP origin, completely separate from the RP origin.

The XSS risk with FedCM is the same as with OAuth/OpenID Connect. You can read OAuth for Browser-Based Apps for an in depth analysis of various methods of protecting against and mitigating XSS attacks, as well as this document from OWASP.

[johannhof]

This is the main reason why Storage Access API calls are automatically granted when there's a prior FedCM call. Some IdPs prefer / need to keep using cross-site cookies or storage for security reasons.
Would that work for your use case?

Thank you, Is there a corresponding demo for this? When I was reading the document, I was confused about how the iframe IdP determines whether it is currently processing the FedCM active state Also, I don’t quite understand how this method solves the RP XSS attack token leakage problem

Right, to clarify, if you decide to expose a token that is sensitive enough to be vulnerable to theft, it can be stolen, this feature doesn't change that. As mentioned here there are ways to mitigate the impact of this. Or you don't expose the token and manage your session via cross-site cookies on the IdP (i.e. by redirecting through the IdP). The Storage Access API will grant you this permission with FedCM allowed on the page, and you can use Storage Access Headers to opt into individual requests regaining 3PC access.

@ewewraw do we have a demo of the SAA autogranting by any chance? :)

[Yekongs]

This is the main reason why Storage Access API calls are automatically granted when there's a prior FedCM call. Some IdPs prefer / need to keep using cross-site cookies or storage for security reasons.
Would that work for your use case?

Thank you, Is there a corresponding demo for this? When I was reading the document, I was confused about how the iframe IdP determines whether it is currently processing the FedCM active state Also, I don’t quite understand how this method solves the RP XSS attack token leakage problem

Right, to clarify, if you decide to expose a token that is sensitive enough to be vulnerable to theft, it can be stolen, this feature doesn't change that. As mentioned here there are ways to mitigate the impact of this. Or you don't expose the token and manage your session via cross-site cookies on the IdP (i.e. by redirecting through the IdP). The Storage Access API will grant you this permission with FedCM allowed on the page, and you can use Storage Access Headers to opt into individual requests regaining 3PC access.

@ewewraw do we have a demo of the SAA autogranting by any chance? :)

At present, in addition to improving RP's own XSS security protection, the only thing left is the Storage Access API. I hope we can have a demo that combines the Storage Access API with FedCM~

[samuelgoto]

At present, in addition to improving RP's own XSS security protection, the only thing left is the Storage Access >API. I hope we can have a demo that combines the Storage Access API with FedCM~

I don't think the Storage Access API auto-grant helps you prevent XSSes in any way. I think you are looking for the pointers that @aaronpk linked here.

Is there anything else actionable here other than following @aaronpk 's guidance? Can I close this?

[philsmart]

What everybody else has said. Just to add, from the perspective of what you get back from the navigator.credentials.get call, this threat has been described in the Credential Management Specification (see https://www.w3.org/TR/credential-management-1/#security-leakage) which FedCM inherits from. That is of course about avoiding the FedCM 'IdentityCredential' from being stolen, you should still be using a secure authentication/authorization protocol/flow (see @aaronpk's comments).