Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Brian Campbell <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
> wrote:
>
>> Thanks for following up, Brian. Responses below.
>>
>> On 17 Feb 2021, at 22:48, Brian Campbell <[e-mail]>
>> 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 <[e-mail]>
>> 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 <https://www.forgerock.com/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>

-- 
_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._