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 Il giorno lun 6 nov 2023 alle ore 15:11 Neil Madden <[email protected]> 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 <[email protected]> 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= > [email protected]> 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= >> [email protected]> 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 >>> >>> Aaron >>> >>> On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt <[email protected]> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> _______________________________________________ >>> OAuth mailing [email protected]https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
