+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 <[email protected]> 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 > > 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
