I agree we should continue to explore service workers — but it does not seem that using them is a best current practice — and on that basis and assuming that is correct, I think the SW approach should be dropped from the document.
On Mon, Aug 28, 2023 at 8:31 AM Yannick Majoros <yann...@valuya.be> wrote: > I think we should discuss facts and demonstrations rather than show and > call to authority. I really want a constructive discussion on this. I'm > perfectly fine with service workers being seen as an unfit solution, if > it's backed by facts and proofs. We've not reached that point. > > Le lun. 28 août 2023 à 15:31, Jim Manico <j...@manicode.com> a écrit : > >> I think, by far, Philippe’s perspective on web security and the threat >> modeling of BFF vs SPA based implicit flows is accurate and astute. >> >> His perspective should be the driving force for any standard in this area. >> >> I also think it’s dangerous misinformation to claim that BFF has no >> security benefits. >> >> Thanks all, >> -- >> Jim Manico >> @Manicode >> Secure Coding Education >> >> On Aug 28, 2023, at 8:15 AM, Jim Manico <j...@manicode.com> wrote: >> >> *applause* >> >> Sucks you need to explain yourself several times but this is very helpful >> for the community. >> >> On Aug 28, 2023, at 7:52 AM, Philippe De Ryck < >> phili...@pragmaticwebsecurity.com> wrote: >> >> Responses inline. >> >> Still, there is some initial incorrect point that makes the rest of the >> discussion complicated, and partly wrong. >> >> >> I believe the key to make the discussion less complicated is to >> acknowledge that there are two separate issues: >> >> 1. An attacker can potentially obtain tokens from the legitimate >> application >> 2. An attacker can obtain a set of tokens from the AS directly, >> completely independent of any application behavior >> >> Given that the goal is to prevent an attacker from obtaining tokens, >> scenario 1 becomes irrelevant when scenario 2 is a possibility. It would be >> really helpful to analyze the SW approach with this in mind. I’ll add >> comments inline to highlight why this matters. >> >> >> Specifically, §6.4.2.1 says this: *The service worker MUST NOT transmit >> tokens, authorization codes or PKCE code verifier to the frontend >> application.* >> >> Wording should be refined, but the idea is that the service worker is >> to actually restrict authorization codes from even reaching the frontend. >> Of course, easier said than done, but that part happens to be quite easy to >> implement. >> >> >> This is related to both scenarios. If the SW is running, you can indeed >> hide tokens from the main browsing context, which helps to support scenario >> 1. For scenario 2, you need the guarantee that the SW will intercept *all new >> flows*, otherwise the attacker can run a silent flow. *As long as the >> SW is running* in the main context, I would assume that the attacker can >> indeed not reach the authorization endpoint directly. >> >> The key part above is “as long as the SW is running”. An attacker with >> the ability to run malicious JS can *unregister* the SW that prevents >> the attacker from reaching the authorization endpoint. >> >> I have raised this issue before, and the response back then was that the >> SW is only actually removed after the browsing context reloads, which is >> true. So from the main context, the attacker cannot launch the attack. >> However, when the attacker instantiates a new browsing context (i.e., an >> iframe), the unregistered SW is no longer present, and is thereby not able >> to restrict access to the authorization endpoint. >> >> I address this concern in the talk I have referenced before. This link >> with the time code included ( >> https://youtu.be/OpFN6gmct8c?feature=shared&t=1973) points you to the >> exact demo scenario, where I illustrate how an unregistered SW cannot >> prevent access to an endpoint in an iframe. Admittedly, I have not >> implemented a full OAuth client as a SW, but the minimal PoC you see here >> suffices to illustrate the ineffectiveness of this approach. >> >> With this information, the attack scenario becomes the following: >> >> 1. The attacker unregisters the SW in the main browsing context, >> preventing it from being used in any new browsing context >> 2. The attacker injects a new iframe and points it to the >> authorization endpoint >> 3. The AS responds with a redirect with the authorization code >> 4. The attacker detects the redirect, copies the authorization code, >> and aborts the page from loading (so that the authorization code is never >> exchanged or the SW is never reloaded) >> 5. The attacker extracts the authorization code and exchanges it for >> tokens >> >> >> >> TL;DR: a SW is not a security mechanism, and the browser cannot guarantee >> that a SW permanently prevents requests to a certain endpoint. >> >> >> This has further impact on much of the other statements: >> *> The main problem with a browser-only client is that the attacker with >> control over the client has the ability to run a silent Authorization Code >> flow, which provides them with an independent set of tokens* >> [...] >> *> **The security differences between a BFF and a browser-only app are >> not about token storage, but about the attacker being able to run a new >> flow to obtain tokens.* >> [...] >> *> Again, the security benefits of a BFF are not about stoken storage. >> Even if you find the perfect storage solution for non-extractable tokens in >> the browser, an attacker still controls the client application and can >> simply request a new set of tokens. * >> >> Truth is: no, you can't start a new authentication flow and get the >> authorization code back in the main thread. I'm talking about the >> redirection scenario, which I'm the most familiar with, but it would >> probably apply to the "message" one as well (which is new to me and seems >> to be ashtoningly legit due to vague "for example" wording in the OAuth2 >> spec :-) ). >> >> >> The attack scenario above does not run the redirect scenario in the main >> browsing context, but in an iframe. Opening an iframe instantiates a new >> nested browsing context, where unregistered SWs are not available. >> >> >> The service worker, according to >> https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/fetch_event#description >> , just intercepts the authorization code, gets a token, and never sends >> it back to the main code. >> >> >> This point is not relevant, since your SW is no longer active when the >> attacker’s authorization code is being returned. >> >> >> But don't trust me on my words: what about demonstrating our claims with >> actual code, and as such create a shorter, simpler, but more constructive >> discussion? >> >> >> I don’t understand where this remark comes from. I have already >> demonstrated back in January that this approach is not effective, and have >> referred to the recording of this presentation numerous times. I stand by >> my demonstration of the ineffectiveness of SW and encourage you to test >> this out yourself. It is as simple as setting up your SW, unregistering it, >> and running an authorization code flow in an iframe. You’ll see that the >> request goes through to the AS, and that your SW is no longer able to stop >> it. >> >> >> The demonstration in its current form would not lead to a successful >> compromise of a good implementation of access tokens handled by a service >> worker. >> >> >> Once again, I refer back to the start of my mail: *it is not about >> protecting existing tokens (scenario 1)**, *it is all about preventing >> the attacker from running a new flow (Scenario 2). >> >> >> I understand that all of this is quite inconvenient, especially if one is >> heavily invested in running browser-only OAuth clients. Unfortunately, it >> is the nature of web-based applications, and doing so requires a complete >> picture of the security implications. That’s exactly what we are working on >> with the specification. >> >> >> Kind regards >> >> Philippe >> >> >> — >> *Pragmatic Web Security* >> *Security for developers* >> https://pragmaticwebsecurity.com/ >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > -- > Yannick Majoros > Valuya sprl > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
