Answers inline to add the proper nuance. > Would you not agree that a "good" CSP config is a good line of defense > against XSS attacks?
A good CSP policy can indeed help to stop the exploitation of an XSS vulnerability, should one exist in the application. I do not agree with the wording “a good line of defense”, as it can imply that a good CSP policy can be used as the only defense. XSS vulnerabilities are first and foremost avoided by adopting secure coding guidelines. CSP acts as a second line of defense, in case an XSS vulnerability still slips through. > I agree that the OAuth BCP should not provide details on CSP config. I do > think we should call out having a considered CSP config is a best practice. > > I differentiate between headers and cookies and SQL injection etc. in that > the headers and cookies are part of the HTTP requests, which is the protocol > OAuth is built on, so weaknesses there weaken the protocol. Just because CSP can be configured as a header (CSP can also be set with a <meta> tag) does not make it part of the protocol OAuth is built on. CSP is 100% an application-level feature. And as useful as CSP can be, I would not consider “not having CSP” as a protocol weakness. I’m not strongly against mentioning CSP, I’m just wondering how much good it does given the complexity of configuring CSP correctly. It suffices to include a CDN that hosts a version of AngularJS 1.x to have a bypassable (and thereby mostly useless) CSP policy. Philippe > > On Mon, Nov 6, 2023 at 11:25 AM Philippe De Ryck > <phili...@pragmaticwebsecurity.com > <mailto:phili...@pragmaticwebsecurity.com>> wrote: > I went back to the Security BCP and combed through the fine details, and > there is indeed some guidance on CSP. But your initial remark that this is > "vague" is definitely true, and this section is actually a good illustration > of what I was trying to say. Let me unpack the details a bit … > > In section 4.16, the security BCP talks about how to restrict framing to > avoid clickjacking/UI redressing attacks. Defending against such attacks > cannot be done with secure coding, but must be done with specific framing > restrictions. The best mechanism to achieve this is by setting security > headers: the legacy X-Frame-Options header or the more modern CSP > frame-ancestors directive. Given that this security requirement is closely > linked to OAuth and is not something that “happens naturally”, but must be > explicitly added, I totally agree that this should be part of the security > BCP. > > Now, in paragraph 5 of the section, things get somewhat confusing (included > below for reference). So far, every mention of "CSP" was used as a synonym > for the "frame-ancestors" directive to restrict framing. However, all the way > at the end of that paragraph, the text suddenly recommends using the > "script-src" directive to restrict sources of JS that can execute on the > page. The paragraph then points to a sample header, with the configuration of > "script-src 'self'". > > Using CSP allows authorization servers to specify multiple origins in a > single response header field and to constrain these using flexible patterns > (see [W3C.CSP-2 <https://www.w3.org/TR/CSP2>] for details). Level 2 of this > standard provides a robust mechanism for protecting against clickjacking by > using policies that restrict the origin of frames (using frame-ancestors) > together with those that restrict the sources of scripts allowed to execute > on an HTML page (by using script-src). > > Unfortunately, this advice is too simplistic to be useful, as it prevents the > loading of JS from any other origin, including CDNs, or third-party services. > Additionally, it violates modern best practices for CSP, which recommend the > use of hashes, nonces, and trust propagation (with nonce propagation or > 'strict-dynamic'). If you’re interested in the details, I’ve done a few guest > blog posts about CSP for Auth0 that cover this: > https://auth0.com/blog/authors/philippe-de-rick/ > <https://auth0.com/blog/authors/philippe-de-rick/> > > > What I'm trying to say here is that a detailed CSP config (apart from the > "frame-ancestors" directive) is not essential for a secure OAuth > implementation or deployment. It can and should act as a second line of > defense against content injection attacks, but not having such a CSP config > does not automatically create a vulnerability. Therefore, my recommendation > is to focus on the details directly relevant to OAuth security. > > For security guidelines for configuring cookies, I believe this would be more > directly related and more useful, as I mentioned before. > > Finally, I can totally see that the community could benefit from more > in-depth security best practices that go beyond OAuth-specific risks. Apart > from CSP, there's a whole bunch more response headers that can be configured > (as you and others have mentioned). On top of that, modern browsers send a > lot of metadata in a request (e.g., the Sec-Fetch Metadata headers) that > could be used by the AS to reject illegitimate requests. However, given the > rapid development of these features and lack of widespread support, I would > envision such recommendations to live in a more "dynamic" document than an > RFC. > > Philippe > > — > Pragmatic Web Security > Security for developers > https://pragmaticwebsecurity.com <https://pragmaticwebsecurity.com/> > >> On 6 Nov 2023, at 18:07, Dick Hardt <dick.ha...@gmail.com >> <mailto:dick.ha...@gmail.com>> wrote: >> >> That's a surprising response Philippe. The BCP already has >> Content-Security-Policy and Referrer-Policy headers recommendations. The >> core of my feedback is to add Cookie and Header best practices to Section 2, >> and point to one or more living documents. >> >> On Mon, Nov 6, 2023 at 8:45 AM Philippe De Ryck >> <phili...@pragmaticwebsecurity.com >> <mailto:phili...@pragmaticwebsecurity.com>> wrote: >> While I understand the idea of pointing to additional security resources, >> I’m not sure if it is the role of the security BCP (or other specs) to take >> on the responsibility to address these issues. In my point of view, the >> security BCP should focus on OAuth aspects, and discuss security topics that >> are directly relevant to that purpose. >> >> Concretely for the security mechanisms discussed here, I can see how cookie >> configurations could be relevant (the session with the AS is inherent to >> OAuth), but I don’t see defenses such as CSP as relevant in that scope. If >> these are in scope, should we then also provide advice or pointers on >> avoiding server-side implementation vulnerabilities, such as SQL injection >> or SSRF? >> >> Additionally, many of these security mechanisms are quite complex and >> non-trivial to deploy. For example, adding a generic pointer stating “you >> should add CSP” does not say much, as CSP can control more than a dozen >> features. >> >> To summarize, I would keep the scope of these specs as narrow as possible >> and avoid aiming to address security concerns that are beyond the realm of >> OAuth. >> >> Philippe >> >> — >> Pragmatic Web Security >> Security for developers >> https://pragmaticwebsecurity.com <https://pragmaticwebsecurity.com/> >> >>> On 6 Nov 2023, at 15:39, Dick Hardt <dick.ha...@gmail.com >>> <mailto:dick.ha...@gmail.com>> wrote: >>> >>> +1 to referring to calling out that cookies / headers should follow best >>> security practice, and pointing to living documents >>> >>> On Mon, Nov 6, 2023 at 6:21 AM Giuseppe De Marco <demarco...@gmail.com >>> <mailto:demarco...@gmail.com>> wrote: >>> Hi, >>> >>> everytime I have implemented SAML2, OAuth 2.0, OpenID Connect, for >>> different projects and orgs, I have included secured web cookie in the >>> recipe. >>> For the implementation profile of OpenID4VP I did the same, where the >>> secured and httponly cookie is used an in particular as a basic security >>> requirement for the cross device flow [1]. >>> >>> Even if I got perfectly Daniel's and Aaron's editorial strategy and I >>> agree, I think that Dick's proposal and your confirmation on that, Neil, is >>> something to take into account to bring developers awareness during the >>> implementation phases. >>> A ref to living OWASP specs surrounded by a generic refs to the user agent >>> security, even if out of scope, I think that should be in the specs. >>> >>> [1] >>> https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/relying-party-solution.html#remote-protocol-flow >>> >>> <https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/relying-party-solution.html#remote-protocol-flow> >>> Il giorno lun 6 nov 2023 alle ore 15:11 Neil Madden >>> <neil.e.mad...@gmail.com <mailto:neil.e.mad...@gmail.com>> ha scritto: >>> Although I think we could add some basic advice, the list of security >>> headers to use is still evolving. For example, there were several headers >>> added after Spectre to limit cross-site interactions. And then there’s >>> things like the “X-XSS-Protection” header, which was best practice to add >>> to responses not too long ago but has now been universally removed from >>> browsers as it enabled certain content disclosure attacks. >>> >>> Cookie security attributes are perhaps a bit more stable, but in general we >>> probably just want to point people at “living” guidance like OWASP. >>> >>> — Neil >>> >>>> On 5 Nov 2023, at 19:28, Dick Hardt <dick.ha...@gmail.com >>>> <mailto:dick.ha...@gmail.com>> wrote: >>>> >>>> The cookie and header recommendations I am thinking of would be for the AS >>>> as well as the client. >>>> >>>> A number of XSS attacks can be thwarted by a modern browser and the right >>>> HTTP headers. >>>> >>>> My question is: Did the authors consider adding cookie and header >>>> recommendations, and decided it was too general? >>>> >>>> Cookie and header best security practices have been around for years -- >>>> I'm not suggesting we make anything up -- I'm suggesting we raise >>>> awareness. >>>> >>>> I consider myself to be fairly security aware, and I was not aware of some >>>> of the HTTP headers that are best security practice. >>>> >>>> /Dick >>>> >>>> >>>> On Sun, Nov 5, 2023 at 11:19 AM Aaron Parecki >>>> <aaron=40parecki....@dmarc.ietf.org <mailto:40parecki....@dmarc.ietf.org>> >>>> wrote: >>>> I don't think it's necessary to say "do the right things with cookies" in >>>> the Security BCP. The Browser Apps BCP has a much deeper discussion of how >>>> different browser-based architectures work with cookies so that seems like >>>> a better place to actually have a real discussion about it. >>>> >>>> Also +1 to what Daniel said about not continuing to add little things. >>>> Plus I think it's too late anyway, publication has already been requested >>>> for the Security BCP. >>>> >>>> Aaron >>>> >>>> On Sun, Nov 5, 2023 at 11:14 AM Daniel Fett >>>> <fett=40danielfett...@dmarc.ietf.org >>>> <mailto:40danielfett...@dmarc.ietf.org>> wrote: >>>> I agree with Aaron! >>>> >>>> Also we should be very careful about any additions to the Security BCP at >>>> this point. It is very easy to re-start the "one more thing" loop we've >>>> been stuck in for the last years. There may be more useful things to say, >>>> but we should put them on the list for a future second version of the BCP. >>>> >>>> -Daniel >>>> >>>> Am 05.11.23 um 20:03 schrieb Aaron Parecki: >>>>> I don't think the Security BCP should incorporate cookie best practices >>>>> directly in the document. If anything, it sounds like possibly a >>>>> candidate for inclusion in the Browser Apps BCP. >>>>> >>>>> There are already some mentions of these cookie properties mentioned in >>>>> the Browser Apps BCP, though only in reference to specific architectures, >>>>> not as a general best practice. For example: >>>>> >>>>> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security >>>>> >>>>> <https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security> >>>>> >>>>> Aaron >>>>> >>>>> On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt <dick.ha...@gmail.com >>>>> <mailto:dick.ha...@gmail.com>> wrote: >>>>> Hey >>>>> >>>>> I was reviewing security on some sites I managed and checked to see if >>>>> the recommendations were in the BCP. >>>>> >>>>> I don't see anything around cookies such as httpOnly, sameSite, secure. >>>>> >>>>> I saw some HTTP security header suggestions buried in 4.16 >>>>> (X-Frame-Options, CSP), but not for Strict-Transport-Security, >>>>> Permissions-Policy, or X-Content-Type-Options, and the CSP guidance is >>>>> rather vague. >>>>> >>>>> I understand these are general web security best practices, and perhaps I >>>>> missed it, but I think it would be useful to call out that best security >>>>> practices around cookies and headers should also be followed in Section >>>>> 2, and either have the best practices included, or direct the reader >>>>> where to find them. >>>>> >>>>> /Dick >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
