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

[Aaron Parecki]

Thanks Rifaat,

The editors have just published draft -18 addressing the comments from
Justin Richer's and Andy Barlow's reviews.

https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-18.html

Aaron


On Wed, May 1, 2024 at 5:51 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is a *WG Last Call* for the *Browser-Based Apps* draft.
> https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/
>
> Please, review this document and reply on the mailing list if you have any
> comments or concerns, by *May 15. *
> If you reviewed the document and you do not have any comments or concerns,
> it would be great if you can reply to this email indicating that.
>
> Regards,
>   Rifaat & Hannes
> ___
> 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

[OAUTH-WG] WGLC for Browser-Based Apps

[Rifaat Shekh-Yusef]

All,

This is a *WG Last Call* for the *Browser-Based Apps* draft.
https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/

Please, review this document and reply on the mailing list if you have any
comments or concerns, by *May 15. *
If you reviewed the document and you do not have any comments or concerns,
it would be great if you can reply to this email indicating that.

Regards,
  Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[David Waite]

On Aug 28, 2023, at 9:51 AM, Yannick Majoros  wrote:

> 
> You really have a point about refresh tokens here, but they are a separate, 
> real issue. Refresh tokens should be avoided whenever you can do without. Any 
> pattern that can keep them safe is on the same level, but their safety is 
> always relative. They make any attack worse, indeed (and that is also true 
> for BFFs in some scenario's). This isn't specifically about BFFs.

Commenting on this one in isolation - token policy in general affects security, 
but refresh tokens are orthogonal to that. From a (compliant) client 
perspective, a refresh token thats good for an hour is not different 
security-wise than an access token-only configuration where the access token is 
good for an hour. A refresh token that never expires (to generate an infinite 
number of access tokens) is not fundamentally different from an access token 
that never expires. 

If you are not doing sender constraints that prevent exfiltration, refreshing 
may give more opportunities for exfiltration. Methods that do provider sender 
constraints however typically define how to do so for both types of tokens.

This has been a recurring challenge in the past, where some policy (such as 
certain implementations and how they react to the offline_access scope from 
OIDC) has steered the discussion to comparing particular archetypical policies 
of AS deployments rather than the technology itself. This is problematic not 
just for complicating the discussion at play, but because we don’t have a 
consistent view of what these archetypes might be across the industry.

-DW___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Yannick Majoros]

Hey Aaron,

*> There is a huge difference between being able to access resources
through the user's browser while it's online vs being able to access
resources without the browser's involvement.*

While there are operational differences, the end result is compromission of
the exposed resources for both cases. Once other mitigations are in place,
the damage is typically the same. There is a real need to document the
differences, but an application using either solution isn't more secure.

*> Additionally, in many cases, the BFF exposes only a subset of actions of
the resource server to the client. Or put another way, sometimes access
tokens can access more resources than just the ones the BFF can access.
This obviously doesn't apply to everyone, but it's still common enough to
be significant. This is briefly mentioned in the security considerations
already: 
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-reducing-the-impact-of-toke
*

If only a subset of actions need to be exposed to the client, the actual
issue is that the access token scope and audience aren't defined well
enough.
A BFF or even a simple proxy can filter the amount of exposed services, but
this is a distinct problematic and is independent from the token storage
solution choice.
Using a BFF for token storage also introduces the opposite problem: cookies
might be sent for resources they weren't intended for.
All of these are basic misconfiguration issues, but reducing the attack
surface by changing which services are potentially exposed isn't an
intrinsic advantage of the BFF as application client.

Le lun. 28 août 2023 à 17:56, Aaron Parecki  a écrit :

> > An XSS compromise would allow an attacker to call the resource server
> from the browser context through the BFF, which would lead to the same
> catastrophous result as doing it from another context.
>
> There is a huge difference between being able to access resources through
> the user's browser while it's online vs being able to access resources
> without the browser's involvement.
>
> Additionally, in many cases, the BFF exposes only a subset of actions of
> the resource server to the client. Or put another way, sometimes access
> tokens can access more resources than just the ones the BFF can access.
> This obviously doesn't apply to everyone, but it's still common enough to
> be significant. This is briefly mentioned in the security considerations
> already:
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-reducing-the-impact-of-toke
>
> Aaron
>
>
> On Mon, Aug 28, 2023 at 8:51 AM Yannick Majoros  wrote:
>
>> An XSS compromise would allow an attacker to call the resource server
>> from the browser context through the BFF, which would lead to the same
>> catastrophous result as doing it from another context.
>>
>> Cookies are sent automatically, potentially to resources which shouldn't
>> get it. Same threat level as a token that is too broadly scoped, really.
>>
>> You really have a point about refresh tokens here, but they are a
>> separate, real issue. Refresh tokens should be avoided whenever you can do
>> without. Any pattern that can keep them safe is on the same level, but
>> their safety is always relative. They make any attack worse, indeed (and
>> that is also true for BFFs in some scenario's). This isn't specifically
>> about BFFs.
>>
>> Le lun. 28 août 2023 à 17:38, Aaron Parecki  a écrit :
>>
>>> > BFFs are not any safer, XSS or any successful malicious javascript
>>> execution has the same end effect
>>>
>>> As described in the draft as well as in this email thread, this is
>>> incorrect.
>>>
>>> An XSS compromise of the BFF architecture results in the attacker being
>>> able to make requests to the BFF with the legitimate user's cookie, as long
>>> as the user's browser is active. An XSS compromise of a SPA results in the
>>> attacker being able to obtain access tokens (and possible refresh tokens),
>>> which results in the attacker being able to access the resource server
>>> directly, outside of the context of the user's browser, which may allow the
>>> attacker to access far more data than the browser app alone, and for a
>>> longer period of time.
>>>
>>> The difference between these threats is extremely significant.
>>>
>>> Aaron
>>>
>>> On Mon, Aug 28, 2023 at 8:14 AM Yannick Majoros 
>>> wrote:
>>>
 My last comment was rather ironic: user-facing applications are
 dangerous (security is hard, which I say nothing with), and that is true
 for any scheme.. BFFs are not any safer, XSS or any successful malicious
 javascript execution has the same end effect (=game over, complete
 compromise of authenticated calls), and there was still no
 factual demonstration of multiple levels of security here. See my detailed
 explanations.

 Le lun. 28 août 2023 à 11:35, 

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

[Yannick Majoros]

Hello Philippe,

Thanks for the new details. This new information let me indeed reproduce
the exploit, which seems different from the January one, that I wasn't
able to successfully reproduce against my current implementation.

*> For someone who is more than eager to demand that we prove them wrong by
showing a fully-detailed implementation and exploit, you seem to be very
unwilling to spend any of your own time trying to understand the arguments
that have been provided. The only arguments you have provided so far boil
down to “trust me, you’re wrong”, even when faced with a clear
demonstration. Furthermore, your description of why the SW should work are
based on a severe lack of understanding of how browser-based security works*
.
*> The process of dropping a proposal that you do not use in practice, and
then demanding that we keep convincing you over and over again that it is a
severely flawed proposal shows an enormous lack of respect. I have shown
you the courtesy of trying to convince you, but since it’s clear that you
are unwilling to even critically inspect your own idea, it’s time to wrap
this up. *

Could we return to a more objective and constructive discussion? I've
invested a significant amount of my own time into your emails, and even
more into the subject itself. My time holds the same value as yours, and I
believe it's essential to treat each other's time with respect. My primary
goal is centered around developing secure web applications and documenting
various approaches. I can be wrong, I can miss details, but it remains
important for this document to be based on proven facts and to demonstrate
any claims made. Criticisms like 'a lack of understanding of browser-based
security' are counterproductive and do not contribute to productive
conversations. I did not drop a subject or even call it a best practice: I
started documenting an alternative approach and now acknowledge its current
imperfections, as was recently highlighted by you, though I wasn't able to
reproduce any exploit from the previous discussions (and this document has
been consistently reviewed over the course of a year, without receiving
substantial public feedback). In an attempt to shed light on specifics and
to challenge the approach effectively, I proposed creating a test
implementation within this very email thread. Thus, statements made here,
such as a lack of  personal investment to 'understand your arguments,' are
not accurate. A proof of concept serves as one way towards understanding. I
still think it would be useful, though implementation was initially
regarded as out of scope, as the unregistration problem seems fixable, for
example. I've also noticed instances where I had to reiterate certain
points without seemingly being acknowledged. To conclude this digression, I
apologize if any of my statements or inquiries came across as
disrespectful, as that was never my intention. I anticipate and hope for an
equitable and inclusive dialogue moving forward.

Though I don't use the pattern personally anymore (all my clients switched
to local storage and got rid of refresh tokens), I did for some time and I
still think it has value. When doing some research for this thread, I
noticed it's being incrementally used (just one example here:
https://github.com/infinum/auth-worker), so there is definitely some
interest. I do think further research is needed in its current state.

Best regards,

Yannick

Le lun. 28 août 2023 à 18:40, Philippe De Ryck <
phili...@pragmaticwebsecurity.com> a écrit :

>
>
> Again, there is something fundamentally misunderstood here: Philippe's
> exploit will not work with a correctly implemented service worker. Also not
> in an iframe. Also not if you unregister it and you start a new iframe.
>
>
> For someone who is more than eager to demand that we prove them wrong by
> showing a fully-detailed implementation and exploit, you seem to be very
> unwilling to spend any of your own time trying to understand the arguments
> that have been provided. The only arguments you have provided so far boil
> down to “trust me, you’re wrong”, even when faced with a clear
> demonstration. Furthermore, your description of why the SW should work are
> based on a severe lack of understanding of how browser-based security
> works.
>
> I cannot spend any more time on discussing a flawed and theoretical
> solution, of which you have yourself admitted that you do not use it in
> practice. However, in the interest of educational purposes, I am willing to
> use this last message in this discussion to outline the flaws in this
> solution. I trust you find this approach pragmatic enough.
>
>
> There is no "need to explain yourself several times" and nobody has
> "already demonstrated back in January that this approach is not effective",
> because a correctly implemented service worker can effectively prevent this
> attack. The attacker cannot "run a new flow" and automate getting a token
> if the service worker 

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

[Philippe De Ryck]

