GWS II discussion topics - Security

[Russ Allbery]

Paul Harrison <paul.harrison at manchester.ac.uk> writes:
> On 23 May 2023, at 17:28, Russ Allbery <eagle at eyrie.org> wrote:

>> The background here for both 3.1 and 3.2 is that we plan to enable, via
>> IVOA protocols or extensions that are faithful to the protocols,
>> various operations that may be quite expensive (eight-hour TAP queries,
>> large batch image processing) or destructive (user table deletion).  I
>> don't want it to be possible to trigger such actions via cross-site
>> requests, mostly because of the risk of denial of service attacks.
>> Those don't have to be malicious and in fact often aren't; think of,
>> for instance, web crawlers that don't honor robots.txt (sadly more
>> common than any of us would like), or some JavaScript-triggered request
>> that gets into a refresh loop and spams requests.

> I think that the only foolproof way to prevent this is to always require
> authentication - that might be becoming more acceptable to the VO world
> nowadays.

3.1 in SQR-063 is in the context of authenticated requests.  (We have a
partly separate desire to not allow GET requests to some services for
other reasons, whether or not they are cross-site requests, which muddies
the water a little bit with 3.2, but that's a somewhat minor point.)

Cross-site requests are mostly only a security concern in the presence of
authentication.  The advantage of the cross-site request for an attacker
is that they allow making requests as some other authenticated user
(identity theft, essentially) so that they can do things they would
otherwise not be able to do.  If there is no authentication, there's no
identity to steal, and thus not much advantage.

> I think that the conclusion is that the only measures that can be used
> to try to mitigate CSRF attacks are header based tokens, and generating
> and transporting these securely are basically equivalent to SSO
> protocols.

I'm not entirely following the path to that conclusion, so let me try to
guess at what you're saying here and see if I got it right.

What I'm hearing is that, in the case where access to the VO services is
authenticated and the service is concerned about cross-site requests, the
only way to protect against those requests while maintaining
interoperability with standard VO clients is to require all requests
contain an Authorization header.  (Or some other header, but I believe
there's an effort already underway to standardize the Authorization header
in a VO services context, and that's the obvious header to use for this in
the presence of authentication anyway, so I think we can simplify and
discard the idea of using other headers.)

The implication is that, again in the case of authenticated requests and a
concern about cross-site requests, cookie-based authentication, CSRF
protection, and VO protocols don't mix.  A site that wants to use
cookie-based authentication while disallowing cross-site requests will
have to define their own protocol that incorporates some other CSRF
protection mechanism (probably based on a hidden form field and a client
that uses HTML forms), and standard VO clients will not interoperate with
that service when using cookie authentication because they won't know to
send the CSRF token.  Interoperability with standard clients only works
with Authorization-header-based authentication.

Assuming I've got that right, we'll have to think about this some more,
but I think that may work for Rubin.  Our main VO protocol clients send
Authorization headers already.  We do allow GET-based authenticated TAP
queries using cookie authentication right now, and that's convenient for
quickly testing with a browser, but I'm not sure how important it is to
continue to support.  I don't think we have any case where we want to
drive VO services from HTML forms directly; I think we always have an
intervening service that is responsible for issuing the VO request and can
include an Authorization header.

If the above is the consensus of the working group, it would be good to
write this down somewhere, perhaps in the SSO document since that document
is already talking about authentication in a VO context.

> However, I think that it is unlikely to be acceptable for a long time
> that an astronomer is required to log-on to the VO, mainly because a
> globally acceptable identity federator is difficult to agree on.

> I think that an observatory that wants to use VO protocols to distribute
> their proprietary data will have to do that on a different authenticated
> endpoint to the “open” data.

I think that's usually easier anyway, at least for the service
implementation.  Providing authenticated and unauthenticated access from
the same endpoints adds a lot of complexity and it's a bit tricky to get
all the details right.

> This still leaves the problem of trying to mitigate CSRF on the open
> data endpoints.

Personally, I wouldn't worry about this.  There's so little benefit from
CSRF to an unauthenticated service that I doubt any attacker would bother,
and even if they did, it's hard to see much risk.  It's a way to hide the
origin of the request at the cost of not being able to see the response, I
suppose, but that doesn't sound very interesting.

>> * Currently, my understanding is that DALI *requires* a compliant server
>>   to support both GET and POST.  While both GET and POST requests have the
>>   same theoretical security properties, in practice GET requests are much
>>   more likely to produce those unintentional denial of service attacks I'm
>>   the most worried about, and there are some cases where I don't think we
>>   will have any obvious need to support GET.  In those cases, it would be
>>   nice to have a way to say "this service is POST-only" so that clients
>>   will know to not attempt GET.  (This was the point of 3.2; the entire
>>   request there is just that servers not be *required* to support GET to
>>   be standard-compliant.)

> This might be the easiest area to try to push on - though it should be
> noted that there are consequences for other things like DataLink -
> though there are mechanisms there for parameter passing outside the url
> query parameters, which might actually lower the level of desire for
> everything to be captured in the URL query parameters. The DataLink
> could point at the equivalent POST.

I think we've already had some discussions within Rubin about POST and
DataLink.

Okay, great.  What's the best way to proceed with making GET support
optional in DALI services?  Presumably that would require standardizing a
way to specify this in the Registry so that clients know whether GET is
supported, and it sounds like there may also be DataLink changes needed?

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