Hi Philippe, I look forward to discussing this with you at the OAuth Security Workshop later this month. Like I mentioned to you last year, I want to make sure your concerns are adequately captured in the document.
The goal for this draft is not to present the one "best" architecture for browser-based apps, since as you mentioned, there are many different ways attacks can happen and different trade-offs with the different patterns. As to Brock's comment, the point of this draft is to document the existing established patterns *as well as their limitations* so that someone implementing OAuth in browser-based apps knows the limits of the pattern they are choosing. We are not saying that any given recommendation in this draft has no possible attack vectors, since that's not the reality of the world in browsers. Aaron On Thu, Aug 10, 2023 at 7:16 AM Brock Allen <brockal...@gmail.com> wrote: > I agree with Philippe here. > > If there are already documented attack vectors working around the > techniques presented in this document, then I worry it will give people a > false sense of security if they follow the guidance contained therein. > > -Brock > > On 8/10/2023 2:51:35 AM, Philippe De Ryck < > phili...@pragmaticwebsecurity.com> wrote: > In my opinion, *this document is not ready to be published as an RFC*. > > In fact, I will be at the OAuth Security Workshop in two weeks to discuss > exactly this (See "The insecurity of OAuth 2.0 in frontends" here: > https://oauth.secworkshop.events/osw2023/agenda-thursday). My hope is > that my presentation can spark the necessary discussion to identify a path > forward to make the RFC useful for practitioners building browser-based > apps. > > I don't have the resources available to write a lengthy email detailing my > objections. I just want to point out that I've raised these points on the > mailing list in the past, and there have been a couple of threads on this > very list suggesting how to move this document forward (e.g., identify > concrete threat models). I've also given a talk at NDC Security earlier > this year (https://www.youtube.com/watch?v=OpFN6gmct8c) about how the > security mechanisms proposed in this document fall short. This video has > been posted to this list before as well. > > Here are a couple of suggestions that I believe would improve this > document: > > - Clearly identify the danger of malicious JS (exfiltrating existing > tokens is only one threat, and the most trivial one at that) > - State the baseline achievable level of security in light of existing XSS > vulnerabilities (i.e., session riding, where the attacker controls the > frontend) > - Identify different desired levels of security for a client application > (e.g., a "public recipe app" vs "eHealth"). Existing work can help, such as > the OWASP ASVS levels ( > https://github.com/OWASP/ASVS/blob/master/4.0/en/0x03-Using-ASVS.md) > - Define which levels of security certain mechanisms can offer (e.g., RTR > for level 1, TMI-BFF for level 2, BFF for level 3) > - Remove unproven and overly complicated solutions (i.e., the service > worker approach) > > As stated before, I'll be at OSW in London in 2 weeks and would be happy > to discuss this further. > > Kind regards > > Philippe > > — > *Pragmatic Web Security* > *Security for developers* > https://pragmaticwebsecurity.com > > On 30 Jul 2023, at 17:46, Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> > wrote: > > All, > > This is a *WG Last Call *for the* Browser-based Apps* draft. > https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-14.html > > Please, review this document and reply on the mailing list if you have any > comments or concerns, by *August 11th*. > > Regards, > Rifaat & Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
