Re: [OAUTH-WG] WGLC for Browser-based Apps

[Philippe De Ryck <[e-mail]>]

Hi Dick,

The solutions you list here focus on using a service worker to intercept an outgoing call to a resource server. During interception, the service worker attaches the access token. This pattern is mainly used to avoid inserting access token logic into the application code. The SW attaches the access token, and if it has a refresh token, it can even run the RT flow to get a new access token.

Note that the SW is used for convenience here, not for security. The Browser-Based Apps draft recently added a SW pattern as a security mechanism (section 6.4.2). The idea is that the SW not only augments calls to the RS, but also handles the communication with the authorization server. 

Based on my understanding, this pattern was specifically added to address an attack scenario I have described a while ago on this mailing list (and also demonstrate in the video linked in my previous mail). In this scenario, the attacker has the ability to run malicious JS code in the application’s origin. The attacker uses that ability to run a silent Authorization Code flow in an iframe, extracts the code, and exchanges it for a new set of tokens. 

The SW pattern in the spec aims to prevent the application from calling the AS directly, since all calls would be intercepted by the SW. This approach is ineffective, since an attacker can always unregister an existing service worker. The spec states that an unregistered worker remains active until the browsing context reloads (after which it would re-register the worker before the attacker’s code runs). However, after unregistering a worker, new contexts will no longer use this worker. As demonstrated in the video I linked to before, an attacker can unregister a worker and then run a flow in a frame without involving the worker. 

In essence, it boils down to Brock’s statement of “a false sense of security”. While someone may view this as sufficiently secure for their specific use cases, I really object to having this as one of the “recommended approaches” in an RFC.

Hope this helps

Philippe


> On 11 Aug 2023, at 02:56, Dick Hardt <[e-mail]> wrote:
> 
> 
> Philippe: would you expand on your comment:
> 
> On Wed, Aug 9, 2023 at 11:51 PM Philippe De Ryck <[e-mail] <mailto:[e-mail]>> wrote:
> - Remove unproven and overly complicated solutions (i.e., the service worker approach)
> 
> A quick Google on oauth service workers returned a number of articles and descriptions of using service workers:
> 
> https://github.com/ForgeRock/appAuthHelper/blob/master/service_workers.md
> 
> https://gaurav-techgeek.medium.com/re-architecting-authentication-with-service-workers-ff8fbbbfbdeb
> 
> https://itnext.io/using-service-worker-as-an-auth-relay-5abc402878dd
> 
> https://about.grabyo.com/service-workers-jwt-tokens/
> 
> 
> 
> On Wed, Aug 9, 2023 at 11:51 PM Philippe De Ryck <[e-mail] <mailto:[e-mail]>> wrote:
>> In my opinion, this document is not ready to be published as an RFC. 
>> 
>> In fact, I will be at the OAuth Security Workshop in two weeks to discuss exactly this (See "The insecurity of OAuth 2.0 in frontends" here: https://oauth.secworkshop.events/osw2023/agenda-thursday). My hope is that my presentation can spark the necessary discussion to identify a path forward to make the RFC useful for practitioners building browser-based apps.
>> 
>> I don't have the resources available to write a lengthy email detailing my objections. I just want to point out that I've raised these points on the mailing list in the past, and there have been a couple of threads on this very list suggesting how to move this document forward (e.g., identify concrete threat models). I've also given a talk at NDC Security earlier this year (https://www.youtube.com/watch?v=OpFN6gmct8c) about how the security mechanisms proposed in this document fall short. This video has been posted to this list before as well.
>> 
>> Here are a couple of suggestions that I believe would improve this document:
>> 
>> - Clearly identify the danger of malicious JS (exfiltrating existing tokens is only one threat, and the most trivial one at that)
>> - State the baseline achievable level of security in light of existing XSS vulnerabilities (i.e., session riding, where the attacker controls the frontend)
>> - Identify different desired levels of security for a client application (e.g., a "public recipe app" vs "eHealth"). Existing work can help, such as the OWASP ASVS levels (https://github.com/OWASP/ASVS/blob/master/4.0/en/0x03-Using-ASVS.md)
>> - Define which levels of security certain mechanisms can offer (e.g., RTR for level 1, TMI-BFF for level 2, BFF for level 3)
>> - Remove unproven and overly complicated solutions (i.e., the service worker approach)
>> 
>> As stated before, I'll be at OSW in London in 2 weeks and would be happy to discuss this further.
>> 
>> Kind regards
>> 
>> Philippe
>> 
>> —
>> Pragmatic Web Security
>> Security for developers
>> https://pragmaticwebsecurity.com <https://pragmaticwebsecurity.com/>
>> 
>>> On 30 Jul 2023, at 17:46, Rifaat Shekh-Yusef <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> All,
>>> 
>>> This is a WG Last Call for the Browser-based Apps draft.
>>> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-14.html
>>> 
>>> Please, review this document and reply on the mailing list if you have any comments or concerns, by August 11th.
>>> 
>>> Regards,
>>>  Rifaat & Hannes
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth