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

[Yannick Majoros <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <
>> [e-mail]> 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
>>> 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) is
>>> categorically false. Here are two concrete differences:
>>>
>>>
>>>    - Stolen refresh tokens give an attacker long-term access in the
>>>    name of the user. Client hijacking only works as long as the user’s browser
>>>    is online and the client is effectively running.
>>>    - Stolen access tokens give an attacker unfettered access to any
>>>    resource server that accepts it. Client hijacking forces the attacker to
>>>    play by the rules of the client. For example, an attacker can abuse a
>>>    stolen token with fake origin headers to access a resource server that
>>>    would accept the token, but has a CORS policy that rejects requests from
>>>    the client’s origin
>>>
>>>
>>> As stated before, the DPoP specification takes a similar point of view
>>> on these consequences. They explicitly aim to prevent the abuse of stolen
>>> tokens, while considering client hijacking to be out of scope (
>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop#name-objectives
>>> )
>>>
>>>
>>> On a sidenote, the term “session riding” seems to refer to CSRF, not to
>>> client hijacking. I have only learned this myself recently and have
>>> mis-used this term before as well. I wanted to point this out to avoid
>>> further confusion.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>> *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.*
>>>
>>> You also talk about “demonstrable” differences. I have shown examples
>>> (both in text and video) of these consequences in browser-only apps,
>>> resulting in the attacker obtaining both an access token and a refresh
>>> token. If you claim that BFFs are just the same, I invite you to
>>> demonstrate your 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.
>>>
>>>
>>> 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.
>>>
>>> This link points to the exact demo scenario in the video I have
>>> referenced before: https://youtu.be/OpFN6gmct8c?feature=shared&t=1366 It
>>> clearly shows how the attacker runs a new flow to obtain tokens, without
>>> ever touching the application’s tokens.
>>>
>>>
>>> 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.
>>>
>>>
>>> Using a SW for storage does not solve anything, since the attacker can
>>> simply request fresh tokens.
>>>
>>>
>>> My conclusion is that, though we can surely make the document better,
>>> there is no all-encompassing solution. Similarly, BFFs are not
>>> a higher level of security for healthcare of banks, just a different
>>> solution. Service workers are still an interesting solution for people who
>>> absolutely want to secure tokens at the frontend, and as improvable as
>>> the document is, shouldn't be left out.
>>>
>>>
>>> You, as the creator of the SW approach, have clearly stated that you
>>> don’t even use it in practice, so I don’t really understand the urge to
>>> make this a recommended pattern. On the contrary, BFFs are used in practice
>>> in a variety of scenarios.
>>>
>>> That said, the SW approach should indeed be mentioned in the document,
>>> to clearly illustrate the security considerations and limitations.
>>>
>>>
>>>
>>>
>>> About some specific concerns:
>>> > *While content injection attacks are still possible, the BFF limits
>>> the attacker’s ability to abuse APIs by constraining access through a
>>> well-defined interface to the backend which eliminates the possibility of
>>> arbitrary API calls.*
>>> Session riding is still the main issue and isn't addressed at all. If
>>> the intention here was to limit the number of exposed endpoints, the
>>> application can still be designed to either only expose what is needed, or
>>> put a proxy or api manager between for limiting exposition, unrelated to
>>> where token storage happen.
>>>
>>>
>>> No-one has ever stated that a BFF would solve the consequences of an
>>> attacker hijacking a client. However, when the attacker is forced to launch
>>> attacks through a client running in the user’s browser, they are forced to
>>> go through the BFF. That gives you a point of control which you *could* use
>>> to implement restrictions. This is not required to benefit from a BFF,
>>> since the main benefit is moving from a public client to a confidential
>>> client.
>>>
>>> You state that you can achieve the same by using a careful design of the
>>> application. However, you fail to mention what you consider the
>>> “application” and where exactly this restriction fits in. This is
>>> important, because once the attacker has exfiltrated access tokens, they
>>> can send arbitrary requests. If the resource servers are not fully shielded
>>> by an API manager, the attacker can contact them directly with a stolen
>>> token. And if you apply this close to the resource servers, how will you
>>> then configure them to only allow certain clients to access certain
>>> endpoints?
>>>
>>>
>>> *> 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. *
>>> The iframe needs to get the auth code somehow, and that typically
>>> happens by setting its src to the auth endpoint, and having a redirect URI
>>> that points to that minimal js page. This would mean an  attacker can
>>> change the redirect URI to be able to point to some custom js in the
>>> application, which is a whole different
>>>
>>> Philippe, I'm honestly quite skeptical about that attack, but it sounds
>>> interesting. Can you provide some details or a reproducer?
>>>
>>>
>>> In all honesty, my understanding that the Web Messaging approach was
>>> universally used turned out to be inaccurate. There are two concrete ways
>>> to run a silent authorization code flow: (1) using
>>> response_mode=web_message and (2) using the proper redirect URI. Both
>>> scenarios allow the attacker to obtain the authorization code by starting
>>> the flow with an authorization request that *is indistinguishable* from
>>> a request coming from the legitimate application.
>>>
>>> *Scenario 1 (web messaging)*
>>>
>>>
>>>    - The iframe src points to the authorize endpoint
>>>    - The AS does not redirect, but responds with an HTML page
>>>    containing JS code. This JS code uses postmessage to send a message
>>>    containing the authorization code to the main application context.
>>>    - The attacker receives this message and obtains the authorization
>>>    code
>>>
>>>
>>> This approach is used by Auth0 and Apple. I have tested my attack
>>> scenario against Auth0. Note that while this flow *does not use* the
>>> redirect URI, it does validate the provided redirect URI. Additionally, the
>>> admin needs to configure the AS to include the client’s origin in a list of
>>> “Allowed Web Origins”.
>>>
>>> This is also the scenario I use in the demo I have linked to above, so
>>> you can see it in action there.
>>>
>>>
>>> *Scenario 2 (redirect)*
>>>
>>>
>>>    - The iframe src points to the authorize endpoint
>>>    - The AS redirects the frame to the application’s callback with the
>>>    authorization code as a query parameter
>>>    - The attacker can monitor the iframe for a URL that contains the
>>>    authorization code, stop the frame from loading (and redeeming the
>>>    authorization code), and extract the code
>>>
>>>
>>> This approach is more universal, but just as vulnerable. The scenario is
>>> exactly the same as in the demo linked to above, but the attack code looks
>>> slightly different.
>>>
>>>
>>>
>>> To conclude, I have carefully argued my point of view on this mailing
>>> list, in recorded videos, and in the sessions at the OAuth Security
>>> Workshop last week. As far as I can tell, the experts in the community
>>> acknowledge the dangers of browser-only apps (i.e., the attacker running a
>>> silent flow)  and agree that the browser-based apps BCP should accurately
>>> reflect this information. We’re currently working on updating the
>>> specification (which will happen in multiple steps, so we ask for a bit of
>>> patience).
>>>
>>> Unless you have anything new to add or any new issues to raise, I
>>> respectfully opt to disengage from further discussion.
>>>
>>> Kind regards
>>>
>>> Philippe
>>>
>>>
>>
>> --
>> Yannick Majoros
>> Valuya sprl
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>