1

I would like to create a web app that runs on a server I don't physically control (e.g., on Google Cloud). I want to protect my users from the possibility of the server being compromised and sending malicious JavaScript code to the client.

What is the state of the art for doing this? Is it even done? Mylar looked like a promising solution with their browser extension for authenticating web apps but it appears to have gotten no traction and I can't even find the browser extension to install (other than building it myself from source).

  • Mylar expects some initial trust, i.e. the code need to be signed and this signature need to be checked. While your exact requirements (including where the initial trust into signatures or similar comes from) is unknown you might use CSP hashes to safely include script from a server you don't trust as long as the initial page and the CSP are served from a server you trust. – Steffen Ullrich May 1 '17 at 4:43
  • 1
    There is no way without having some instance you trust first. This might be the author of a plugin you install, a CA issuing a certificate to sign some something etc or simply be using a specific browser software and OS. – Steffen Ullrich May 1 '17 at 15:27
  • When you have no hand over what the server actually does, there is nothing you can do - when you do not trust the hoster, you can not expect them to run any code or do anything you try to defend against this threat. – Tobi Nary Oct 29 '17 at 19:58
1

There is a clear separation of concerns here. As the web app developper, you should use state of the art security rules to protect your app. If you are also accountable for its integration on a server, you should also ensure that all the components you use around the application (for example an Apache or nginx front server) have configurations that follow state of the art rules.

But the protection of the client machines can only rely on the machine owners, and the best you can do is to ensure that you have done your job in producing and configuration a correctly secured web app.

That being said the security of a web app heavily rely on the global security on its host. If you think you cannot trust the host environment, you should not use it, or accept that the security of your app will not be higher than the security of its host. Said differently, in using a hosting service for your app, you accept its security level.

  • Yes, that's a good summary of what I now understand to be the current state of affairs. It's disappointing because it wouldn't be difficult to make browsers refuse to load a web app unless it has a valid signature by the application author, reducing the attack surface significantly by eliminating the need for the server to be trusted. This was demonstrated in a proof of concept by Mylar (css.csail.mit.edu/mylar). It looks like people who care about this (e.g., Signal) have been distributing their applications as Chrome apps but those are now deprecated. – David Braun Jun 2 '17 at 17:41
0

Content Security Policy is probably a good place to start.

But ultimately, from a client perspective, if you connect to a web site (with Javascript enabled), you're implying that you have some basic level of trust in it... even if you don't realise it.

From the perspective of hosting a site, if you're hosting with a provider then you're trusting them to do so in a secure fashion, there's only so much you can do: your "egg" is completely in their "basket".

For 3rd party assets (typically hosted via a CDN), you can employ subresource integrity.

  • Interesting tools but if I employ CSP and SRI on my site and then an attacker compromises it he can simply turn them off. Sigh. – David Braun May 1 '17 at 15:15
  • @DavidBraun Yep - hence the egg and basket analogy... – Nathan May 2 '17 at 11:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.