I will follow up with you off-list to chat further, thanks! Aaron
On Thu, Jun 16, 2022 at 5:50 AM Yannick Majoros <yann...@valuya.be> wrote: > Hello Aaron, > > I'd be happy to contribute. What would be an appropriate time to talk > about this? > > Thanks > > Le jeu. 16 juin 2022 à 04:56, Aaron Parecki <aa...@parecki.com> a écrit : > >> These are exactly the kinds of things I would expect to see in the >> Browser-based app BCP. There isn't one best way to do things, but it's >> worth pointing out the options and the tradeoffs of each. Some people may >> not share the same concerns as others, but it's useful to point out the >> different options and the tradeoffs. If you're willing to contribute to the >> doc, I'd be happy to set up some time to talk offline about how to make >> that happen. >> >> Aaron >> >> >> On Wed, Jun 15, 2022 at 4:08 AM Yannick Majoros <yann...@valuya.be> >> wrote: >> >>> Hello, >>> >>> >>Best practices according to whom? >>> >>> >This list, and documents such as: >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics >>> >>> According to the explanation about rfc-6749 / oauth 2.1 and the PKCE >>> example, it seems that document would indeed be the right place to document >>> security issues and their workarounds. >>> >>> But I don't see any justification for section 6 in that document (which >>> is also a draft BTW). That document seems to not say much about token >>> storage, unless I'm mistaken. >>> >>> I am aware of discussions about potential issues about in-browser token >>> storage and the risks they involve, mostly in case of successful XSS. As >>> you all know, the point is also quite controversial, as there are also >>> voices arguing that this isn't the main attention point: in case of XSS, >>> the user is actually impersonated anyway and actually getting hold of the >>> token is a moot point, as accessing all protected resources is then >>> trivial, the client having all necessary technical means for that. >>> >>> If protecting tokens from the client (typically, javascript frontend) >>> after successful XSS is still a point, which it seems to be for some people >>> according to various widespread resources (though not universally so), >>> there are options for that which are at least as secure as a stateful BFF. >>> >>> For example, a service worker can effectively isolate tokens and call a >>> resource server in a safe way, with the frontend having no token access at >>> all: >>> [image: image.png] >>> >>> OTOH, a commonly (though not consensual) recommended solution is a >>> stateful BFF. Popular common sense is that it's safe to leakage because of >>> HTTPOnly cookies, but that's actually not the case. Here is an example of >>> exploit, once XSS has happened (which is the actual problem, not >>> javascript-accessible token storage): >>> [image: image.png] >>> This attack isn't even specific to HTTPOnly cookies: it can be made to >>> target any form of secret (tokens or cookies) in an *authorization code* >>> flow. But this illustrates that cookies aren't inherently safer than, say, >>> a *service worker*. >>> >>> For these reasons, I suggest: >>> - documenting that kind of security issues in the *OAuth 2.0 Security >>> Best Current Practice* document >>> - recommend more alternatives (e.g. service/web workers, among others), >>> or instead even focusing attention on XSS >>> - rewriting section 6 to not mislead people into thinking that pure >>> frontend / pure SPA solutions are inherently less safe than cookie-based >>> approaches. >>> - generally focusing on documenting attacks and countermeasures, as >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics is >>> doing quite well :-) >>> >>> How can we improve the current situation? Would it be useful to list and >>> detail some attacks that are not documented in the *OAuth 2.0 Security >>> Best Current Practice* document? Would submitting a new draft for >>> frontends be a good idea? >>> >>> Best regards, >>> >>> Yannick Majoros >>> >>> Le mer. 15 juin 2022 à 04:11, Dick Hardt <dick.ha...@gmail.com> a >>> écrit : >>> >>>> >>>> >>>> Best practices according to whom? >>>> >>>> >>>> This list, and documents such as: >>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics >>>> >>>> Wouldn't the concerns of section 6 of your draft better be parts of a >>>> follow-up or addendum to rfc-6749? >>>> >>>> >>>> OAuth 2.1 has no normative changes over OAuth 2.0, and includes all the >>>> docs and learnings that have come out since OAuth 2.0 was published. >>>> >>>> Creating a new version allows implementors to reference OAuth 2.1 and >>>> deployments will know that it is compliant with all the learnings rather >>>> than having to reference numerous, sometimes conflicting documents. >>>> >>>> A good example is PKCE -- it is best practice and deals with the >>>> security concerns -- but trying to understand what to do reading both 6749 >>>> and 7636 is non-trivial for many. >>>> >>>> While adding an addendum would solve a few of the issues addressed by >>>> the 2.1 doc -- the WG decided that the 2.1 doc was the approach to take. >>>> >>>> /Dick >>>> >>>> On Tue, Jun 14, 2022 at 12:12 AM Yannick Majoros <yann...@valuya.be> >>>> wrote: >>>> >>>>> Hello Aaron and anyone in the group, >>>>> >>>>> Could you further comment on my last email? >>>>> >>>>> I'd have an additional question: in >>>>> https://datatracker.ietf.org/doc/html/rfc6749#section-10 there is a >>>>> list of security considerations. Wouldn't the concerns of section 6 of >>>>> your >>>>> draft better be parts of a follow-up or addendum to rfc-6749? >>>>> >>>>> Thanks, >>>>> >>>>> Yannick >>>>> >>>>> >>>>> Le sam. 11 juin 2022 à 20:55, Yannick Majoros <yann...@valuya.be> a >>>>> écrit : >>>>> >>>>>> >> There is a lot of debate around the question. Are these really >>>>>> security best practices? >>>>>> >The intent of this draft is to document the best practices today. If >>>>>> >anything in the document is not the best way to do something given >>>>>> the >>>>>> >documented constraints, then that should be revisited. >>>>>> >>>>>> Best practices according to whom? There are various opinions on the >>>>>> subject, it's not black and white, so wouldn't it be best to be factual, >>>>>> e.g. describing attack X and counter-measures, and how solution Y is the >>>>>> best known tradeoff for that case. >>>>>> >>>>>> I indeed suggest section 6 to be revisited, as this the options >>>>>> described there are neither universally agreed upon, neither the >>>>>> best/only >>>>>> options to secure an application. >>>>>> >>>>>> I'd be happy to contribute, btw. I'm in the process of completing a >>>>>> kind of matrix which associates all known options (BFF, local/session >>>>>> storage/service worker/web worker/closure/token in a cookie/...), the >>>>>> security issues involved and their impact. I do also have POCs and >>>>>> further >>>>>> documentation for each solution, along with attack descriptions and their >>>>>> mitigations. >>>>>> >>>>>> > Did you consider using a service worker or other frontend solutions >>>>>> (web worker, closure...) for safe token storage? That would make a pure >>>>>> frontend solution at least as safe as cookies. >>>>>> >>>>>> This has been on my list to write up as another option. >>>>>> >>>>>> Great. I'd be interested in providing input here. Would it be useful? >>>>>> >>>>>> >> What if the backend is stateless and so doesn't have any session >>>>>> >You would need to use an encrypted session cookie to avoid storing >>>>>> >server-side state, but this is available in many web frameworks. >>>>>> >>>>>> Isn't that encrypted session cookie a kind of token? :-) Is this a >>>>>> best practice? >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Yannick >>>>>> >>>>>> Le ven. 10 juin 2022 à 23:02, Aaron Parecki <aa...@parecki.com> a >>>>>> écrit : >>>>>> >>>>>>> Hi Yannick, answers inline: >>>>>>> >>>>>>> > There is a lot of debate around the question. Are these really >>>>>>> security best practices? >>>>>>> >>>>>>> The intent of this draft is to document the best practices today. If >>>>>>> anything in the document is not the best way to do something given >>>>>>> the >>>>>>> documented constraints, then that should be revisited. >>>>>>> >>>>>>> > Did you consider using a service worker or other frontend >>>>>>> solutions (web worker, closure...) for safe token storage? That would >>>>>>> make >>>>>>> a pure frontend solution at least as safe as cookies. >>>>>>> >>>>>>> This has been on my list to write up as another option. >>>>>>> >>>>>>> > Why would a cookie be safer, as this opens CSRF attacks that would >>>>>>> make the same actions available to a hacker that would be possible by >>>>>>> getting hold of a token (which might even be more difficult)? >>>>>>> >>>>>>> The assumption is that you would also protect against CSRF attacks >>>>>>> like any typical web application. >>>>>>> >>>>>>> > What if the backend is stateless and so doesn't have any session >>>>>>> >>>>>>> You would need to use an encrypted session cookie to avoid storing >>>>>>> server-side state, but this is available in many web frameworks. >>>>>>> >>>>>>> Aaron >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 10, 2022 at 5:12 AM Yannick Majoros <yann...@valuya.be> >>>>>>> wrote: >>>>>>> > >>>>>>> > Hello, >>>>>>> > >>>>>>> > Regarding "OAuth 2.0 for Browser-Based Apps" section 6 ( >>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-09#section-6 >>>>>>> ), I do have some questions and concerns. Can I get in touch with >>>>>>> someone >>>>>>> about this? >>>>>>> > >>>>>>> > My main questions are: >>>>>>> > - There is a lot of debate around the question. Are these really >>>>>>> security best practices? >>>>>>> > - Did you consider using a service worker or other frontend >>>>>>> solutions (web worker, closure...) for safe token storage? That would >>>>>>> make >>>>>>> a pure frontend solution at least as safe as cookies. >>>>>>> > - Why would a cookie be safer, as this opens CSRF attacks that >>>>>>> would make the same actions available to a hacker that would be >>>>>>> possible by >>>>>>> getting hold of a token (which might even be more difficult)? >>>>>>> > - What if the backend is stateless and so doesn't have any session >>>>>>> (which defeats 6.1 & 6.2 and leaves no option according to current >>>>>>> draf)? >>>>>>> > >>>>>>> > Best regards. >>>>>>> > >>>>>>> > Yannick Majoros >>>>>>> > Valuya sprl >>>>>>> > _______________________________________________ >>>>>>> > OAuth mailing list >>>>>>> > OAuth@ietf.org >>>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Yannick Majoros >>>>>> Valuya sprl >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Yannick Majoros >>>>> Valuya sprl >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>> >>> -- >>> Yannick Majoros >>> Valuya sprl >>> >>> > > -- > Yannick Majoros > Valuya sprl > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
