Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Joseph Heenan]

I support adoption.

Joseph


> On 23 Aug 2023, at 20:01, Rifaat Shekh-Yusef  wrote:
> 
> All,
> 
> This is an official call for adoption for the Protected Resource Metadata 
> draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
> 
> Please, reply on the mailing list and let us know if you are in favor of 
> adopting this draft as WG document, by Sep 6th.
> 
> 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] Call for adoption - Protected Resource Metadata

[Daniel Fett]

+1

Am 28.08.23 um 10:33 schrieb Joseph Heenan:

I support adoption.

Joseph


On 23 Aug 2023, at 20:01, Rifaat Shekh-Yusef 
 wrote:


All,

This is an official call for adoption for the *Protected Resource 
Metadata* draft:

https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/

Please, reply on the mailing list and let us know if you are in favor 
of adopting this draft as WG document, by *Sep 6th.*


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] Call for adoption - Protected Resource Metadata

[Takahiko Kawasaki]

I support adoption.

In the past, when considering the encryption of JWT access tokens, I
learned that the draft regarding the metadata of the resource server had
expired, which was disappointing. For an authorization server to encrypt an
access token with an asymmetric algorithm, it must obtain a public key of
the target resource server, but there was no standardized way. I'm glad to
see the specification has been revived. If it had been revived a bit
earlier, the addition that was made as "client" metadata in the "JWT
Response for OAuth Token Introspection" specification would likely have
been treated as metadata for the "resource server."

Best Regards,
Takahiko Kawasaki


On Thu, Aug 24, 2023 at 4:02 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *Sep 6th.*
>
> 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

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

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&t=1973) points 
you to the exact demo scenario, where I illustrate how an unregistered SW 
cannot prevent access to an endpoint in an iframe. Admittedly, I have not 
implemented a full OAuth client as a SW, but the minimal PoC you see here 
suffices to illustrate the ineffectiveness of this approach.

With this information, the attack scenario becomes the following:
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 aut

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&t=1973) 
> points you to the exact demo scenario, where I illustrate how an unregistered 
> SW cannot prevent access to an endpoint in an iframe. Admittedly, I have not 
> implemented a full OAuth client as a SW, but the minimal PoC you see here 
> suffices to illustrate the ineffectiveness of this approach.
> 
> With this information, the attack scenario becomes the following:
> 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

[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&t=1973) 
>> points you to the exact demo scenario, where I illustrate how an 
>> unregistered SW cannot prevent access to an endpoint in an iframe. 
>> Admittedly, I have not implemented a full OAuth client as a SW, but the 
>> minimal PoC you see here suffices to illustrate the ineffectiveness of this 
>> approach.
>> 
>> With this information, the attack scenario becomes the following:
>> 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

[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

[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&t=1973) points you to the
> exact demo scenario, where I illustrate how an unregistered SW cannot
> prevent access to an endpoint in an iframe. Admittedly, I have not
> implemented a full OAuth client as a SW, but the minimal PoC you see here
> suffices to illustrate the ineffectiveness of this approach.
>
> With this information, the attack scenario becomes the following:
>
>1. The attacker unregisters the SW in the main browsing context,
>preventing it from being used in any new browsing c

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&t=1973) points you to the
> exact demo scenario, where I illustrate how an unregistered SW cannot
> prevent access to an endpoint in an iframe. Admittedly, I have not
> implemented a full OAuth client as a SW, but the minimal PoC you see here
> suffices to illustrate the ineffectiveness of this approach.
>
> With this information, the attack scenario becomes the following:
>
>1. The attacker unregisters the SW in the main browsing context,
>preventing it from being used in any new browsing context
>2. The attacker injects a new iframe and points it to the
>authorization endpoint
>3. The AS responds with a redirect with the authorization code
>4. The attacker detects the redirect, copies the authorization code,
>and aborts the page from loading (so that the authorization code is never
>exchanged or the SW is never reloaded)
>5. The attacker extracts the authorization code and exchanges it for
>tokens
>
>
>
> TL;DR: a SW is not a security mechanism, and the browser cannot guarantee
> that a SW permanently prevents requests to a certain endpoint.
>
>
> This has further impact on much of the other statements:
> *> The main problem with a browser-only client is that the attacker with
> control over the client has the ability to run a silent Authorization Code
> flow, which provides them with an independent set of tokens*
> [...]
> *> **The security differences between a BFF and a browser-only app are
> not about token storage, but about the attacker being able to run a new
> flow to obtain tokens.*
> [...]
> *> Again, the security benefits of a BFF are not about stoken storage.
> Even if 

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 app

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 ac

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 authorizat

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

