GWS II discussion topics - Security

[Paul Harrison]

Hi,

We we encouraged not to discuss the specifics of https://sqr-063.lsst.io/ at the interop, but there was one general topic that should have been discussed, because as a result of that note there is a perception that the “VO is insecure” - this is a dangerous reputational message to be circulating that I believe is based on an incorrect analysis and is only true in the sense that “the Internet is insecure”.

I assert that in general security concerns as pretty much orthogonal to VO protocol specifications for two reasons

* Firstly technical, most security mechanisms are based either on HTTP headers or in the transport layer and VO protocols typically deal with URL structure and message body content.
* Secondly the whole point of the VO was to make data interoperable in a public way.

Below I will deal with some of the specific issues raised.

3.1 - This whole argument is made from a very 'browser client only' perspective. As stated above in the second general principle of course VO protocols can be called from anywhere, so they will be inherently susceptible to “CSRF attacks” - that is normal usage. Of course it would be a bit surprising if when clicking on a picture of a cute cat an astronomer ran a TAP query, but when using Topcat they do want to be able to query multiple servers in different locations. (I understand that if you are running VO services for some protected resource requiring authentication and authorisation then the cat example is worrying, but by my first principle above it is not a VO concern, but requires any mitigation measures available to the general internet).

The second part of the argument made in this section is that not being able to use CORS is somehow a problem, and there is an implication that CORS helps with stopping CSRF attacks. It is worth remembering that CORS itself is a mechanism to break the stronger “same origin security policy” that was put in place once once javascript fetches became possible and the user could no longer trust just what whey could see on a web page - the same origin policy gave the user some assurance that everything that was going on in their browser was controlled by the server indicated in their address bar. Given the second general principle above, the only sensible CORS answer in general would be “all origin” anyway.

3.2 - I have some sympathy with the point made here, but whilst in general the OWASP advice is good, it should be remembered that the “state changing” part here is just a side effect of an asynchronous job - the same query could be made as a pure sync GET anyway in principle, so it is not like you can do something “extra” (like make repeated withdrawals from a bank account). So again I assert that the problems here (like DoS attacks) are general internet not VO specific ones.

3.3 - Here there is a general misunderstanding of what the namespace reference is, and it being http not https does not change the security landscape at all. It was probably design error to have namespace looks like they do - W3C certainly regretted it - https://www.w3.org/blog/2008/02/w3c_s_excessive_dtd_traffic/

4.1 - XML is also singled out for security problems - again, I really do not think that this is exceptional - all computing subsystems have security issues. I note with some amusement that JSON was designed to transform directly into Javascript with no intervening business logic, thus making it  pretty good vector for injection attacks.


In conclusion whilst https://sqr-063.lsst.io/ might have some other valid criticisms of VO protocols, I feel that the VO is no more or less secure than the internet as a whole.

Paul.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20230522/3ba69919/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20230522/3ba69919/attachment.p7s>