Makes sense, thanks. > On 18 Mar 2021, at 22:55, Brian Campbell <bcampb...@pingidentity.com> wrote: > > > Thanks Neil. I'll look at incorporating that guidance. Although I think > referencing might be more appropriate than incorporating directly. > >> On Mon, Mar 15, 2021 at 3:44 AM Neil Madden <neil.mad...@forgerock.com> >> wrote: >> There is now a draft from the W3C explicitly addressing Spectre and its >> impacts on web security. I think we should aim to incorporate the guidance >> for “dynamic subresources” [1], and in particular the first item in the >> list, which is recommendations for "Application-internal resources (private >> API endpoints …)”. The recommended response headers given are: >> >> Cross-Origin-Resource-Policy: same-origin >> Content-Security-Policy: sandbox >> Cross-Origin-Opener-Policy: same-origin >> Vary: Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site >> X-Content-Type-Options: nosniff >> X-Frame-Options: DENY >> >> Cheers, >> >> Neil >> >> [1]: >> https://w3c.github.io/webappsec-post-spectre-webdev/#dynamic-subresources >> >>> On 20 Feb 2021, at 09:07, Neil Madden <neil.mad...@forgerock.com> wrote: >>> >>> I was mentioning it primarily as another example of the assumption that GET >>> requests are safe. However, the draft rfc6265bis [1] does seem concerned >>> about this, and mentions <link rel=prerender> as a possible attack vector. >>> This would again potentially pull the access token into the renderer’s >>> memory space (until site isolation becomes widespread). >>> >>> I also have a general dislike of SameSite cookies as a defence against >>> CSRF. There are CSRF-like attacks that are not strictly cross-*site* but >>> are cross-origin (CORF?). For example, subdomain hijacking is relatively >>> common [2] and completely defeats SameSite. As the draft itself says [3]: >>> >>> <quote> >>> >>> "SameSite" cookies offer a robust defense against CSRF attack when >>> deployed in strict mode, and when supported by the client. It is, >>> however, prudent to ensure that this designation is not the extent of >>> a site's defense against CSRF, as same-site navigations and >>> submissions can certainly be executed in conjunction with other >>> attack vectors such as cross-site scripting. >>> >>> Developers are strongly encouraged to deploy the usual server-side >>> defenses (CSRF tokens, ensuring that "safe" HTTP methods are >>> idempotent, etc) to mitigate the risk more fully. >>> </quote> >>> >>> If we recommend SameSite for this, IMO we should do so only with the same >>> caveats expressed in the httpbis draft. >>> >>> [1]: >>> https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07#section-5.3.7.1 >>> [2]: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers# >>> [3]: >>> https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07#section-8.8.1 >>> >>> Cheers, >>> >>> Neil >>> >>>>> On 19 Feb 2021, at 23:18, Brian Campbell <bcampb...@pingidentity.com> >>>>> wrote: >>>>> >>>> >>>> Thanks Neil, >>>> Appreciate the insight and recommendations. I think we can incorporate >>>> that, more or less, into the next revision. >>>> One point to dig into just a bit more, you said that 'SameSite has a >>>> "GET-out clause" in the form of “lax”'. As I understand it, such a cookie >>>> would still only be sent on a cross-site GET resulting from a top-level >>>> navigation. And in the context of the bff-token endpoint, that >>>> significantly reduces the ways a cross-site request could be initiated and >>>> those ways (pop-up or full page redirection) further limits the likelihood >>>> of the malicious party being able to read response data. >>>> >>>>> On Thu, Feb 18, 2021 at 5:08 AM Neil Madden <neil.mad...@forgerock.com> >>>>> wrote: >>>>> Thanks for following up, Brian. Responses below. >>>>> >>>>>> On 17 Feb 2021, at 22:48, Brian Campbell <bcampb...@pingidentity.com> >>>>>> wrote: >>>>>> >>>>>> Always appreciate (and often learn from) your insights, Neil. I'd like >>>>>> to dig into the CSRF thing a bit more though to understand better and >>>>>> hopefully do the right thing in the draft. >>>>>> >>>>>> It seems to me that a GET at the bff-token endpoint is "safe" in that >>>>>> it's effectively just a read. >>>>> >>>>> Well it’s a read that returns an access token. It’s “safe” in the sense >>>>> of side-effects, but we absolutely want to preserve the confidentiality >>>>> of what is returned and only allow it to be accessed by authorized >>>>> clients (the legitimate frontend). At the moment the only thing keeping >>>>> that safe is the JSON content type. For example, imagine a world in which >>>>> the token-bff endpoint instead returned the access token as HTML: >>>>> >>>>> <div id=“accessToken”>abcd</div> >>>>> >>>>> Then as an attacker I can simply embed an iframe on my site that refers >>>>> to your bff-endpoint and then parse the access token out of the DOM. The >>>>> browser will happily load that iframe and send along the cookie when it >>>>> makes the request. If you have CORS enabled on your site (with >>>>> Access-Control-Allow-Credentials) then any of the allowed CORS origins >>>>> can directly call the bff-token endpoint and read the access token even >>>>> in JSON form. There have also been historical same-origin policy bypasses >>>>> using Flash, Adobe Reader, or other plugins (thankfully now largely >>>>> eliminated), or by redefining JavaScript prototypes - see >>>>> https://haacked.com/archive/2009/06/25/json-hijacking.aspx/ . These are >>>>> largely fixed, but I wouldn’t bet on there never being another one. >>>>> >>>>> >>>>>> There could be a "cache miss" where the backend attempts to use a >>>>>> refresh token it has to get a new access token from the remote AS, which >>>>>> will be more resource intensive but doesn't fundamentally alter the >>>>>> state of the backend so is still "safe". That in conjunction with your >>>>>> pointing to Cross-Origin Read Blocking makes me think your concern isn't >>>>>> so much about traditional CSRF used to take some malicious action but >>>>>> rather about somehow (speculative side-channel attacks, problems with >>>>>> javascript interpreters, other similar vectors that are somewhat beyond >>>>>> me) accessing the data of the response to a forged cross site request. >>>>>> Correct me if I'm wrong. I don't know if or how much the distinction >>>>>> matters in terms of mitigation approach but I'm keen to better >>>>>> understand. >>>>> >>>>> As explained above, because the endpoint returns JSON it _should_ be >>>>> impossible to directly read the response from a cross-origin read (unless >>>>> explicitly enabled with CORS). But you may still be able to embed that >>>>> response in an <img> or similar. Because people are terrible at setting >>>>> correct Content-Type headers on responses, browsers often ignore them and >>>>> instead try to sniff what the real content type is: so if the response >>>>> looks a bit like a valid image format (or PDF or JavaScript or whatever) >>>>> then it might try and render it. No doubt this will fail, but at that >>>>> point the data has already been loaded into the address space of the >>>>> renderer process for the attacker’s site. That means that it is then >>>>> vulnerable to attacks like Spectre that bypass normal memory protection. >>>>> The browser vendors consider this to be a real threat, hence CORB. >>>>> >>>>> The most important thing for a cookie-based JSON API to do is to return a >>>>> correct Content-Type header and to also return X-Content-Type-Options: >>>>> nosniff to prevent browsers from trying to sniff the real content-type. >>>>> (I have an example in my book where the failure to do this can actually >>>>> turn a JSON API into a vector for XSS attacks, even if you have no SPA >>>>> frontend component at all). >>>>> >>>>> (You should also mark the cookie as HttpOnly because this prevents the >>>>> cookie ever entering the address space of a renderer process in modern >>>>> browsers - an actual genuine security benefit of HttpOnly cookies). >>>>> >>>>> But my worry is that this is still basically trusting the client to >>>>> perform critical security checks, and historically browsers have had >>>>> plenty of bypasses in this area. So for something as high-value as an >>>>> access token I’d prefer that any request using cookie-based >>>>> authentication is protected by proactive CSRF defences to prevent >>>>> malicious requests being allowed in the first place. >>>>> >>>>>> >>>>>> It sounds like your preference for only POST rests in an assumption that >>>>>> the larger app will already have in place some CSRF defenses and by >>>>>> using POST the bff-token endpoint will basically inherit said defenses. >>>>>> Or is POST by itself good enough (the CORB writeup seems to suggest that >>>>>> the context in which a POST could be made is more guarded against side >>>>>> channel stuff)? But perhaps then the draft should be more explicit >>>>>> about CSRF defense? Saying it just has to be done. Or like even >>>>>> mandating a non-standard header be in the request, >>>>>> "X-Neil-says-beware-CSRF: yuppers" as a strawman. With such a header it >>>>>> could remain a GET. And I kinda like GET because it is really a request >>>>>> for data. Or perhaps the request should be a POST with built-in CSRF >>>>>> protection by changing it to carry any parameters as JSON in the body >>>>>> with "{}" for the case of no parameters specified? Or just make it a >>>>>> PUT and call it good? Not sure any of these are good ideas but just >>>>>> trying to hash out the most appropriate thing to do. >>>>> >>>>> Right, the preference for POST is because it's more likely to trigger >>>>> CSRF defences, which often consider GET/HEAD requests to be “safe”. Even >>>>> before Spectre, there is a whole array of side-channel attacks for >>>>> extracting information from cross-site responses: https://xsleaks.dev . >>>>> Note that even SameSite has a "GET-out clause" in the form of “lax”. >>>>> >>>>> So yes, the real requirement is that the endpoint should have adequate >>>>> CSRF protection. Requiring a special header has had bypasses in the past >>>>> (again, mostly using Flash). >>>>> >>>>> So I think we should recommend the following: >>>>> >>>>> 1. The response MUST contain a correct Content-Type: application/json >>>>> header and X-Content-Type-Options: nosniff. >>>>> 2. The cookie SHOULD be marked as HttpOnly. >>>>> 3. The endpoint MUST NOT be accessible via CORS. >>>>> 4. The endpoint SHOULD have adequate CSRF protections in place. At a >>>>> minimum the cookie should be marked as SameSite. >>>>> >>>>> We could perhaps add an informational reference to >>>>> https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html >>>>> given that there is a changing landscape around cookies at the moment. >>>>> If the browser vendors do eliminate 3rd-party cookies then 1, 3, and 4 >>>>> become largely unnecessary (although 3 might still be a risk due to >>>>> sub-domain hijacking, and 1 will always be good practice). >>>>> >>>>> — Neil >>>>> >>>>>> >>>>>> That got a little rambly, sorry. But hopefully it makes some sense. >>>>>> >>>>>>> On Sun, Feb 14, 2021 at 1:17 AM Neil Madden <neil.mad...@forgerock.com> >>>>>>> wrote: >>>>>>> >>>>>>> The combination of the bff-token endpoint recommending the use of GET >>>>>>> requests together with the hint to use cookie-based authentication is >>>>>>> likely going to punch a hole in most CSRF defenses, which assume that >>>>>>> GETs are safe. The only thing preventing this being exploitable is >>>>>>> Cross-Origin Read Blocking >>>>>>> (https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md) >>>>>>> due to the JSON content-type. That makes me really nervous. We should >>>>>>> at least mandate X-Content-Type-Options: nosniff on that response. I’d >>>>>>> feel more comfortable if this was a POST request only. >>>>>>> >>>>>>> — Neil >>>>>>> >>>>>> >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>> privileged material for the sole use of the intended recipient(s). Any >>>>>> review, use, distribution or disclosure by others is strictly >>>>>> prohibited. If you have received this communication in error, please >>>>>> notify the sender immediately by e-mail and delete the message and any >>>>>> file attachments from your computer. Thank you. >>>>> >>>>> >>>>> ForgeRock values your Privacy >>>> >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged >>>> material for the sole use of the intended recipient(s). Any review, use, >>>> distribution or disclosure by others is strictly prohibited. If you have >>>> received this communication in error, please notify the sender immediately >>>> by e-mail and delete the message and any file attachments from your >>>> computer. Thank you. >> >> >> ForgeRock values your Privacy > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately by > e-mail and delete the message and any file attachments from your computer. > Thank you.
-- ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
