Draft CORS guidance for an IVOA JSON protocol

[Russ Allbery]

Ugh, sorry, there's a confusing error in this message that I didn't catch
before I sent it.

Russ Allbery via grid <grid at ivoa.net> writes:

> If case 3 applies but the service also needs to support cookie
> authentication without any extra HTTP headers, then one of the other
> CORS mitigation strategies must be used.  This is the case that I think
> is worth documenting in a standardization of the x-www-form-urlencoded
> network encoding.  The obvious thing to document is probably some
> version of the synchronizer token pattern [2], although in some cases it
> may be possible to get away with using SameSite=Strict cookies.
> (SameSite=Strict cookies have some significant limitations, however,
> which would deserve a longer discussion.)  Documenting this as part of
> the standard would allow use of an authenticated, CSRF-protected
> x-www-form-urlencoded POST API by non-browser clients such as PyVO or
> TOPCAT.

Non-browser x-www-form-urlencoded clients are much easier to handle than
this because non-browser clients almost certainly don't authenticate with
cookies and CSRF issues only apply to cooke-based authentication.  Since
non-browser clients send Authorization headers, they can be distinguished
on the server side from browsers and their requests can be passed through
without requiring CSRF protection.

It's correct to document CSRF mitigations here because the server
otherwise has no reliable way to distinguish between same-origin and
cross-origin cookie-authenticated POST requests, and therefore without
CSRF mitigations only cases 1 and 2 can be supported in the
x-www-form-urlencoded network encoding.  However, only web form or
browser-based client-side JavaScript clients (in other words, the clients
that authenticate with cookies) will need to implement them, not
non-browser clients.

My apologies; the browser web security model is endlessly confusing,
including to me.  Part of why I would love to get it all written down
properly is so that I can go read it when I inevitably get confused again
in the future.  :)

One other thing I should mention because it's another common source of
confusion: inside a browser JavaScript context, cross-origin requests to
not include credentials by default, so by default will fail authentication
checks.  However, the JavaScript can request that credentials (which in
this context means cookies) be sent, and if the request is still a simple
request in other respects, it is still sent to the server.  Unless the
server includes Access-Control-Allow-Credentials and a matching
Access-Control-Allow-Origin header in the response, the *response* will be
blocked by the browser and cannot be read by any malicious JavaScript.
But the server-side action *still happened*; the response was discarded,
but only after the server processed the request and returned the response.

This is what I meant in my previous messages when I said "blind" requests.
The specific case where CSRF security concerns often apply is this case: a
cross-origin simple request with credentials (so the request piggybacks on
the authentication credentials of the owner of the browser), where the
response does not contain CORS headers and therefore will be blocked and
discarded by the browser, but only after the requested operation was
already performed by the server.

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>