Web Profile and security

[Ray Plante]

(this is a resend)

Hi folks,

Let me back up a bit.  There are three basic security questions we need to ask 
ourselves:

   1.  How can malicious code gain trusted access?
   2.  What can malicious code do once it gains trusted access?
   3.  What can we do to prevent it?

My concerns surrounding #1 are as follows:  the window pops and asks for 
confirmation to connect to the hub.  The window identifies the source of the 
web samp client application (by its IP name); based on this the user decides 
whether to trust the client and allow the connection.  There are two common 
ways to get a user to trust malicious code:

   o  spoof the identity by claiming to be who it isn't.  This is often
      done via man-in-the-middle attacks, including DNS spoofing.

   o  phish the identity, e.g. use a domain name that is nearly identical
      to a trusted one.

It is human nature for folks, when repeatedly presented with the same hoop to 
getting what they want, to just jump through it without care.  I would argue 
that in the limit of our success in the VO, particularly with a Web-SAMP 
profile, the confirmation window is not a security feature (though it may be 
useful in other ways).  In that limit (imagine a popular web-samp enabled EO 
site), malicious access will occur.

(As I'll describe below, the purpose of certificates is to validate that 
someone really is who they claim to be.  Certs, however, isn't the only way to 
do this.)

As for #2, I'm less familiar with SAMP and what the common mtypes can do. I see 
that clients can request other clients to load files via a URL; e.g. Tomcat may 
instruct a web client to read a file from local disk (yes?). Can a web client 
tell another web client to read from an arbitrary file on disk (like 
/etc/passwd)?

Part of the danger, of course, is that mtypes are extensible, and new ones can 
be defined to do anything on the local system.  Now developers should apply 
prudence when defining new mtypes (because there could be rogue desktop apps, 
albeit being harder to deliver to users); nevertheless, there is no such 
control implied when Web-SAMP is in use.

Another general danger has to do with hole into the local system the Web-SAMP 
hub opens to the outside world.  Even if the hub, say, filters dangerous 
requests, its implementation needs also needs to worry about illegal uses of 
the protocol to break out of the hub's "sandbox" (the analog to SQL-injection 
attacks or overflow attacks) and gain the power of the user.

For #3, we need to look into what can be done to prevent #1 and #2. Perhaps the 
danger can be mitigated with extra rules for handling client messages 
(presumably in the hub, since client applications already exist). However, it 
seems to me the weak point is in the trust established when the connection is 
made.

As I said above, certificates allow one to validate that a client (or a server) 
is who they say they are.  It works because only the owner of the identity has 
the private key associated with the signature on the certificate.  HTTPS 
provides a means for a client to present such a certificate.  To make the 
confirmation window effective against the attacks in #1, we need a certificate 
identifying the provider of the web client to be provided to the hub.  This has 
a few challenges:
    o  The JavaScript language does not support (to my knowledge)
         presenting a cert with an HTTPS URL.
    o  We have to get the cert plus a private key to the JS VM in the
         browser in a secure way (this is known as credential delegation)

At the moment, I don't know exactly how to address these; however, I believe 
that others in the web community have been grappling with the same problem and 
solutions are in the works.  (E.g. modern browsers are picking up support for 
extensions to JavaScript that can do more.)  Of course, X.509 certificates are 
not the only way to accomplish the validation. Perhaps the answer is 
incorporating credential delegation or authentication challenges into the hub.

My above stabs at the three security questions are most definitely incomplete 
and need more work.  Nevertheless, my answer to #1 suggests to me that these 
should not be ignored.

cheers,
Ray