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
