From nobody Thu Feb 18 04:09:05 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1D73A115C for ; Thu, 18 Feb 2021 04:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4R5lysKvlyo for ; Thu, 18 Feb 2021 04:09:01 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5313A1157 for ; Thu, 18 Feb 2021 04:09:00 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id x16so3174434wmk.3 for ; Thu, 18 Feb 2021 04:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KL3tWaqWBrfGEbwDTz6bwdIVuh91yQTexkEKm+eZC4c=; b=ZLOlf2392heqIVZrj43jesCmzTjtjTSRnVePXxAORIxLjonD1KS39EbuFMSvs7Zlex RJsCe5Fcb5qBzskYxGeMnKA7eY5M1qsaK7jdpD1yHxwBd2DcQUfha1mLOKqCFcXqsGNR bmwtwx8QKRcH/WlHXNeRZ08Bo/L/qjWY2BUQU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KL3tWaqWBrfGEbwDTz6bwdIVuh91yQTexkEKm+eZC4c=; b=S8aPPP9PZui2ecMSkdgOcWtLr/8FDidfPaqzTotVdJCaowPMMHUYuDj9I1pUyJkvIo ans2VhobPdJkaXc/uDDUxULYB/44iT3dFAs3S9KWlmbJ580Y/9DUMAUFmOWergFi7MAG eVk3aISsrSW5dn2Vv3E357NZ3Ft1wwmWIwEmY3qDtSNj1zX+yvR1wiUeAEED8YsCSY6C 9ovLWsMflvt9IqJd49ed/iJIIOdxrQjqMCFfuAQfaDbSM1eIdpGKqYUrHsp3ke3g9fjw g/d6tOuaU8jetPh72C8J5xL3S5InSOs+uMNfKe9iMAS6KLPyIYn4OhWeiH3XtzYMiPAY ECuQ== X-Gm-Message-State: AOAM530K/L5+cVFz2egFYk1gpXijSEkNkdmpXYLbDWY4OE30SJh51SAS sExB9NC6H6lQ/nVqm5FWJYUkoRk84zRNTqoiRkn9aDrdzlvip2a7V/E4k27z7vIEjUZiV9o4YQ= = X-Google-Smtp-Source: ABdhPJyU/15nxdc3ZJy6mq7/MWKeFhF8sY11v5gwMqGd0+lla60By9Cx9ugUAxH+wzdOuttheZ8LLQ== X-Received: by 2002:a7b:c055:: with SMTP id u21mr3412289wmc.68.1613650138605; Thu, 18 Feb 2021 04:08:58 -0800 (PST) Received: from [10.0.0.6] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id 6sm11478055wra.63.2021.02.18.04.08.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Feb 2021 04:08:58 -0800 (PST) From: Neil Madden Message-Id: <35645BCD-A9F5-4A57-9771-836647F08444@forgerock.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 18 Feb 2021 12:08:55 +0000 In-Reply-To: Cc: Vittorio Bertocci , oauth To: Brian Campbell References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Content-Type: multipart/alternative; boundary="Apple-Mail=_E04D6C09-F3E2-4EB4-A150-D4E8E3A339D2" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 12:09:04 -0000 --Apple-Mail=_E04D6C09-F3E2-4EB4-A150-D4E8E3A339D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Thanks for following up, Brian. Responses below. > On 17 Feb 2021, at 22:48, Brian Campbell wro= te: >=20 > 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 hopeful= ly do the right thing in the draft.=20 >=20 > It seems to me that a GET at the bff-token endpoint is "safe" in that it'= s effectively just a read. Well it=E2=80=99s a read that returns an access token. It=E2=80=99s =E2=80= =9Csafe=E2=80=9D in the sense of side-effects, but we absolutely want to pr= eserve the confidentiality of what is returned and only allow it to be acce= ssed by authorized clients (the legitimate frontend). At the moment the onl= y 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:
abcd
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 brows= er will happily load that iframe and send along the cookie when it makes th= e 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 bf= f-token endpoint and read the access token even in JSON form. There have al= so been historical same-origin policy bypasses using Flash, Adobe Reader, o= r other plugins (thankfully now largely eliminated), or by redefining JavaS= cript prototypes - see https://haacked.com/archive/2009/06/25/json-hijackin= g.aspx/ . The= se are largely fixed, but I wouldn=E2=80=99t bet on there never being anoth= er 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 m= ore resource intensive but doesn't fundamentally alter the state of the bac= kend so is still "safe". That in conjunction with your pointing to Cross-Or= igin Read Blocking makes me think your concern isn't so much about traditio= nal CSRF used to take some malicious action but rather about somehow (specu= lative side-channel attacks, problems with javascript interpreters, other s= imilar vectors that are somewhat beyond me) accessing the data of the respo= nse to a forged cross site request. Correct me if I'm wrong. I don't know i= f or how much the distinction matters in terms of mitigation approach but I= 'm keen to better understand. =20 As explained above, because the endpoint returns JSON it _should_ be imposs= ible to directly read the response from a cross-origin read (unless explici= tly enabled with CORS). But you may still be able to embed that response in= an or similar. Because people are terrible at setting correct Conten= t-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 attacke= r=E2=80=99s site. That means that it is then vulnerable to attacks like Spe= ctre that bypass normal memory protection. The browser vendors consider thi= s to be a real threat, hence CORB. The most important thing for a cookie-based JSON API to do is to return a c= orrect Content-Type header and to also return X-Content-Type-Options: nosni= ff 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 compon= ent at all). (You should also mark the cookie as HttpOnly because this prevents the cook= ie 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 byp= asses in this area. So for something as high-value as an access token I=E2= =80=99d prefer that any request using cookie-based authentication is protec= ted by proactive CSRF defences to prevent malicious requests being allowed = in the first place. >=20 > 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 P= OST 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? Say= ing 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 suc= h 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 h= ash out the most appropriate thing to do.=20 Right, the preference for POST is because it's more likely to trigger CSRF = defences, which often consider GET/HEAD requests to be =E2=80=9Csafe=E2=80= =9D. Even before Spectre, there is a whole array of side-channel attacks fo= r extracting information from cross-site responses: https://xsleaks.dev . Note that even SameSite has a "GET-out clause" in the= form of =E2=80=9Clax=E2=80=9D. 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 heade= r 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 minimu= m the cookie should be marked as SameSite.=20 We could perhaps add an informational reference to https://cheatsheetseries= .owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.ht= ml given that there is a changing landscape ar= ound cookies at the moment. If the browser vendors do eliminate 3rd-party c= ookies 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). =E2=80=94 Neil >=20 > That got a little rambly, sorry. But hopefully it makes some sense.=20 >=20 > On Sun, Feb 14, 2021 at 1:17 AM Neil Madden > wrote: >=20 > The combination of the bff-token endpoint recommending the use of GET req= uests together with the hint to use cookie-based authentication is likely g= oing 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 Blo= cking (https://chromium.googlesource.com/chromium/src/+/master/services/net= work/cross_origin_read_blocking_explainer.md ) due to the JSON content-type. That makes me really nervous. We s= hould at least mandate X-Content-Type-Options: nosniff on that response. I= =E2=80=99d feel more comfortable if this was a POST request only.=20 >=20 > =E2=80=94 Neil >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, = distribution or disclosure by others is strictly prohibited. If you have r= eceived this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer= . Thank you. --=20 ForgeRock values your Privacy --Apple-Mail=_E04D6C09-F3E2-4EB4-A150-D4E8E3A339D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Thanks for following up, B= rian. Responses below.