> Again, there is something fundamentally misunderstood here: Philippe's 
> exploit will not work with a correctly implemented service worker. Also not 
> in an iframe. Also not if you unregister it and you start a new iframe.

For someone who is more than eager to demand that we prove them wrong by 
showing a fully-detailed implementation and exploit, you seem to be very 
unwilling to spend any of your own time trying to understand the arguments that 
have been provided. The only arguments you have provided so far boil down to 
“trust me, you’re wrong”, even when faced with a clear demonstration. 
Furthermore, your description of why the SW should work are based on a severe 
lack of understanding of how browser-based security works. 

I cannot spend any more time on discussing a flawed and theoretical solution, 
of which you have yourself admitted that you do not use it in practice. 
However, in the interest of educational purposes, I am willing to use this last 
message in this discussion to outline the flaws in this solution. I trust you 
find this approach pragmatic enough.


> There is no "need to explain yourself several times" and nobody has "already 
> demonstrated back in January that this approach is not effective", because a 
> correctly implemented service worker can effectively prevent this attack. The 
> attacker cannot "run a new flow" and automate getting a token if the service 
> worker implementation follows the specified guidelines:
> §6.4.2.1
> * The application MUST register the Service Worker before running any 
> code interacting with the user.
> 
> The redirect URI is registered within your application. If you allow any 
> redirect_uri to be a silent refresh flow (typically in an iframe), you *must* 
> make it synchronously register the service worker as the first action on the 
> page, just as any other part of the application (and stopping that is a whole 
> different attack than XSS). The single-threaded nature of javascript and 
> synchronous loading of scripts will not let any secret leak before it has 
> been loaded (and as an additional counter-measure for half-manual access code 
> leaks, you could add some restriction to remove auth codes from pages before 
> it is loaded).

This paragraph clearly illustrates that you still do not grasp the attack 
scenario, which kind of undermines the “trust me bro” arguments. Let me walk 
you through the scenario in a chronological order. And to be 100% clear about 
why things are the way they are, I added source references in red.

