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

[Yannick Majoros <[e-mail]>]

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 <[e-mail]> 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 <[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
>>>>
>>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> Vennlig hilsen
>
> Steinar Noem
> Partner Udelt AS
> Systemutvikler
>
> | [e-mail] | [e-mail]  | [phone] | www.udelt.no |
>


-- 
Yannick Majoros
Valuya sprl