Web Profile and security

[Paul Harrison]

Hi,

I too have security worries about this proposal - mainly because cross site scripting http://en.wikipedia.org/wiki/Cross-site_scripting has already proved to be a significant web application vulnerability. This is all connected to the ever increasing capabilities of javascript within browsers, and because of this organic growth was driven by the desire to do fancy rather than safe things. Anyway, as I am unable to stop the march of progress single-handedly I have some comments the authentication issues and trying to use https that have been raised by Ray.

I think that the authentication security concerns that we are trying to address are:

1) the web application comes from a trusted source
2) the communications from the "web application" (i.e. the browser) to the hub are not hijacked.

The first can be addressed by the the originating web server using https - it is then up to the user to check the site's identity as they would when internet shopping for instance, and then as Mark says only allow a hub registration when they have just browsed to that site rather than any other. (Note this does not guarantee of course that the trustworthy web application provider's application is safe from XSS which could inject malicious code)

And the second concern is addressed (again as Mark said) by only allowing the hub to accept communications from localhost - this should be a MUST - it is central to the security/simplicity of SAMP, which explicitly precludes any inter host communication between SAMP hubs as has been suggested - if people want to have inter host SAMP communications then they can  set up SSH tunnels to allow this with a fair degree of security.


On 2010-12 -16, at 22:11, Ray Plante wrote:

> 
> 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.
> 



If we are really interested in getting reliable identity information to the hub then it could be done with a  signed java applet - as we know there is already a sandbox busting mechanism for applets that asks the user to allow the breakout and gives them a strong mechanism for verifying where the request came from (the certificate). So the protocol would go something like this;

1. the applet makes first contact with the hub and passes a verifiable identifier - the verifiable identifier could be the web application's url  that is signed with the same certificate that was used to sign the applet in the first place (and is compiled into the applet) The hub then does not need to challenge the user if it can verify the signature, and it knows the origin of the request.
2. the applet then writes the returned SAMP secret into the browser DOM so that it can be used by javascript - I am not sure how easy this is as it was really the fact that the DOM api of the java plugin was fairly sparse that lead people to want to use javascript - but I believe something basic could be done.
3. General SAMP communications are then started up with a javascript client.

This would be reasonably easy to implement, as it would not involve having to install any local keys - though perhaps not a absolutely bullet-proof as it might be - the applet could be stolen by a malicious site for instance,so would need to be hardened to work only when served from its intended origin, and perhaps a way is needed for the hub to verify this for itself by contacting the origin web server as well   - the only downside  I can really see is that java is not available on some snazzy portable devices that people like nowadays..
> 
> I'll repeat what I said in my presentation, (see also sec 1.2 of
> http://www.star.bristol.ac.uk/~mbt/websamp/websamp.html)
> which is that *in practice*, my proposal doesn't present any more 
> serious security issues than the current best/only way of 
> getting web pages to do SAMP, namely signed java applets.
> My reasoning for this is that although signed java
> applets use certificates, in practice VO users (myself included I'm
> afraid, though I'm starting to learn) don't look at the details of 
> these certificates or understand how they work.  By way of example, 
> the WebStart version of TOPCAT has a certificate which is self-signed,
> untrusted, unverified and expired (as an added bonus, it's signed by
> "Peter W. Draper", a name unfamiliar to most users - though this is 
> irrelevant to the security since a self-signed cert can use any 
> name it wants).  Lots of people have used this, but I've never had 
> anybody query it.  Aladin appears to be in a similar situation.
> 

There does need to be some education on this issue, but I agree that the failure to do so early enough has lead to a situation where people largely ignore the certificate warnings - and as you say any self-signed certificate is essentially useless. There is already a mechanism within academia (especially the grid world) though where a proper PKI has been set up, with well established root certificates to create a global trust hierarchy. This is overseen in europe by http://www.eugridpma.org/, which collaborates with other continental authorities to form the global International Grid Trust Federation (IGTF) from where you can download the root certificates. In the UK you can obtain certificates from this PKI at https://ca.grid-support.ac.uk/ if you are a member of a university - It requires presenting real ID to someone in your university, and as such provides better proof that you are who the certificate says you are than most commercial certificates which really only identify email addresses.

Unfortunately it is not common practice for sysadmins to preload the root certificates from this PKI into web browers/email clients so that you would still get warnings about certificate trustworthiness, but in principle once you had loaded the root certificates into your clients you would cease to get the warnings.

This message is "signed" with my e-science certificate, so you should trust that is me ;-)

Cheers,	
	Paul.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2957 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/apps-samp/attachments/20101220/f1f190a1/attachment.bin>