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. 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.
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.
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._
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
