Closed arturjanc closed 1 year ago
From an embedded application & SSO perspective, the functionality described here sounds undesirable. In Microsoft Teams and Office, 1P/3P developers may embed applications running across different origins that we'd like to allow cookies access to (for SSO with our IdP/STS), based on a single SAA prompt, rather than multiple prompts or prompts on a per-frame basis. Multiple prompts would make for a highly disrupted user experience in such cases
/cc @jasonnutter and @timcappalli who I believe shared similar feedback offline
Can you clarify which of the specific restrictions above (from the second list) will have the effect of causing multiple prompts in your setup? I assume you mean (3) where storage access would be scoped to the requesting origin instead of the site?
I don’t think multiple prompts for the same pair of top and embedded site is a thing in any of the implementations. It certainly isn’t in WebKit. Once the user has opted in for a pair, that is remembered and the will be no prompt.
That's true, but the suggestion in (3) is to scope the grant to <embedding site, grantee origin> as opposed to <embedding site, grantee site> -- which I believe matches the current scope in Firefox, but not WebKit. On pages that embed multiple frames from the same site, but different origins (e.g. site.example
embedding widget1.site2.example
and widget2.site2.example
) this would result in multiple prompts.
I doubt we’d prompt per subdomain if we’ve granted for one of them under the same registrable domain. We would probably just grant on interaction + API call.
The concern with this approach is that it reduces security by exposing unrelated same-site-but-cross-origin applications to cross-site attacks after storage access is granted to any document within their site. The consequence of this behavior is that third-party cookie deprecation would lose much of its security value.
As an example, there were places where browsers made the assumption that the removal of 3p cookies will eliminate certain cross-origin information leaks -- unfortunately, this assumption will no longer hold when storage access granted to a sibling subdomain re-enables such leaks against the entire site (which can include more sensitive origins than the one which requested storage access).
Just to illustrate this with a quick example:
bank.example
which includes login.bank.example
with sensitive data as well as docs.bank.example
which hosts an embeddable widget which can ask for storage access to remember the location of a user's local branch.onlinestore.example
iframes docs.bank.example
as part of checkout flow (where the iframe may ask for storage access). It also has a clickthemonkey.onlinestore.example
marketing site which embeds third-party iframes with the best monkey images on the web, based on URLs sent by users.In the current model, clickthemonkey.onlinestore.example
as well as all of the iframes it embeds will receive the ability to send credentialed requests to login.bank.example
and will be to learn when the user is logged into the bank, as well as exploit XS-leaks, CSRF and related vulnerabilities in that origin.
Can you clarify which of the specific restrictions above (from the second list) will have the effect of causing multiple prompts in your setup? I assume you mean (3) where storage access would be scoped to the requesting origin instead of the site?
(1), where cross-origin subframes can't take advantage of the storage access given to embedded origin from the top frame.
Can you clarify which of the specific restrictions above (from the second list) will have the effect of causing multiple prompts in your setup? I assume you mean (3) where storage access would be scoped to the requesting origin instead of the site?
(1), where cross-origin subframes can't take advantage of the storage access given to embedded origin from the top frame.
@arturjanc ^^ this behavior, thanks @jasonnutter
In the current model, clickthemonkey.onlinestore.example as well as all of the iframes it embeds will receive the ability to send credentialed requests to login.bank.example and will be to learn when the user is logged into the bank, as well as exploit XS-leaks, CSRF and related vulnerabilities in that origin.
Can you please clarify how you envision clickthemonkey.onlinestore.example
learning the user is logged into login.bank.example
in this example? I can think of either via postMessage, redirect, or fetch/xhr, and the first two would require explicit action by login.bank.example
(i.e. it would the responsibility of login.bank.example
to verify the embedding domain [via preregistration and/or user consent] before sending it any sensitive information).
In our world as an IDP, while any site can embed our authorize
endpoint (with prompt=none
), even if the user is logged in (and 1p cookies for that session are available in the iframe), authentication artifacts will only be accessible to the relying party when the iframe has been redirected back to the provided redirect_uri, which needs to be the same origin as the embedding site and if that redirect_uri is registered ahead of time, and the user has provided consent for that relying party (or an admin has consented for them).
In the POC, it looks like the attacking site is embedding a javascript file for the given embedded domain that has been granted storage access, and then console.logging the incoming cookies (seemingly without any verification of the parent domain), correct?
My perspective is that if you are a website that can be embedded, it is your responsibility to verify who is embedding you before transmitting any sensitive information, either via only allowing certain ancestors via CSP (which isn't always practical) or by explicitly verifying the embedding origin (e.g. inspecting referrer headers and/or only returning artifacts to trusted origins via redirects).
(1), where cross-origin subframes can't take advantage of the storage access given to embedded origin from the top frame.
Could you provide a more specific example of the origins/sites that are interacting in this way in your use case?
The reason I'm asking is that allowing this results is arguably the most problematic behavior from a security perspective. Understanding why a frame that's cross-site to both the top-level site and the origin which received storage access needs to send credentialed requests to the grantee is important to figure out the best solution here.
Note that the summary in the text above is a bit of a mental shortcut, for which I apologize. The actual proposal in the doc linked above talks about using Permissions Policy with a default of 'self'
where storage access could be delegated to cross-origin frames by the top-level site if needed.
Can you please clarify how you envision
clickthemonkey.onlinestore.example
learning the user is logged intologin.bank.example
in this example?
clickthemonkey.onlinestore.example
can observe when requests carry cookies based on behavior of endpoints in the target origin that are visible cross-origin. This is briefly covered under the note about preconditions in the Summary of problems with the requestStorageAccess design and current implementations section of the doc above, but it's useful to elaborate.
There are multiple ways in which applications reveal whether a request is made with cookies:
/profile
redirects to a login page for uncredentialed requests.
/api/exportdata
results in a {}
response to an uncredentialed request, but returns a lot of data for an authenticated request.
These are just the basic, fairly general patterns which reveal if a user was logged in. There are others, e.g. load timings of any responses that return a Vary: Cookie
header will also reveal when a request starts carrying cookies (due to the necessity to load the resource from the network instead of the cache).
In the POC, it looks like the attacking site is embedding a javascript file for the given embedded domain that has been granted storage access, and then console.logging the incoming cookies (seemingly without any verification of the parent domain), correct?
Yes, this just a debugging feature in the PoC to show which cookies were present, and is not what a real application would do. The actual patterns that reveal whether a request was made with cookies are the ones listed above.
My perspective is that if you are a website that can be embedded, it is your responsibility to verify who is embedding you before transmitting any sensitive information, either via only allowing certain ancestors via CSP (which isn't always practical).
This is unfortunately too optimistic of an assumption in this case, which we can't depend on.
First, it's important to remember that here we're talking about login.bank.example
which is not meant to be embeddable, it just happens to be same-site with docs.bank.example
which received storage access. Second, login.bank.example
is safe by default against cross-site information leaks in browsers which disable third-party cookies or which default to SameSite=Lax
cookies. Only when an unrelated sibling subdomain (docs.bank.example
) receives storage access, does login.bank.example
get exposed to attacks because unrelated third-parties can now start sending arbitrary credentialed requests to it in the current model. This is the current problematic behavior of the Storage Access API which this proposal aims to address.
Could you provide a more specific example of the origins/sites that are interacting in this way in your use case?
The example given by @iambmelt is the key one we're concerned about: a top-level application (e.g. Teams) which needs to embed our IDP for its own authentication, and then also embeds cross-origin iframes (i.e. Teams addins) which we also want to be able to get SSO with the same user identity that is signed into the top-level app (without user interaction, whenever possible).
I agree with the analysis by @arturjanc in the linked doc. Linking to the old issue where per-frame vs per-page: #3.
Could you provide a more specific example of the origins/sites that are interacting in this way in your use case?
The example given by @iambmelt is the key one we're concerned about: a top-level application (e.g. Teams) which needs to embed our IDP for its own authentication, and then also embeds cross-origin iframes (i.e. Teams addins) which we also want to be able to get SSO with the same user identity that is signed into the top-level app (without user interaction, whenever possible).
One alternative here is to move the user activation check to immediately before the "grant" logic (determine the storage access policy). This would allow activation-less checks of the existing map, but not activation-less permission promts or browser-specific autogrant checks.
I left some inline comments directly on the document. Overall I tend to agree with the observations it makes, though I'm a little wary that requiring CORS will end up moving the needle much.
To the point that @johnwilander raised, it does not seem inconceivable to me to perhaps not prompt again for a given site, but do require each origin to independently call rSA. So while the end user prompt's scope is site, the scope of impact is the origin that made the call. I think that would get you most of the security benefits. In the specification we'd only have to define the latter as the end user prompt's scope is very much up to the user agent. (This might be better discussed in #39 which already goes into some of the issues we might run into if we go down that path.)
I've written up some details about "do not prompt again for a given site, but do require each origin to independently call rSA" in #122, essentially it means walking back from the per-page model but I think it's worth it for several reasons listed in that issue.
I'll go ahead and claim that we resolved the overall concern here through #141, thanks for the discussion everyone and especially @arturjanc for discovering this issue!
Thanks for all the work on resolving this and switching to a per-frame model in https://github.com/privacycg/storage-access/issues/122, @johannhof @cfredric.
IMO the change strikes the right balance and is enough to address the concerns outlined above (and avoids much of the complexity we'd have to introduce to achieve the same security properties in a per-page model).
As part of a review of the Storage Access API design, @johannhof and I have identified concerns of cross-site information leakage that reduce the security benefit of third-party cookie restrictions. We'd like to suggest improvements to the API’s security model that will mitigate and ideally resolve these concerns.
A brief summary of the issues:
sandbox
frames. Untrusted content embedded by the top-level site in a sandboxed iframe also receives the ability to make credentialed requests to the grantee.SameSite=Lax
orSameSite=Strict
to cross-site requests.We put together a document that describes this in more detail: https://docs.google.com/document/d/1AsrETl-7XvnZNbG81Zy9BcZfKbqACQYBSrjM3VsIpjY/edit#
The document includes three proposals to improve various parts of the security model. In a nutshell, we'd like to:
SameSite=None
.Our expectation is that (1) and (3) above should have relatively little impact on existing uses of
requestStorageAccess
, while the CORS requirement may require developers making requests to the embeddee from the context of their 1P embedder to refactor their code and enable CORS for affected resources.For context, our review was done in the context of the recent
requestStorageAccessForSite
proposal and the mitigations that we are proposing will address some important concerns listed in its Privacy and Security Considerations. However, we think that these issues should be addressed regardless of consensus onrequestStorageAccessForSite
.We'd like to reach consensus about these changes across browser vendors soon, to prevent having to make backwards-incompatible changes after the API gains more adoption.
/cc @annevk @johnwilander