[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&t=1973) points you to the
>> exact demo scenario, where I illustrate how an unregistered SW cannot
>> prevent access to an endpoint in an iframe. Admittedly, I have not
>> implemented a full OAuth client as a SW, but the minimal PoC you see here
>> suffices to illustrate the ineffectiveness of this approach.
>>
>> With this information, the attack scenario becomes the following:
>>
>>1. The attacker unregisters the SW in the main browsing context,
>>preventing it from being used in any new browsing context
>>2. The attacker injects a new iframe and points it to the
>>authorization endpoint
>>3. The AS responds with a redirect with the authorization code
>>4. The attacker detects the redirect, copies the authorization code,
>>and aborts the page from loading (so that the authorization code is never
>>exchanged or the SW is never reloaded)
>>5. The attacker extracts the authorization code and exchanges it for
>>tokens
>>
>>
>>
>> TL;DR: a SW is not a security mechanism, and the browser cannot guarantee
>> that a SW permanently prevents requests to a certain endpoint.
>>
>>
>> This has further impact on much of the other statements:
>> *> The main problem with a browser-only client is that the attacker with
>> control

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 a

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

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&t=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 same-ori

[OAUTH-WG] Fwd: New Version Notification for draft-gilman-wimse-use-cases-00.txt

[Justin Richer]

Hi all,

Back at IETF116 in Yokohama, Evan Gilman presented information about SPIFFE, a 
workload security platform. At IETF 117 in SF, we presented a set of questions 
and possible new work, to lots of positive feedback. Now we’ve set up the 
Workload Identity in Multi System Environments (WIMSE) mailing list for 
discussing things, wi...@ietf.org — and we’ve just 
published the following -00 use cases document. If this topic area interests 
you, please take a look through the use cases (it’s pretty short right now) and 
join the conversation on the WIMSE mailing list.

Thanks,
 — Justin

Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-gilman-wimse-use-cases-00.txt
Date: August 28, 2023 at 1:53:01 PM EDT
To: "Evan Gilman" , "Joseph Salowey" , 
"Justin Richer" , "Pieter Kasselman" 


A new version of Internet-Draft draft-gilman-wimse-use-cases-00.txt has been
successfully submitted by Justin Richer and posted to the
IETF repository.

Name: draft-gilman-wimse-use-cases
Revision: 00
Title:Workload Identity Use Cases
Date: 2023-08-28
Group:Individual Submission
Pages:7
URL:  https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.txt
Status:   https://datatracker.ietf.org/doc/draft-gilman-wimse-use-cases/
HTML: https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-gilman-wimse-use-cases


Abstract:

  Workload identity systems like SPIFFE provide a unique set of
  security challenges, constraints, and possibilities that affect the
  larger systems they are a part of.  This document seeks to collect
  use cases within that space, with a specific look at both the OAuth
  and SPIFFE technologies.

Discussion Venues

  This note is to be removed before publishing as an RFC.

  Source for this draft and an issue tracker can be found at
  https://github.com/bspk/draft-gilman-wimse-use-cases.



The IETF Secretariat



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

Re: [OAUTH-WG] Fwd: New Version Notification for draft-gilman-wimse-use-cases-00.txt

[Dick Hardt]

Link for WIMSE list https://www.ietf.org/mailman/listinfo/wimse

On Mon, Aug 28, 2023 at 11:12 AM Justin Richer  wrote:

> Hi all,
>
> Back at IETF116 in Yokohama, Evan Gilman presented information about
> SPIFFE, a workload security platform. At IETF 117 in SF, we presented a set
> of questions and possible new work, to lots of positive feedback. Now we’ve
> set up the Workload Identity in Multi System Environments (WIMSE) mailing
> list for discussing things, wi...@ietf.org — and we’ve just published the
> following -00 use cases document. If this topic area interests you, please
> take a look through the use cases (it’s pretty short right now) and join
> the conversation on the WIMSE mailing list.
>
> Thanks,
>  — Justin
>
> Begin forwarded message:
>
> *From: *internet-dra...@ietf.org
> *Subject: **New Version Notification for
> draft-gilman-wimse-use-cases-00.txt*
> *Date: *August 28, 2023 at 1:53:01 PM EDT
> *To: *"Evan Gilman" , "Joseph Salowey" ,
> "Justin Richer" , "Pieter Kasselman" <
> pieter.kassel...@microsoft.com>
>
> A new version of Internet-Draft draft-gilman-wimse-use-cases-00.txt has
> been
> successfully submitted by Justin Richer and posted to the
> IETF repository.
>
> Name: draft-gilman-wimse-use-cases
> Revision: 00
> Title:Workload Identity Use Cases
> Date: 2023-08-28
> Group:Individual Submission
> Pages:7
> URL:
> https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-gilman-wimse-use-cases/
> HTML:
> https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-gilman-wimse-use-cases
>
>
> Abstract:
>
>   Workload identity systems like SPIFFE provide a unique set of
>   security challenges, constraints, and possibilities that affect the
>   larger systems they are a part of.  This document seeks to collect
>   use cases within that space, with a specific look at both the OAuth
>   and SPIFFE technologies.
>
> Discussion Venues
>
>   This note is to be removed before publishing as an RFC.
>
>   Source for this draft and an issue tracker can be found at
>   https://github.com/bspk/draft-gilman-wimse-use-cases.
>
>
>
> The IETF Secretariat
>
>
>
> ___
> 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

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

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