On= 17 Feb 2021, at 22:48, Brian Campbell <bcampbell@pingidentity.com> wrote:
Always appreciate (and often learn from) your insight= s, Neil. I'd like to dig into the CSRF thing a bit more though to understan= d 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 r= ead.

Well it= =E2=80=99s a read that returns an access token. It=E2=80=99s =E2=80=9Csafe= =E2=80=9D 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 i= n which the token-bff endpoint instead returned the access token as HTML:

<div id=3D=E2=80=9CaccessToken=E2=80= =9D>abcd</div>

Then as an atta= cker I can simply embed an iframe on my site that refers to your bff-endpoi= nt 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 y= ou have CORS enabled on your site (with Access-Control-Allow-Credentials) t= hen any of the allowed CORS origins can directly call the bff-token endpoin= t and read the access token even in JSON form. There have also been histori= cal same-origin policy bypasses using Flash, Adobe Reader, or other plugins= (thankfully now largely eliminated), or by redefining JavaScript prototype= s - see https://haacked.com/archive/2009/06/25/json-hijacking.= aspx/ . These are largely fixed, but I wouldn=E2=80=99t bet on the= re 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 f= rom the remote AS, which will be more resource intensive but doesn't fundam= entally alter the state of the backend so is still "safe". That in conjunct= ion with your pointing to Cross-Origin Read Blocking makes me think your co= ncern isn't so much about traditional CSRF used to take some malicious acti= on but rather about somehow (speculative side-channel attacks, problems wit= h javascript interpreters, other similar vectors that are somewhat beyond m= e) accessing the data of the response to a forged cross site request. Corre= ct 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 impossibl= e 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 Con= tent-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 alre= ady been loaded into the address space of the renderer process for the atta= cker=E2=80=99s 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.

T= he most important thing for a cookie-based JSON API to do is to return a co= rrect Content-Type header and to also return X-Content-Type-Options: nosnif= f to prevent browsers from trying to sniff the real content-type. (I have a= n 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 compone= nt at all).

(You should also mark the c= ookie as HttpOnly because this prevents the cookie ever entering the addres= s space of a renderer process in modern browsers - an actual genuine securi= ty benefit of HttpOnly cookies).

But my= worry is that this is still basically trusting the client to perform criti= cal security checks, and historically browsers have had plenty of bypasses = in this area. So for something as high-value as an access token I=E2=80=99d= 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 defense= s and by using POST the bff-token endpoint will basically inherit said defe= nses. Or is POST by itself good enough (the CORB writeup seems to suggest t= hat 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 ab= out CSRF defense? Saying it just has to be done. Or like even mandating a n= on-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 shou= ld be a POST with built-in CSRF protection by changing it to carry any para= meters as JSON in the body with "{}" for the case of no parameters specifie= d?  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 =E2=80=9Csafe=E2=80= =9D. Even before Spectre, there is a whole array of side-channel attacks fo= r extracting information from cross-site responses: https://xsleaks.dev . Note that even Same= Site has a "GET-out clause" in the form of =E2=80=9Clax=E2=80=9D.

So yes, the real requirement is that the endpoin= t 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: appl= ication/json header and X-Content-Type-Options: nosniff.
2. The c= ookie SHOULD be marked as HttpOnly.
3. The endpoint MUST NOT be a= ccessible via CORS.
4. The endpoint SHOULD have adequate CSRF pro= tections in place. At a minimum the cookie should be marked as SameSite.&nb= sp;

We could perhaps add an information= al reference to http= s://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Preve= ntion_Cheat_Sheet.html given that there is a changing landscape ar= ound cookies at the moment. If the browser vendors do eliminate 3rd-party c= ookies 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).=

=E2=80=94 Neil


That got a little r= ambly, sorry. But hopefully it makes some sense.

On Sun, Feb 14, 2021 at 1:17 AM Neil Madden <neil.m= adden@forgerock.com> wrote:

The combination of the bff-token endpoi= nt recommending the use of GET requests together with the hint to use cooki= e-based authentication is likely going to punch a hole in most CSRF defense= s, which assume that GETs are safe. The only thing preventing this being ex= ploitable is Cross-Origin Read Blocking (https://chromium.googlesource.= com/chromium/src/+/master/services/network/cross_origin_read_blocking_expla= iner.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=E2=80=99d feel more comfortable if this was a POST request only. 
=E2=80=94 Neil

<= /div>

CONFIDENTIALITY NOTICE: = This email may contain confidential and privileged material for the sole us= e of the intended recipient(s). Any review, use, distribution or disclosure= by others is strictly prohibited.  If you have received this communic= ation in error, please notify the sender immediately by e-mail and delete t= he message and any file attachments from your computer. Thank you.


ForgeRock values your Privacy --Apple-Mail=_E04D6C09-F3E2-4EB4-A150-D4E8E3A339D2--