> On 18 Feb 2021, at 13:08, 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 
>> <mailto: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.

You are overlooking basic browser security measures like the Same-Origin Policy 
here. The browser will only allow access to an iframe if it has the same origin 
as the context accessing the frame. If an attacker embeds this frame in their 
site, it will be a cross-origin frame, and access will be denied.

FYI, simple CORS requests follow the same security pattern (when headers are 
missing, browsers do not expose the response). Preflighted CORS requests cover 
"new features" (i.e., stuff you traditionally could not do with HTML elements) 
and ask permission before sending a request. 

Also, if you're worried about framing, it's much simpler to require the token 
endpoint to send "X-Frame-Options: DENY" and "Content-Security-Policy: 
frame-ancestors 'none'" response headers. This denies framing altogether 
without going into complicated CORS territory.

Philippe

—
Pragmatic Web Security
Security for developers
https://pragmaticwebsecurity.com/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to