The application on example.com loads in the main browsing context (referred to 
as APP from now on) and registers a SW [Based on your proposal in the spec and 
the image in your GH demo repo [1]]
The SW runs the authorization code flow, obtains tokens, and does not expose 
anything to the APP  [Based on your proposal in the spec and the image in your 
GH demo repo [1]]
The APP can make API calls, which are intercepted the SW and augmented with 
tokens before they go out  [Based on your proposal in the spec and the image in 
your GH demo repo [1]]
The attacker triggers the ability to execute malicious JS (e.g., XSS)
The malicious JS unregisters the SW. Because of this unregistration, the SW 
will not be used for a new browsing context (e.g., an iframe). The SW will 
however be re-registered when there’s a page load from example.com 
, which does not happen at this point. [Based on the 
considerations in the spec: 
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#section-6.4.2.2]
The attacker sets up a piece of malicious JS code (ATTACK) that runs every 1ms 
(we’ll come back to this)
The attacker creates a new iframe (FRAME), inserts it into the page, and points 
the FRAME to the authorization endpoint of the AS to run a silent authorization 
code flow. The SW is not present to intercept this call, so it will reach the 
AS. [The fact that this step is possible is demonstrated in the recording from 
January (https://youtu.be/OpFN6gmct8c?feature=shared=1973), albeit in a more 
rudimentary fashion]
The AS receives a request with cookies, and issues an authorization code in 
response. This code is delivered through a redirect, so the response carries a 
Location header with value https://example.com/callback?code=ABC123 [As defined 
by the OAuth specs. If the response_mode=web_message value is supported, no 
redirect happens and the attacker receives a message containing the code, as 
demonstrated in the recording from January.]
Because of the Location header, the browser will try to load the callback from 
APP in the FRAME. However, the ATTACK code will prevent this, as described 
below. [Demonstrated at OSW2023, code snippet included below] 
The ATTACK code is monitoring the URL of the iframe, which throws an error for 
cross-origin frames, but works just fine once the FRAME becomes same-origin, 
hence the aggressive timer. 
The moment the URL becomes 

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

[Yannick Majoros]

That's outside of the responsibility of a BFF. That's what web application
firewalls are doing, with disputable results. They are another tool that
can be used, for any of the described flows btw.

Le lun. 28 août 2023, 18:14, Dick Hardt  a écrit :

> While a breach of a BFF may be as catastrophic as an exfiltration of an
> access token, the BFF may also be more secure against a breach.
>
> For example, a BFF could detect a possible compromise by the API usage
> pattern becoming unusual to the app, that a RS is not able to detect as the
> general usage patterns are less defined, and the BFF could then stop
> processing requests.
>
>
>
>
> On Mon, Aug 28, 2023 at 8:58 AM Aaron Parecki  40parecki@dmarc.ietf.org> wrote:
>
>> > An XSS compromise would allow an attacker to call the resource server
>> from the browser context through the BFF, which would lead to the same
>> catastrophous result as doing it from another context.
>>
>> There is a huge difference between being able to access resources through
>> the user's browser while it's online vs being able to access resources
>> without the browser's involvement.
>>
>> Additionally, in many cases, the BFF exposes only a subset of actions of
>> the resource server to the client. Or put another way, sometimes access
>> tokens can access more resources than just the ones the BFF can access.
>> This obviously doesn't apply to everyone, but it's still common enough to
>> be significant. This is briefly mentioned in the security considerations
>> already:
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-reducing-the-impact-of-toke
>>
>> Aaron
>>
>>
>> On Mon, Aug 28, 2023 at 8:51 AM Yannick Majoros 
>> wrote:
>>
>>> An XSS compromise would allow an attacker to call the resource server
>>> from the browser context through the BFF, which would lead to the same
>>> catastrophous result as doing it from another context.
>>>
>>> Cookies are sent automatically, potentially to resources which shouldn't
>>> get it. Same threat level as a token that is too broadly scoped, really.
>>>
>>> You really have a point about refresh tokens here, but they are a
>>> separate, real issue. Refresh tokens should be avoided whenever you can do
>>> without. Any pattern that can keep them safe is on the same level, but
>>> their safety is always relative. They make any attack worse, indeed (and
>>> that is also true for BFFs in some scenario's). This isn't specifically
>>> about BFFs.
>>>
>>> Le lun. 28 août 2023 à 17:38, Aaron Parecki  a
>>> écrit :
>>>
 > BFFs are not any safer, XSS or any successful malicious javascript
 execution has the same end effect

 As described in the draft as well as in this email thread, this is
 incorrect.

 An XSS compromise of the BFF architecture results in the attacker being
 able to make requests to the BFF with the legitimate user's cookie, as long
 as the user's browser is active. An XSS compromise of a SPA results in the
 attacker being able to obtain access tokens (and possible refresh tokens),
 which results in the attacker being able to access the resource server
 directly, outside of the context of the user's browser, which may allow the
 attacker to access far more data than the browser app alone, and for a
 longer period of time.

 The difference between these threats is extremely significant.

 Aaron

 On Mon, Aug 28, 2023 at 8:14 AM Yannick Majoros 
 wrote:

> My last comment was rather ironic: user-facing applications are
> dangerous (security is hard, which I say nothing with), and that is true
> for any scheme.. BFFs are not any safer, XSS or any successful malicious
> javascript execution has the same end effect (=game over, complete
> compromise of authenticated calls), and there was still no
> factual demonstration of multiple levels of security here. See my detailed
> explanations.
>
> Le lun. 28 août 2023 à 11:35, Steinar Noem  a
> écrit :
>
>> I think this is a great discussion, and it seems to me that Yannicks
>> last comment is basically what Phillippe is trying to point out..
>> I just wanted to remind the authors about a couple of things that we
>> briefly discussed during OSW in London.
>>
>> Although it might not be directly relevant for this discussion I do
>> think that it might be a good idea that the spec mentions that:
>>
>>- The level of security you require for any client is often a
>>reflection of the sensitivity of the information that the API 
>> exposes. You
>>will have different requirements for confidential information than 
>> for open
>>data. An example of a similar recommendation can be found in the HTTP
>>Semantics specification: https://httpwg.org/specs/rfc9110.html#GET
>>
>>- In my domain it is most often the owner of the API (the data
>>

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

[Dick Hardt]

While a breach of a BFF may be as catastrophic as an exfiltration of an
access token, the BFF may also be more secure against a breach.

For example, a BFF could detect a possible compromise by the API usage
pattern becoming unusual to the app, that a RS is not able to detect as the
general usage patterns are less defined, and the BFF could then stop
processing requests.




On Mon, Aug 28, 2023 at 8:58 AM Aaron Parecki  wrote:

> > An XSS compromise would allow an attacker to call the resource server
> from the browser context through the BFF, which would lead to the same
> catastrophous result as doing it from another context.
>
> There is a huge difference between being able to access resources through
> the user's browser while it's online vs being able to access resources
> without the browser's involvement.
>
> Additionally, in many cases, the BFF exposes only a subset of actions of
> the resource server to the client. Or put another way, sometimes access
> tokens can access more resources than just the ones the BFF can access.
> This obviously doesn't apply to everyone, but it's still common enough to
> be significant. This is briefly mentioned in the security considerations
> already:
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-reducing-the-impact-of-toke
>
> Aaron
>
>
> On Mon, Aug 28, 2023 at 8:51 AM Yannick Majoros  wrote:
>
>> An XSS compromise would allow an attacker to call the resource server
>> from the browser context through the BFF, which would lead to the same
>> catastrophous result as doing it from another context.
>>
>> Cookies are sent automatically, potentially to resources which shouldn't
>> get it. Same threat level as a token that is too broadly scoped, really.
>>
>> You really have a point about refresh tokens here, but they are a
>> separate, real issue. Refresh tokens should be avoided whenever you can do
>> without. Any pattern that can keep them safe is on the same level, but
>> their safety is always relative. They make any attack worse, indeed (and
>> that is also true for BFFs in some scenario's). This isn't specifically
>> about BFFs.
>>
>> Le lun. 28 août 2023 à 17:38, Aaron Parecki  a écrit :
>>
>>> > BFFs are not any safer, XSS or any successful malicious javascript
>>> execution has the same end effect
>>>
>>> As described in the draft as well as in this email thread, this is
>>> incorrect.
>>>
>>> An XSS compromise of the BFF architecture results in the attacker being
>>> able to make requests to the BFF with the legitimate user's cookie, as long
>>> as the user's browser is active. An XSS compromise of a SPA results in the
>>> attacker being able to obtain access tokens (and possible refresh tokens),
>>> which results in the attacker being able to access the resource server
>>> directly, outside of the context of the user's browser, which may allow the
>>> attacker to access far more data than the browser app alone, and for a
>>> longer period of time.
>>>
>>> The difference between these threats is extremely significant.
>>>
>>> Aaron
>>>
>>> On Mon, Aug 28, 2023 at 8:14 AM Yannick Majoros 
>>> wrote:
>>>
 My last comment was rather ironic: user-facing applications are
 dangerous (security is hard, which I say nothing with), and that is true
 for any scheme.. BFFs are not any safer, XSS or any successful malicious
 javascript execution has the same end effect (=game over, complete
 compromise of authenticated calls), and there was still no
 factual demonstration of multiple levels of security here. See my detailed
 explanations.

 Le lun. 28 août 2023 à 11:35, Steinar Noem  a écrit :

> I think this is a great discussion, and it seems to me that Yannicks
> last comment is basically what Phillippe is trying to point out..
> I just wanted to remind the authors about a couple of things that we
> briefly discussed during OSW in London.
>
> Although it might not be directly relevant for this discussion I do
> think that it might be a good idea that the spec mentions that:
>
>- The level of security you require for any client is often a
>reflection of the sensitivity of the information that the API exposes. 
> You
>will have different requirements for confidential information than for 
> open
>data. An example of a similar recommendation can be found in the HTTP
>Semantics specification: https://httpwg.org/specs/rfc9110.html#GET
>- In my domain it is most often the owner of the API (the data
>controller) who defines and approves the level of security which it 
> finds
>to fit their responsibilities (e.g. legal obligations) - although in 
> some
>cases it might be both the data provider and the data consumer. 
> Meaning -
>this BCP might be equally important for the API-owner as it is to the
>client developer.
>- I think this discussion shows that 

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

[Dick Hardt]

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  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  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  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=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 

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

[Aaron Parecki]

> An XSS compromise would allow an attacker to call the resource server
from the browser context through the BFF, which would lead to the same
catastrophous result as doing it from another context.

There is a huge difference between being able to access resources through
the user's browser while it's online vs being able to access resources
without the browser's involvement.

Additionally, in many cases, the BFF exposes only a subset of actions of
the resource server to the client. Or put another way, sometimes access
tokens can access more resources than just the ones the BFF can access.
This obviously doesn't apply to everyone, but it's still common enough to
be significant. This is briefly mentioned in the security considerations
already:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-reducing-the-impact-of-toke

Aaron


On Mon, Aug 28, 2023 at 8:51 AM Yannick Majoros  wrote:

> An XSS compromise would allow an attacker to call the resource server from
> the browser context through the BFF, which would lead to the same
> catastrophous result as doing it from another context.
>
> Cookies are sent automatically, potentially to resources which shouldn't
> get it. Same threat level as a token that is too broadly scoped, really.
>
> You really have a point about refresh tokens here, but they are a
> separate, real issue. Refresh tokens should be avoided whenever you can do
> without. Any pattern that can keep them safe is on the same level, but
> their safety is always relative. They make any attack worse, indeed (and
> that is also true for BFFs in some scenario's). This isn't specifically
> about BFFs.
>
> Le lun. 28 août 2023 à 17:38, Aaron Parecki  a écrit :
>
>> > BFFs are not any safer, XSS or any successful malicious javascript
>> execution has the same end effect
>>
>> As described in the draft as well as in this email thread, this is
>> incorrect.
>>
>> An XSS compromise of the BFF architecture results in the attacker being
>> able to make requests to the BFF with the legitimate user's cookie, as long
>> as the user's browser is active. An XSS compromise of a SPA results in the
>> attacker being able to obtain access tokens (and possible refresh tokens),
>> which results in the attacker being able to access the resource server
>> directly, outside of the context of the user's browser, which may allow the
>> attacker to access far more data than the browser app alone, and for a
>> longer period of time.
>>
>> The difference between these threats is extremely significant.
>>
>> Aaron
>>
>> On Mon, Aug 28, 2023 at 8:14 AM Yannick Majoros 
>> wrote:
>>
>>> My last comment was rather ironic: user-facing applications are
>>> dangerous (security is hard, which I say nothing with), and that is true
>>> for any scheme.. BFFs are not any safer, XSS or any successful malicious
>>> javascript execution has the same end effect (=game over, complete
>>> compromise of authenticated calls), and there was still no
>>> factual demonstration of multiple levels of security here. See my detailed
>>> explanations.
>>>
>>> Le lun. 28 août 2023 à 11:35, Steinar Noem  a écrit :
>>>
 I think this is a great discussion, and it seems to me that Yannicks
 last comment is basically what Phillippe is trying to point out..
 I just wanted to remind the authors about a couple of things that we
 briefly discussed during OSW in London.

 Although it might not be directly relevant for this discussion I do
 think that it might be a good idea that the spec mentions that:

- The level of security you require for any client is often a
reflection of the sensitivity of the information that the API exposes. 
 You
will have different requirements for confidential information than for 
 open
data. An example of a similar recommendation can be found in the HTTP
Semantics specification: https://httpwg.org/specs/rfc9110.html#GET
- In my domain it is most often the owner of the API (the data
controller) who defines and approves the level of security which it 
 finds
to fit their responsibilities (e.g. legal obligations) - although in 
 some
cases it might be both the data provider and the data consumer. Meaning 
 -
this BCP might be equally important for the API-owner as it is to the
client developer.
- I think this discussion shows that any mitigation on the browser
side will only raise the bar for the attacker, and can never be a fully
effective countermeasure. I think this point could be even more clearly
stated early in the spec, and that both the API-owner or client owner
should be aware of this risk, and select their appropriate choice of
security measures based on a risk assessment. In some cases their
conclusion might be that a browser based app is not secure enough for
their responsibilities.

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

[Yannick Majoros]

An XSS compromise would allow an attacker to call the resource server from
the browser context through the BFF, which would lead to the same
catastrophous result as doing it from another context.

Cookies are sent automatically, potentially to resources which shouldn't
get it. Same threat level as a token that is too broadly scoped, really.

You really have a point about refresh tokens here, but they are a separate,
real issue. Refresh tokens should be avoided whenever you can do without.
Any pattern that can keep them safe is on the same level, but their safety
is always relative. They make any attack worse, indeed (and that is also
true for BFFs in some scenario's). This isn't specifically about BFFs.

Le lun. 28 août 2023 à 17:38, Aaron Parecki  a écrit :

> > BFFs are not any safer, XSS or any successful malicious javascript
> execution has the same end effect
>
> As described in the draft as well as in this email thread, this is
> incorrect.
>
> An XSS compromise of the BFF architecture results in the attacker being
> able to make requests to the BFF with the legitimate user's cookie, as long
> as the user's browser is active. An XSS compromise of a SPA results in the
> attacker being able to obtain access tokens (and possible refresh tokens),
> which results in the attacker being able to access the resource server
> directly, outside of the context of the user's browser, which may allow the
> attacker to access far more data than the browser app alone, and for a
> longer period of time.
>
> The difference between these threats is extremely significant.
>
> Aaron
>
> On Mon, Aug 28, 2023 at 8:14 AM Yannick Majoros  wrote:
>
>> My last comment was rather ironic: user-facing applications are dangerous
>> (security is hard, which I say nothing with), and that is true for any
>> scheme.. BFFs are not any safer, XSS or any successful malicious javascript
>> execution has the same end effect (=game over, complete compromise of
>> authenticated calls), and there was still no factual demonstration of
>> multiple levels of security here. See my detailed explanations.
>>
>> Le lun. 28 août 2023 à 11:35, Steinar Noem  a écrit :
>>
>>> I think this is a great discussion, and it seems to me that Yannicks
>>> last comment is basically what Phillippe is trying to point out..
>>> I just wanted to remind the authors about a couple of things that we
>>> briefly discussed during OSW in London.
>>>
>>> Although it might not be directly relevant for this discussion I do
>>> think that it might be a good idea that the spec mentions that:
>>>
>>>- The level of security you require for any client is often a
>>>reflection of the sensitivity of the information that the API exposes. 
>>> You
>>>will have different requirements for confidential information than for 
>>> open
>>>data. An example of a similar recommendation can be found in the HTTP
>>>Semantics specification: https://httpwg.org/specs/rfc9110.html#GET
>>>- In my domain it is most often the owner of the API (the data
>>>controller) who defines and approves the level of security which it finds
>>>to fit their responsibilities (e.g. legal obligations) - although in some
>>>cases it might be both the data provider and the data consumer. Meaning -
>>>this BCP might be equally important for the API-owner as it is to the
>>>client developer.
>>>- I think this discussion shows that any mitigation on the browser
>>>side will only raise the bar for the attacker, and can never be a fully
>>>effective countermeasure. I think this point could be even more clearly
>>>stated early in the spec, and that both the API-owner or client owner
>>>should be aware of this risk, and select their appropriate choice of
>>>security measures based on a risk assessment. In some cases their
>>>conclusion might be that a browser based app is not secure enough for
>>>their responsibilities.
>>>
>>>
>>> S
>>>
>>> søn. 27. aug. 2023 kl. 18:41 skrev Yannick Majoros :
>>>
 Yes, but this is true for all flows. Web applications are dangerous.
 Applications handling user input are dangerous too.

 Le dim. 27 août 2023, 17:46, Tom Jones 
 a écrit :

> You can write your code as strong as you wish. You cannot determine if
> the code running in the computer is that code running unaltered. ..tom
>
>
> On Sun, Aug 27, 2023 at 5:25 AM Yannick Majoros 
> wrote:
>
>> Thanks for taking the time to respond and for the constructive
>> feedback.
>>
>> Still, there is some initial incorrect point that makes the rest of
>> the discussion complicated, and partly wrong.
>>
>> 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 

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

[Tom Jones]

Something is deeply flawed about this thread. Consider that the following
quote from Steiner talks about information in the client as though the
client were actually the client is the resource owner. But the resource
owner should view the client as just another attacker. Somewhere the
interest of the data owner should be considered as we know that any
standard creates a race to the bottom, to the cheapest solution that can
claim compliance.

The level of security you require for any client is often a reflection of
the sensitivity of the information that the API exposes.

thx ..Tom (mobile)

On Mon, Aug 28, 2023, 2:36 AM Steinar Noem  wrote:

> I think this is a great discussion, and it seems to me that Yannicks last
> comment is basically what Phillippe is trying to point out..
> I just wanted to remind the authors about a couple of things that we
> briefly discussed during OSW in London.
>
> Although it might not be directly relevant for this discussion I do think
> that it might be a good idea that the spec mentions that:
>
>- The level of security you require for any client is often a
>reflection of the sensitivity of the information that the API exposes. You
>will have different requirements for confidential information than for open
>data. An example of a similar recommendation can be found in the HTTP
>Semantics specification: https://httpwg.org/specs/rfc9110.html#GET
>- In my domain it is most often the owner of the API (the data
>controller) who defines and approves the level of security which it finds
>to fit their responsibilities (e.g. legal obligations) - although in some
>cases it might be both the data provider and the data consumer. Meaning -
>this BCP might be equally important for the API-owner as it is to the
>client developer.
>- I think this discussion shows that any mitigation on the browser
>side will only raise the bar for the attacker, and can never be a fully
>effective countermeasure. I think this point could be even more clearly
>stated early in the spec, and that both the API-owner or client owner
>should be aware of this risk, and select their appropriate choice of
>security measures based on a risk assessment. In some cases their
>conclusion might be that a browser based app is not secure enough for
>their responsibilities.
>
>
> S
>
> søn. 27. aug. 2023 kl. 18:41 skrev Yannick Majoros :
>
>> Yes, but this is true for all flows. Web applications are dangerous.
>> Applications handling user input are dangerous too.
>>
>> Le dim. 27 août 2023, 17:46, Tom Jones  a
>> écrit :
>>
>>> You can write your code as strong as you wish. You cannot determine if
>>> the code running in the computer is that code running unaltered. ..tom
>>>
>>>
>>> On Sun, Aug 27, 2023 at 5:25 AM Yannick Majoros 
>>> wrote:
>>>
 Thanks for taking the time to respond and for the constructive feedback.

 Still, there is some initial incorrect point that makes the rest of the
 discussion complicated, and partly wrong.

 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 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 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.

 But don't trust me on my words: what about demonstrating our claims
 with 

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

[Aaron Parecki]

> BFFs are not any safer, XSS or any successful malicious javascript
execution has the same end effect

As described in the draft as well as in this email thread, this is
incorrect.

An XSS compromise of the BFF architecture results in the attacker being
able to make requests to the BFF with the legitimate user's cookie, as long
as the user's browser is active. An XSS compromise of a SPA results in the
attacker being able to obtain access tokens (and possible refresh tokens),
which results in the attacker being able to access the resource server
directly, outside of the context of the user's browser, which may allow the
attacker to access far more data than the browser app alone, and for a
longer period of time.

The difference between these threats is extremely significant.

Aaron

On Mon, Aug 28, 2023 at 8:14 AM Yannick Majoros  wrote:

> My last comment was rather ironic: user-facing applications are dangerous
> (security is hard, which I say nothing with), and that is true for any
> scheme.. BFFs are not any safer, XSS or any successful malicious javascript
> execution has the same end effect (=game over, complete compromise of
> authenticated calls), and there was still no factual demonstration of
> multiple levels of security here. See my detailed explanations.
>
> Le lun. 28 août 2023 à 11:35, Steinar Noem  a écrit :
>
>> I think this is a great discussion, and it seems to me that Yannicks last
>> comment is basically what Phillippe is trying to point out..
>> I just wanted to remind the authors about a couple of things that we
>> briefly discussed during OSW in London.
>>
>> Although it might not be directly relevant for this discussion I do think
>> that it might be a good idea that the spec mentions that:
>>
>>- The level of security you require for any client is often a
>>reflection of the sensitivity of the information that the API exposes. You
>>will have different requirements for confidential information than for 
>> open
>>data. An example of a similar recommendation can be found in the HTTP
>>Semantics specification: https://httpwg.org/specs/rfc9110.html#GET
>>- In my domain it is most often the owner of the API (the data
>>controller) who defines and approves the level of security which it finds
>>to fit their responsibilities (e.g. legal obligations) - although in some
>>cases it might be both the data provider and the data consumer. Meaning -
>>this BCP might be equally important for the API-owner as it is to the
>>client developer.
>>- I think this discussion shows that any mitigation on the browser
>>side will only raise the bar for the attacker, and can never be a fully
>>effective countermeasure. I think this point could be even more clearly
>>stated early in the spec, and that both the API-owner or client owner
>>should be aware of this risk, and select their appropriate choice of
>>security measures based on a risk assessment. In some cases their
>>conclusion might be that a browser based app is not secure enough for
>>their responsibilities.
>>
>>
>> S
>>
>> søn. 27. aug. 2023 kl. 18:41 skrev Yannick Majoros :
>>
>>> Yes, but this is true for all flows. Web applications are dangerous.
>>> Applications handling user input are dangerous too.
>>>
>>> Le dim. 27 août 2023, 17:46, Tom Jones  a
>>> écrit :
>>>
 You can write your code as strong as you wish. You cannot determine if
 the code running in the computer is that code running unaltered. ..tom


 On Sun, Aug 27, 2023 at 5:25 AM Yannick Majoros 
 wrote:

> Thanks for taking the time to respond and for the constructive
> feedback.
>
> Still, there is some initial incorrect point that makes the rest of
> the discussion complicated, and partly wrong.
>
> 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 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 

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

[Yannick Majoros]

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  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  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=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 

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

[Yannick Majoros]

Again, there is something fundamentally misunderstood here: Philippe's
exploit will not work with a correctly implemented service worker. Also not
in an iframe. Also not if you unregister it and you start a new iframe.

There is no "need to explain yourself several times" and nobody has
"already demonstrated back in January that this approach is not effective",
because a correctly implemented service worker can effectively prevent this
attack. The attacker cannot "run a new flow" and automate getting a token
if the service worker implementation follows the specified guidelines:
*§6.4.2.1*

** The application MUST register the Service Worker before running any
code interacting with the user.*

The redirect URI is registered within your application. If you allow any
redirect_uri to be a silent refresh flow (typically in an iframe), you
*must* make it synchronously register the service worker as the first
action on the page, just as any other part of the application (and stopping
that is a whole different attack than XSS). The single-threaded nature of
javascript and synchronous loading of scripts will not let any secret leak
before it has been loaded (and as an additional counter-measure for
half-manual access code leaks, you could add some restriction to remove
auth codes from pages before it is loaded).

Hence my proposal: instead of a demonstration where you test a
possibly incomplete implementation (which, as far as I can see, doesn't
have the fine details that make it fool-proof), I propose to deliver a
proof-of-contest that would follow these guidelines. Before admitting that
"you cannot secure browser-flows only", I'd still want to actually see that
you can do this (which isn't the case from the explanation I read this
far). This whole story can perfectly be all wrong, but it's work checking
first. Let's be pragmatic, right?


Le lun. 28 août 2023 à 14:15, Jim Manico  a écrit :

> *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=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 

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

[Yannick Majoros]

My last comment was rather ironic: user-facing applications are dangerous
(security is hard, which I say nothing with), and that is true for any
scheme.. BFFs are not any safer, XSS or any successful malicious javascript
execution has the same end effect (=game over, complete compromise of
authenticated calls), and there was still no factual demonstration of
multiple levels of security here. See my detailed explanations.

Le lun. 28 août 2023 à 11:35, Steinar Noem  a écrit :

> I think this is a great discussion, and it seems to me that Yannicks last
> comment is basically what Phillippe is trying to point out..
> I just wanted to remind the authors about a couple of things that we
> briefly discussed during OSW in London.
>
> Although it might not be directly relevant for this discussion I do think
> that it might be a good idea that the spec mentions that:
>
>- The level of security you require for any client is often a
>reflection of the sensitivity of the information that the API exposes. You
>will have different requirements for confidential information than for open
>data. An example of a similar recommendation can be found in the HTTP
>Semantics specification: https://httpwg.org/specs/rfc9110.html#GET
>- In my domain it is most often the owner of the API (the data
>controller) who defines and approves the level of security which it finds
>to fit their responsibilities (e.g. legal obligations) - although in some
>cases it might be both the data provider and the data consumer. Meaning -
>this BCP might be equally important for the API-owner as it is to the
>client developer.
>- I think this discussion shows that any mitigation on the browser
>side will only raise the bar for the attacker, and can never be a fully
>effective countermeasure. I think this point could be even more clearly
>stated early in the spec, and that both the API-owner or client owner
>should be aware of this risk, and select their appropriate choice of
>security measures based on a risk assessment. In some cases their
>conclusion might be that a browser based app is not secure enough for
>their responsibilities.
>
>
> S
>
> søn. 27. aug. 2023 kl. 18:41 skrev Yannick Majoros :
>
>> Yes, but this is true for all flows. Web applications are dangerous.
>> Applications handling user input are dangerous too.
>>
>> Le dim. 27 août 2023, 17:46, Tom Jones  a
>> écrit :
>>
>>> You can write your code as strong as you wish. You cannot determine if
>>> the code running in the computer is that code running unaltered. ..tom
>>>
>>>
>>> On Sun, Aug 27, 2023 at 5:25 AM Yannick Majoros 
>>> wrote:
>>>
 Thanks for taking the time to respond and for the constructive feedback.

 Still, there is some initial incorrect point that makes the rest of the
 discussion complicated, and partly wrong.

 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 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 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.

 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?

 The demonstration in its current form would not lead to a successful

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

[Jim Manico]

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  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 
>>>  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=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:
>> The attacker unregisters the SW in the main browsing context, preventing it 
>> from being used in any new browsing context
>> The attacker injects a new iframe and points it to the authorization endpoint
>> The AS responds with a redirect with the authorization code
>> 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)
>> 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 

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

[Jim Manico]

*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 
>  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=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:
> The attacker unregisters the SW in the main browsing context, preventing it 
> from being used in any new browsing context
> The attacker injects a new iframe and points it to the authorization endpoint
> The AS responds with a redirect with the authorization code
> 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)
> 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. 
> 

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

[Philippe De Ryck]

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=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:
The attacker unregisters the SW in the main browsing context, preventing it 
from being used in any new browsing context
The attacker injects a new iframe and points it to the authorization endpoint
The AS responds with a redirect with the authorization code
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)
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 

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

[Steinar Noem]

I think this is a great discussion, and it seems to me that Yannicks last
comment is basically what Phillippe is trying to point out..
I just wanted to remind the authors about a couple of things that we
briefly discussed during OSW in London.

Although it might not be directly relevant for this discussion I do think
that it might be a good idea that the spec mentions that:

   - The level of security you require for any client is often a reflection
   of the sensitivity of the information that the API exposes. You will have
   different requirements for confidential information than for open data. An
   example of a similar recommendation can be found in the HTTP Semantics
   specification: https://httpwg.org/specs/rfc9110.html#GET
   - In my domain it is most often the owner of the API (the data
   controller) who defines and approves the level of security which it finds
   to fit their responsibilities (e.g. legal obligations) - although in some
   cases it might be both the data provider and the data consumer. Meaning -
   this BCP might be equally important for the API-owner as it is to the
   client developer.
   - I think this discussion shows that any mitigation on the browser side
   will only raise the bar for the attacker, and can never be a fully
   effective countermeasure. I think this point could be even more clearly
   stated early in the spec, and that both the API-owner or client owner
   should be aware of this risk, and select their appropriate choice of
   security measures based on a risk assessment. In some cases their
   conclusion might be that a browser based app is not secure enough for
   their responsibilities.


S

søn. 27. aug. 2023 kl. 18:41 skrev Yannick Majoros :

> Yes, but this is true for all flows. Web applications are dangerous.
> Applications handling user input are dangerous too.
>
> Le dim. 27 août 2023, 17:46, Tom Jones  a
> écrit :
>
>> You can write your code as strong as you wish. You cannot determine if
>> the code running in the computer is that code running unaltered. ..tom
>>
>>
>> On Sun, Aug 27, 2023 at 5:25 AM Yannick Majoros 
>> wrote:
>>
>>> Thanks for taking the time to respond and for the constructive feedback.
>>>
>>> Still, there is some initial incorrect point that makes the rest of the
>>> discussion complicated, and partly wrong.
>>>
>>> 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 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 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.
>>>
>>> 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?
>>>
>>> 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.
>>>
>>> Yannick
>>>
>>>
>>> Le sam. 26 août 2023 à 14:20, Philippe De Ryck <
>>> phili...@pragmaticwebsecurity.com> a écrit :
>>>
 My responses inline.


 Hi everyone,

 The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract
 further explains that it "details the security considerations and best
 practices that must be taken into account when developing browser-based
 applications that use OAuth 2.0.".

 As such, detailing security 

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

[Yannick Majoros]

Yes, but this is true for all flows. Web applications are dangerous.
Applications handling user input are dangerous too.

Le dim. 27 août 2023, 17:46, Tom Jones  a
écrit :

> You can write your code as strong as you wish. You cannot determine if the
> code running in the computer is that code running unaltered. ..tom
>
>
> On Sun, Aug 27, 2023 at 5:25 AM Yannick Majoros  wrote:
>
>> Thanks for taking the time to respond and for the constructive feedback.
>>
>> Still, there is some initial incorrect point that makes the rest of the
>> discussion complicated, and partly wrong.
>>
>> 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 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 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.
>>
>> 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?
>>
>> 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.
>>
>> Yannick
>>
>>
>> Le sam. 26 août 2023 à 14:20, Philippe De Ryck <
>> phili...@pragmaticwebsecurity.com> a écrit :
>>
>>> My responses inline.
>>>
>>>
>>> Hi everyone,
>>>
>>> The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract
>>> further explains that it "details the security considerations and best
>>> practices that must be taken into account when developing browser-based
>>> applications that use OAuth 2.0.".
>>>
>>> As such, detailing security considerations is important. I share the
>>> point of view that basing web applications on proven concepts is important.
>>> The approaches detailed in the document have all their advantages
>>> and disadvantages.
>>>
>>>
>>> We have discussed the topic of browser-based apps in depth at the OAuth
>>> Security Workshop last week. I am also working with Aaron Parecki on
>>> updating the specification to more accurately reflect these advantages and
>>> disadvantages. Updates will go out in the coming days/weeks, so we more
>>> than welcome concrete feedback on the content there.
>>>
>>> There are 2 main approaches to browser-based applications security. One
>>> of them is to store security credentials at the frontend. The other one is
>>> to use cookies and a BFF. Though common practice, there is nothing
>>> fundamentally more secure about them in a demonstrable way. Different
>>> approaches, different characteristics and security assumptions. Nobody can
>>> prove that either approach is better, just that there are different
>>> concerns.
>>>
>>> Handling security in BFFs relies on cookies that cannot be read by the
>>> javascript application. This mechanism provides some reliable protection
>>> about the cookie itself that is used as a kind of credential to access
>>> confidential web resources. It obviously demands some additional layers in
>>> the flow (proxy or light server). You also need a mechanism to share
>>> session information, either at the server side, or for example by having
>>> the cookie itself hold that information. A bigger concern to me is that you
>>> basically give up standard mechanisms for securing the flow between the
>>> frontend and the backend: the security between the two is a custom solution
>>> (based on cookies, in a specific, custom way, this part being in no way

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

[Tom Jones]

You can write your code as strong as you wish. You cannot determine if the
code running in the computer is that code running unaltered. ..tom


On Sun, Aug 27, 2023 at 5:25 AM Yannick Majoros  wrote:

> Thanks for taking the time to respond and for the constructive feedback.
>
> Still, there is some initial incorrect point that makes the rest of the
> discussion complicated, and partly wrong.
>
> 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 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 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.
>
> 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?
>
> 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.
>
> Yannick
>
>
> Le sam. 26 août 2023 à 14:20, Philippe De Ryck <
> phili...@pragmaticwebsecurity.com> a écrit :
>
>> My responses inline.
>>
>>
>> Hi everyone,
>>
>> The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract
>> further explains that it "details the security considerations and best
>> practices that must be taken into account when developing browser-based
>> applications that use OAuth 2.0.".
>>
>> As such, detailing security considerations is important. I share the
>> point of view that basing web applications on proven concepts is important.
>> The approaches detailed in the document have all their advantages
>> and disadvantages.
>>
>>
>> We have discussed the topic of browser-based apps in depth at the OAuth
>> Security Workshop last week. I am also working with Aaron Parecki on
>> updating the specification to more accurately reflect these advantages and
>> disadvantages. Updates will go out in the coming days/weeks, so we more
>> than welcome concrete feedback on the content there.
>>
>> There are 2 main approaches to browser-based applications security. One
>> of them is to store security credentials at the frontend. The other one is
>> to use cookies and a BFF. Though common practice, there is nothing
>> fundamentally more secure about them in a demonstrable way. Different
>> approaches, different characteristics and security assumptions. Nobody can
>> prove that either approach is better, just that there are different
>> concerns.
>>
>> Handling security in BFFs relies on cookies that cannot be read by the
>> javascript application. This mechanism provides some reliable protection
>> about the cookie itself that is used as a kind of credential to access
>> confidential web resources. It obviously demands some additional layers in
>> the flow (proxy or light server). You also need a mechanism to share
>> session information, either at the server side, or for example by having
>> the cookie itself hold that information. A bigger concern to me is that you
>> basically give up standard mechanisms for securing the flow between the
>> frontend and the backend: the security between the two is a custom solution
>> (based on cookies, in a specific, custom way, this part being in no way
>> OAuth or standard). This solves the problem by not using OAuth at all in
>> the browser part of the application, basically making the client
>> application purely backend. However, the fact that browser-based
>> applications cannot be secured with OAuth isn't universally 

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

[Yannick Majoros]

Thanks for taking the time to respond and for the constructive feedback.

Still, there is some initial incorrect point that makes the rest of the
discussion complicated, and partly wrong.

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 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 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.

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?

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.

Yannick


Le sam. 26 août 2023 à 14:20, Philippe De Ryck <
phili...@pragmaticwebsecurity.com> a écrit :

> My responses inline.
>
>
> Hi everyone,
>
> The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract
> further explains that it "details the security considerations and best
> practices that must be taken into account when developing browser-based
> applications that use OAuth 2.0.".
>
> As such, detailing security considerations is important. I share the point
> of view that basing web applications on proven concepts is important. The
> approaches detailed in the document have all their advantages
> and disadvantages.
>
>
> We have discussed the topic of browser-based apps in depth at the OAuth
> Security Workshop last week. I am also working with Aaron Parecki on
> updating the specification to more accurately reflect these advantages and
> disadvantages. Updates will go out in the coming days/weeks, so we more
> than welcome concrete feedback on the content there.
>
> There are 2 main approaches to browser-based applications security. One of
> them is to store security credentials at the frontend. The other one is to
> use cookies and a BFF. Though common practice, there is nothing
> fundamentally more secure about them in a demonstrable way. Different
> approaches, different characteristics and security assumptions. Nobody can
> prove that either approach is better, just that there are different
> concerns.
>
> Handling security in BFFs relies on cookies that cannot be read by the
> javascript application. This mechanism provides some reliable protection
> about the cookie itself that is used as a kind of credential to access
> confidential web resources. It obviously demands some additional layers in
> the flow (proxy or light server). You also need a mechanism to share
> session information, either at the server side, or for example by having
> the cookie itself hold that information. A bigger concern to me is that you
> basically give up standard mechanisms for securing the flow between the
> frontend and the backend: the security between the two is a custom solution
> (based on cookies, in a specific, custom way, this part being in no way
> OAuth or standard). This solves the problem by not using OAuth at all in
> the browser part of the application, basically making the client
> application purely backend. However, the fact that browser-based
> applications cannot be secured with OAuth isn't universally true, and
> strongly depends on one's definition of "secure", and basically comes down
> to what the security issue is.
>
>
> The updated specification will clearly outline the security considerations
> when making the browser-based application a public OAuth client.
>
> *The main problem with a browser-only client is that the attacker with

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

[Tom Jones]

Right Philippe -  there really is no way to create a secure client as a web
app.  You would need access to the trusted execution environment, which is
not available.

..tom


On Sat, Aug 26, 2023 at 5:21 AM Philippe De Ryck <
phili...@pragmaticwebsecurity.com> wrote:

> My responses inline.
>
>
> Hi everyone,
>
> The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract
> further explains that it "details the security considerations and best
> practices that must be taken into account when developing browser-based
> applications that use OAuth 2.0.".
>
> As such, detailing security considerations is important. I share the point
> of view that basing web applications on proven concepts is important. The
> approaches detailed in the document have all their advantages
> and disadvantages.
>
>
> We have discussed the topic of browser-based apps in depth at the OAuth
> Security Workshop last week. I am also working with Aaron Parecki on
> updating the specification to more accurately reflect these advantages and
> disadvantages. Updates will go out in the coming days/weeks, so we more
> than welcome concrete feedback on the content there.
>
> There are 2 main approaches to browser-based applications security. One of
> them is to store security credentials at the frontend. The other one is to
> use cookies and a BFF. Though common practice, there is nothing
> fundamentally more secure about them in a demonstrable way. Different
> approaches, different characteristics and security assumptions. Nobody can
> prove that either approach is better, just that there are different
> concerns.
>
> Handling security in BFFs relies on cookies that cannot be read by the
> javascript application. This mechanism provides some reliable protection
> about the cookie itself that is used as a kind of credential to access
> confidential web resources. It obviously demands some additional layers in
> the flow (proxy or light server). You also need a mechanism to share
> session information, either at the server side, or for example by having
> the cookie itself hold that information. A bigger concern to me is that you
> basically give up standard mechanisms for securing the flow between the
> frontend and the backend: the security between the two is a custom solution
> (based on cookies, in a specific, custom way, this part being in no way
> OAuth or standard). This solves the problem by not using OAuth at all in
> the browser part of the application, basically making the client
> application purely backend. However, the fact that browser-based
> applications cannot be secured with OAuth isn't universally true, and
> strongly depends on one's definition of "secure", and basically comes down
> to what the security issue is.
>
>
> The updated specification will clearly outline the security considerations
> when making the browser-based application a public OAuth client.
>
> *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.* These
> tokens give the attacker long-term and unrestricted access in the name of
> the user. A BFF-based architecture does not suffer from this issue, since
> the OAuth client is a confidential client. Regardless of one’s definition
> of “secure”, this is a clear difference on the achievable level of
> security.
>
> Of course, as stated multiple times before, the use of a BFF does not
> eliminate the presence of the malicious JS, nor does it solve all abuse
> scenarios.
>
>
>
> Storing tokens at the frontend has advantages: it solves my concern above
> about a standard based flow between the frontend and the backend.
>
>
> The use of cookies is a core building block of the web, and is quite
> standard.
>
> It's simpler from an operational point of view. And it's been used in the
> wild for ages.
>
>
> Anyone using a browser-only client should be informed about the clear and
> significant dangers of this approach, which the updated specification will
> do.
>
>
> Both flows have been compromised numerous times. This doesn't mean they
> are not right by design, but that the specific security concerns have to be
> addressed.
>
>
> If you have specific security concerns about a BFF, I’d suggest raising
> them. Until now, I have only seen arguments that highlight the additional
> effort it takes to implement a BFF, but nothing to undermine its security.
> Plenty of highly sensitive applications in the healthcare and financial
> industry opt for a BFF for its improved security properties and consider
> this trade-off to be favorable.
>
>
> Now, the concerns we are really discussing is, what happens in case of XSS
> or any form of malicious javascript.
>
> In this case, for all known flows, session riding is the first real issue.
> Whether the injected code calls protected web resources through the BFF or
> using the stored tokens, is irrelevant: the 

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

[Philippe De Ryck]

My responses inline.


> Hi everyone,
> 
> The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract 
> further explains that it "details the security considerations and best 
> practices that must be taken into account when developing browser-based 
> applications that use OAuth 2.0.".
> 
> As such, detailing security considerations is important. I share the point of 
> view that basing web applications on proven concepts is important. The 
> approaches detailed in the document have all their advantages and 
> disadvantages.

We have discussed the topic of browser-based apps in depth at the OAuth 
Security Workshop last week. I am also working with Aaron Parecki on updating 
the specification to more accurately reflect these advantages and 
disadvantages. Updates will go out in the coming days/weeks, so we more than 
welcome concrete feedback on the content there.

> There are 2 main approaches to browser-based applications security. One of 
> them is to store security credentials at the frontend. The other one is to 
> use cookies and a BFF. Though common practice, there is nothing fundamentally 
> more secure about them in a demonstrable way. Different approaches, different 
> characteristics and security assumptions. Nobody can prove that either 
> approach is better, just that there are different concerns.
> 
> Handling security in BFFs relies on cookies that cannot be read by the 
> javascript application. This mechanism provides some reliable protection 
> about the cookie itself that is used as a kind of credential to access 
> confidential web resources. It obviously demands some additional layers in 
> the flow (proxy or light server). You also need a mechanism to share session 
> information, either at the server side, or for example by having the cookie 
> itself hold that information. A bigger concern to me is that you basically 
> give up standard mechanisms for securing the flow between the frontend and 
> the backend: the security between the two is a custom solution (based on 
> cookies, in a specific, custom way, this part being in no way OAuth or 
> standard). This solves the problem by not using OAuth at all in the browser 
> part of the application, basically making the client application purely 
> backend. However, the fact that browser-based applications cannot be secured 
> with OAuth isn't universally true, and strongly depends on one's definition 
> of "secure", and basically comes down to what the security issue is.

The updated specification will clearly outline the security considerations when 
making the browser-based application a public OAuth client. 

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. These tokens give the attacker 
long-term and unrestricted access in the name of the user. A BFF-based 
architecture does not suffer from this issue, since the OAuth client is a 
confidential client. Regardless of one’s definition of “secure”, this is a 
clear difference on the achievable level of security. 

Of course, as stated multiple times before, the use of a BFF does not eliminate 
the presence of the malicious JS, nor does it solve all abuse scenarios. 



> Storing tokens at the frontend has advantages: it solves my concern above 
> about a standard based flow between the frontend and the backend.

The use of cookies is a core building block of the web, and is quite standard. 

> It's simpler from an operational point of view. And it's been used in the 
> wild for ages.

Anyone using a browser-only client should be informed about the clear and 
significant dangers of this approach, which the updated specification will do. 


> Both flows have been compromised numerous times. This doesn't mean they are 
> not right by design, but that the specific security concerns have to be 
> addressed.

If you have specific security concerns about a BFF, I’d suggest raising them. 
Until now, I have only seen arguments that highlight the additional effort it 
takes to implement a BFF, but nothing to undermine its security. Plenty of 
highly sensitive applications in the healthcare and financial industry opt for 
a BFF for its improved security properties and consider this trade-off to be 
favorable.


> Now, the concerns we are really discussing is, what happens in case of XSS or 
> any form of malicious javascript.
> 
> In this case, for all known flows, session riding is the first real issue. 
> Whether the injected code calls protected web resources through the BFF or 
> using the stored tokens, is irrelevant: the evil is done. Seeing different 
> threat levels between token abuse and session riding is a logical shortcut: 
> in many cases, the impact will be exactly the same.

Stating that using stolen tokens is the same as sending requests through a 
compromised client in the user’s browser (client hijacking) 

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

[Yannick Majoros]

Hi everyone,

The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract
further explains that it "details the security considerations and best
practices that must be taken into account when developing browser-based
applications that use OAuth 2.0.".

As such, detailing security considerations is important. I share the point
of view that basing web applications on proven concepts is important. The
approaches detailed in the document have all their advantages
and disadvantages.

There are 2 main approaches to browser-based applications security. One of
them is to store security credentials at the frontend. The other one is to
use cookies and a BFF. Though common practice, there is nothing
fundamentally more secure about them in a demonstrable way. Different
approaches, different characteristics and security assumptions. Nobody can
prove that either approach is better, just that there are different
concerns.

Handling security in BFFs relies on cookies that cannot be read by the
javascript application. This mechanism provides some reliable protection
about the cookie itself that is used as a kind of credential to access
confidential web resources. It obviously demands some additional layers in
the flow (proxy or light server). You also need a mechanism to share
session information, either at the server side, or for example by having
the cookie itself hold that information. A bigger concern to me is that you
basically give up standard mechanisms for securing the flow between the
frontend and the backend: the security between the two is a custom solution
(based on cookies, in a specific, custom way, this part being in no way
OAuth or standard). This solves the problem by not using OAuth at all in
the browser part of the application, basically making the client
application purely backend. However, the fact that browser-based
applications cannot be secured with OAuth isn't universally true, and
strongly depends on one's definition of "secure", and basically comes down
to what the security issue is.

Storing tokens at the frontend has advantages: it solves my concern above
about a standard based flow between the frontend and the backend. It's
simpler from an operational point of view. And it's been used in the wild
for ages.

Both flows have been compromised numerous times. This doesn't mean they are
not right by design, but that the specific security concerns have to be
addressed.

Now, the concerns we are really discussing is, what happens in case of XSS
or any form of malicious javascript.

In this case, for all known flows, session riding is the first real issue.
Whether the injected code calls protected web resources through the BFF or
using the stored tokens, is irrelevant: the evil is done. Seeing different
threat levels between token abuse and session riding is a logical shortcut:
in many cases, the impact will be exactly the same.

Reducing the attack surface with a BFF or even a simple proxy is a possible
but separate topic: this doesn't have to be linked to where tokens are
stored. Alternatively, services that shouldn't be accessible could simply
not be exposed, and token scope and audience must be well thought.

As such, BFFs as well as frontend token storage, though different, are
application design choices and have no demonstrable superiority from a
security point of view.

Still, it seems it matters to some people to not exfiltrate tokens in case
of successful XSS. In the first instance, I don't share this need to
protect short-lived tokens in a game over scenario, but the whole
investigation of more secure frontend storage mechanisms started because
some customers are concerned. We are in the realm of choice, not of
provable security need, but it is still important to them.

Documenting security concerns and possible solutions is part of the
document. Where you store the tokens has an impact on how easy it will be
for an attacker to exfiltrate them. Local or session storage is obviously
not the best choice here, as injected javascript can easily access it. A
service worker is an interesting place to store them, as it can
additionally play the role of a front-end proxy that both holds the token
securely, and securely proxy requests to the resource server. Besides, a
track was started with Rifaat to initiate changes to the service worker
specifications to make some things simpler.

The point that the service worker solution isn't that widespread is indeed
correct and should be addressed. I propose transparently mentioning that it
is seen as a possible but uncommon storage mechanism. There should also be
some explanation about other kinds of web workers, which are more
commonly used but exploitable, so less secure when token exfiltration is a
concern. The document isn't only about security best practices, though, but
about security concerns. Implementations are explicitly out of scope.

My conclusion is that, though we can surely make the document better, there
is no all-encompassing 

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

[Philippe De Ryck]

I’m going to respond inline and re-organize the previous message a bit. 


> It's worth noting that it didn't get so much traction up to this time, and 
> that I stopped using it in multiple applications myself.

That’s exactly what I meant with my statement of an “unproven approach”. If 
you, the creator of this pattern, are not even using it in a production 
application, I fail to see how this is a recommended best practice for securing 
frontends. After all, the goal of this document is defined as follows:

This specification details the security considerations and best practices that 
must be taken into account when developing browser-based applications that use 
OAuth 2.0


BFFs, on the other hand, are widely used in applications where security is a 
high priority (e.g., financial, healthcare). 


> Not because it's not a worthwhile pattern to solve the mentioned problem, but 
> because token leak is typically not the real issue. XSS is the first one to 
> solve, and I disagree it's unavoidable (and certainly at any level: extra 
> care for application start code can get you very far).

It’s about more than XSS. Malicious JS ends up in applications through a 
variety of ways. In theory, you could argue that we know how to solve XSS or 
the issue of malicious JS. In practice, this is unfortunately absolutely false. 

Even if we just focus on XSS, where developers have full control over the code, 
I can easily argue that you cannot guarantee the absence of a vulnerability. 
For example, a well-established best practice  for outputting data with benign 
HTML is running the unsafe data through an HTML sanitiser. A few years ago, 
both Google’s internal sanitiser and DOMPurify, a sanitiser built by the 
world’s best XSS experts, contained a bypass vulnerability 
(https://securityaffairs.com/83199/hacking/google-search-xss-flaw.html 
 & 
https://portswigger.net/research/bypassing-dompurify-again-with-mutation-xss). 
In essence, this means that every project relying on these (which is a best 
practice) was potentially vulnerable to XSS.


It remains true that you should aim to avoid having malicious JS in your app 
anyway, and do everything in your power to make this happen. However, the 
assumption in the spec is that malicious JS will happen, since plenty of 
countermeasures aim to reduce the impact of such an attack.


> Regarding the demonstration in the video, I don't think it would compromise 
> my current implementation.
> 
> The current draft says this in §6.4.2.1 :
> * The application MUST register the Service Worker before running any code 
> interacting with the user.
> 
> This adds an important constraint: an attacker would not only need to 
> compromise any part of the application, but should also make sure the very 
> first thing it does (registering the service worker) is also compromised, 
> which is much harder.
> 
> Step by step, the code I saw would:
> - open an iframe
> - redirect to the authorization server
> - get redirected to the registered redirect_uri (which is an additional 
> important constraint here)
> - register the service worker to run immediately
> ... which would stop the attack here, the main application not even seeing 
> the auth code and not being able to call the /token endpoint

No, because running a silent flow in an iframe typically uses a web message 
response. In essence, the callback is not the redirect URI, but a minimal JS 
page that sends the code to the main application context using the web 
messaging mechanism. The message will have the origin of the authorization 
server as a sender. 


> BFFs are not a proven better level of protection. Session riding in case of 
> XSS is still the same.
> 
> One such claim is about BFFs being more secure because they are backed by 
> unstealable session cookies.

This view on threats is not the position that this working group has taken 
before. For example, for DPoP, there’s a detailed threat model that aims to 
counter a variety of attacks, except for session riding, which is explicitly 
considered out of scope (https://danielfett.de/2020/05/04/dpop-attacker-model/ 
).

I am not saying (nor have I ever said) that a BFF is the holy grail that solves 
everything. If malicious JS code runs, you/the user are still in major trouble. 
However, with a BFF, that trouble can be reduced from unfettered abuse of 
access/refresh tokens to session riding (aka online XSS from DPoP). The fact 
that a BFF uses cookies helps to obtain these properties, but it is not the 
foundation of the security benefits. The main benefit is that the OAuth client 
application is a backend web application instead of a frontend web application.


> They also have debatable points: you either need some third party or custom 
> software (with their own threat to security)

Why do you think a BFF is third-party or 

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

[Dick Hardt]

Philippe: thanks for investigating each of the links I provided. I had
mistakenly assumed that the SW would be managing the entire OAuth
interaction per the recommendation.

Yannick: thank you for sharing your own experience and views.

It seems that the SW recommendation is aspirational rather than an
established best practice. Assuming that is true, I agree it should not be
included as it will add complexity with unproven benefit.

Unfortunately I won't be in London for OSW. I'm hopeful that we can revise
the document so that it is acceptable to all attending to be ready for WGLC
so that we can publish the best current practices to guide implementers.
I'd suggest that if we can't agree that a given practice is the best
current practice, it should be dropped so that what we do agree on can be
published.

/Dick




On Sun, Aug 13, 2023 at 8:28 AM Yannick Majoros  wrote:

> Hello everyone,
>
> I'd like to contribute to the ongoing discussion by sharing my insights.
> Giving some feedback has been on my list for a long time, but hasn't been
> feasible for me due to time constraints, as I'm sure all of you have. I'm
> taking some time to give my two cents.
>
> First, some context. I started getting more involved with this while
> working for one of my customers (a government organization), documenting
> and architecturing the way forward for using OAuth2 and OIDC in our
> frontend applications. There were some debates about what would be
> acceptable for us and that we could consider secure. Besides the
> specifications, there were various claims besides the specifications with
> varying degrees of research and documentation. Some of them are quite
> opinionated or commercially motivated. "Common sense" statements without
> demonstration, made the debate difficult. One such claim is about BFFs
> being more secure because they are backed by unstealable session cookies.
>
> After some discussions, among which with Aaron, I decided to investigate
> possible solutions to the "what if my frontend is compromised by an XSS
> attack and I still want my token to not leak" problem. One such solution
> for which I wrote some proof-of-concept and ported a few applications at
> the time was with a Service Worker, for which I had some early
> implementation here: https://github.com/Valuya/servicewauther .
>
> It's worth noting that it didn't get so much traction up to this time, and
> that I stopped using it in multiple applications myself. Not because it's
> not a worthwhile pattern to solve the mentioned problem, but because token
> leak is typically not the real issue. XSS is the first one to solve, and I
> disagree it's unavoidable (and certainly at any level: extra care for
> application start code can get you very far). Next comes probably session
> riding: you need to restrict your attack surface as much as possible and
> scope what users can access to what the application actually needs. This
> problem is similar for any XSS exploit, whatever implementation is chosen
> (BFF, session storage, service worker...), and lowers the priority of
> token exfiltration.
>
> Regarding the demonstration in the video, I don't think it would
> compromise my current implementation.
>
> The current draft says this in §6.4.2.1:
> ** The application MUST register the Service Worker before running any
> code interacting with the user.*
>
> This adds an important constraint: an attacker would not only need to
> compromise any part of the application, but should also make sure the very
> first thing it does (registering the service worker) is also compromised,
> which is much harder.
>
> Step by step, the code I saw would:
> - open an iframe
> - redirect to the authorization server
> - get redirected to the registered redirect_uri (which is an additional
> important constraint here)
> - register the service worker to run immediately
> ... which would stop the attack here, the main application not even seeing
> the auth code and not being able to call the /token endpoint
>
> BFFs are not a proven better level of protection. Session riding in case
> of XSS is still the same. They also have debatable points: you either need
> some third party or custom software (with their own threat to security),
> and in the current state of knowledge, they rather give a false sense of
> security. Complexity of implementation is another point, outside of
> security.
>
> My personal conclusion is that the root issue isn't token exfiltration,
> XSS or session riding, but that the real danger comes from authentication
> itself. There are some flows with PROs and CONS, and we have to live with
> them, accepting the risks and finding the best mitigations. The fact that
> there are different point of views here is a good thing, and I think this
> will help us document strengths and weaknesses of the different solutions.
>
> Yannick
>
> Le dim. 13 août 2023 à 08:22, Philippe De Ryck <
> phili...@pragmaticwebsecurity.com> a écrit :
>
>>
>> I have a different 

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

[Yannick Majoros]

Hello everyone,

I'd like to contribute to the ongoing discussion by sharing my insights.
Giving some feedback has been on my list for a long time, but hasn't been
feasible for me due to time constraints, as I'm sure all of you have. I'm
taking some time to give my two cents.

First, some context. I started getting more involved with this while
working for one of my customers (a government organization), documenting
and architecturing the way forward for using OAuth2 and OIDC in our
frontend applications. There were some debates about what would be
acceptable for us and that we could consider secure. Besides the
specifications, there were various claims besides the specifications with
varying degrees of research and documentation. Some of them are quite
opinionated or commercially motivated. "Common sense" statements without
demonstration, made the debate difficult. One such claim is about BFFs
being more secure because they are backed by unstealable session cookies.

After some discussions, among which with Aaron, I decided to investigate
possible solutions to the "what if my frontend is compromised by an XSS
attack and I still want my token to not leak" problem. One such solution
for which I wrote some proof-of-concept and ported a few applications at
the time was with a Service Worker, for which I had some early
implementation here: https://github.com/Valuya/servicewauther .

It's worth noting that it didn't get so much traction up to this time, and
that I stopped using it in multiple applications myself. Not because it's
not a worthwhile pattern to solve the mentioned problem, but because token
leak is typically not the real issue. XSS is the first one to solve, and I
disagree it's unavoidable (and certainly at any level: extra care for
application start code can get you very far). Next comes probably session
riding: you need to restrict your attack surface as much as possible and
scope what users can access to what the application actually needs. This
problem is similar for any XSS exploit, whatever implementation is chosen
(BFF, session storage, service worker...), and lowers the priority of
token exfiltration.

Regarding the demonstration in the video, I don't think it would compromise
my current implementation.

The current draft says this in §6.4.2.1:
** The application MUST register the Service Worker before running any code
interacting with the user.*

This adds an important constraint: an attacker would not only need to
compromise any part of the application, but should also make sure the very
first thing it does (registering the service worker) is also compromised,
which is much harder.

Step by step, the code I saw would:
- open an iframe
- redirect to the authorization server
- get redirected to the registered redirect_uri (which is an additional
important constraint here)
- register the service worker to run immediately
... which would stop the attack here, the main application not even seeing
the auth code and not being able to call the /token endpoint

BFFs are not a proven better level of protection. Session riding in case of
XSS is still the same. They also have debatable points: you either need
some third party or custom software (with their own threat to security),
and in the current state of knowledge, they rather give a false sense of
security. Complexity of implementation is another point, outside of
security.

My personal conclusion is that the root issue isn't token exfiltration, XSS
or session riding, but that the real danger comes from authentication
itself. There are some flows with PROs and CONS, and we have to live with
them, accepting the risks and finding the best mitigations. The fact that
there are different point of views here is a good thing, and I think this
will help us document strengths and weaknesses of the different solutions.

Yannick

Le dim. 13 août 2023 à 08:22, Philippe De Ryck <
phili...@pragmaticwebsecurity.com> a écrit :

>
> I have a different interpretation of the objective of using a service
> worker, and it aligns with descriptions in most of those links -- minimize
> the risk of the access token and refresh token exfiltration from the
> application by malicious JS code.  Service workers, when implemented
> properly, isolate the access token, refresh token, PKCE from code in the
> DOM, similar to how properly created cookies are isolated from the DOM JS.
>
> This lowers the security risk of using OAuth to protect a server's
> resources to be similar to the risks of using cookies.  I think this is an
> improvement in the security of the application, and does not create a false
> sense of security as you claim.
>
>
> It is not just the use of a service worker that matters, it is the way the
> service worker is deployed. The examples you gave earlier all use a service
> worker to attach a token to an outgoing request. They still obtain the
> token from the main application (see [1] at the bottom), so tokens are
> still exposed to the main application. 

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

[Philippe De Ryck]

> I have a different interpretation of the objective of using a service worker, 
> and it aligns with descriptions in most of those links -- minimize the risk 
> of the access token and refresh token exfiltration from the application by 
> malicious JS code.  Service workers, when implemented properly, isolate the 
> access token, refresh token, PKCE from code in the DOM, similar to how 
> properly created cookies are isolated from the DOM JS.
> 
> This lowers the security risk of using OAuth to protect a server's resources 
> to be similar to the risks of using cookies.  I think this is an improvement 
> in the security of the application, and does not create a false sense of 
> security as you claim.

It is not just the use of a service worker that matters, it is the way the 
service worker is deployed. The examples you gave earlier all use a service 
worker to attach a token to an outgoing request. They still obtain the token 
from the main application (see [1] at the bottom), so tokens are still exposed 
to the main application. So if the goal is to prevent token exfiltration from 
the main app, this setup is not effective. The attacker could just run a new 
flow in an iframe, obtain fresh tokens and exfiltrate them.

The proposal of using service workers in this draft aims to provide this 
security by also shielding the authorization code and token exchange. I have 
not seen a practical implementation of this pattern. Furthermore, even if you 
implement this, an attacker with XSS capabilities can still unregister the 
worker and then obtain tokens to exfiltrate. 


> If an attacker has the ability to run malicious JS code in the application's 
> origin, the attacker can do anything against the underlying web resources 
> regardless of using OAuth or cookies.
> Do you have an alternative approach to isolating the OAuth credentials from 
> the DOM code? 

Yes, that is exactly why it is not possible to prevent token exfiltration when 
malicious JS runs. The BFF pattern as described in this document reduces the 
impact to its minimum level: a session riding attack. In that scenario, the 
attacker will never be able to obtain access/refresh tokens, and can only 
“tunnel” requests through the user’s online browser. That’s also why I always 
recommend to focus on defending against malicious JS instead of just trying to 
hide tokens. However, history shows that even with the best efforts, malicious 
JS will eventually end up in the application.

Unfortunately, the spec in its current from argues that techniques like refresh 
token rotation or the service worker help prevent abuse in case of token 
exfiltration. Since these techniques can (easily) be circumvented, they create 
a false sense of security. I clearly demonstrate this in the video I referenced 
earlier (https://www.youtube.com/watch?v=OpFN6gmct8c), as well as in this older 
post 
(https://mailarchive.ietf.org/arch/msg/oauth/s68mcQCC1NNe_Y2Q9Qu6x0VuLrI/). 
Note that this post is more than 3 years old, so my insights and way of 
explaining has changed since then.


> FWIW: If you want someone to understand previous posts, I'd suggest providing 
> a link to the post, and even better also include a small extract. Also, while 
> it is more effort on your part, I find concise, crisp responses more 
> constructive for email dialog, and similarly, don't expect that the email 
> list has, or will, take the time to watch your video. Have you watched any of 
> mine?

I fully understand that watching a video is not the most straightforward way of 
consuming content, but in this case, the video adds a tremendous amount of 
value. It allows me to use graphics to explain the issues, and it includes 
actual demo attacks to obtain tokens, even with recommended security mechanisms 
in place. If you would be arguing a point and refer to a video that clearly 
explains your thoughts, I would definitely watch it.






[1]

>>> 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

No mention of how tokens end up in the worker. A brief look at the code 
mentions frames and seems to refer to the AppAuth library, so this does not 
seem to happen in the worker.

>>> https://gaurav-techgeek.medium.com/re-architecting-authentication-with-service-workers-ff8fbbbfbdeb

The tokens are obtained from the main application. See the section "Now let us 
get the right token."

>>> https://itnext.io/using-service-worker-as-an-auth-relay-5abc402878dd

The tokens are obtained from the main application. I quote: getAuthTokenHeader 
method will communicate with js executed in a page to get current token 

>>> https://about.grabyo.com/service-workers-jwt-tokens/

No mention of how tokens end up in the worker.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

I have a different interpretation of the objective of using a service
worker, and it aligns with descriptions in most of those links -- minimize
the risk of the access token and refresh token exfiltration from the
application by malicious JS code.  Service workers, when implemented
properly, isolate the access token, refresh token, PKCE from code in the
DOM, similar to how properly created cookies are isolated from the DOM JS.

This lowers the security risk of using OAuth to protect a server's
resources to be similar to the risks of using cookies.  I think this is an
improvement in the security of the application, and does not create a false
sense of security as you claim.

If an attacker has the ability to run malicious JS code in the
application's origin, the attacker can do anything against the underlying
web resources regardless of using OAuth or cookies.

Do you have an alternative approach to isolating the OAuth credentials from
the DOM code?

FWIW: If you want someone to understand previous posts, I'd suggest
providing a link to the post, and even better also include a small extract.
Also, while it is more effort on your part, I find concise, crisp responses
more constructive for email dialog, and similarly, don't expect that the
email list has, or will, take the time to watch your video. Have you
watched any of mine?








On Thu, Aug 10, 2023 at 10:11 PM Philippe De Ryck <
phili...@pragmaticwebsecurity.com> wrote:

> 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  wrote:
>
>
> Philippe: would you expand on your comment:
>
> On Wed, Aug 9, 2023 at 11:51 PM Philippe De Ryck <
> phili...@pragmaticwebsecurity.com> 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 <
> phili...@pragmaticwebsecurity.com> 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 

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

[Philippe De Ryck]

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  wrote:
> 
> 
> Philippe: would you expand on your comment:
> 
> On Wed, Aug 9, 2023 at 11:51 PM Philippe De Ryck 
>  > 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 
>  > 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

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

[Dick Hardt]

Philippe: would you expand on your comment:

On Wed, Aug 9, 2023 at 11:51 PM Philippe De Ryck <
phili...@pragmaticwebsecurity.com> 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 <
phili...@pragmaticwebsecurity.com> 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
>
> On 30 Jul 2023, at 17:46, Rifaat Shekh-Yusef 
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> 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

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

[Aaron Parecki]

Hi Philippe, I look forward to discussing this with you at the OAuth
Security Workshop later this month. Like I mentioned to you last year, I
want to make sure your concerns are adequately captured in the document.

The goal for this draft is not to present the one "best" architecture for
browser-based apps, since as you mentioned, there are many different ways
attacks can happen and different trade-offs with the different patterns.

As to Brock's comment, the point of this draft is to document the existing
established patterns *as well as their limitations* so that someone
implementing OAuth in browser-based apps knows the limits of the pattern
they are choosing. We are not saying that any given recommendation in this
draft has no possible attack vectors, since that's not the reality of the
world in browsers.

Aaron

On Thu, Aug 10, 2023 at 7:16 AM Brock Allen  wrote:

> I agree with Philippe here.
>
> If there are already documented attack vectors working around the
> techniques presented in this document, then I worry it will give people a
> false sense of security if they follow the guidance contained therein.
>
> -Brock
>
> On 8/10/2023 2:51:35 AM, Philippe De Ryck <
> phili...@pragmaticwebsecurity.com> 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
>
> On 30 Jul 2023, at 17:46, Rifaat Shekh-Yusef 
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> 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

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

[Brock Allen]

I agree with Philippe here.

If there are already documented attack vectors working around the techniques 
presented in this document, then I worry it will give people a false sense of 
security if they follow the guidance contained therein. 

-Brock

On 8/10/2023 2:51:35 AM, Philippe De Ryck  
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

On 30 Jul 2023, at 17:46, Rifaat Shekh-Yusef  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 
[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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Philippe De Ryck]

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

> On 30 Jul 2023, at 17:46, Rifaat Shekh-Yusef  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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] WGLC for Browser-based Apps

[Rifaat Shekh-Yusef]

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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth