Hacker News Reader

Comment by Sarien | Hacker News Reader

How can a COMPROMISED WEBapp ever not be able to leak data while being usable?

Here's how:

* Backend: Due to Linux network namespaces, the app can't communicate with the network (except over "sandstorm-http-bridge" which allows it to respond to inbound HTTP requests).

* Frontend: Due to Content-Security-Policy, the client part of the app can't communicate with any hostname other than the one the app runs on. The CSP header is set by Sandstorm, not the app.

So then it has no network access, and therefore even if it is compromised, can't leak anything.

This does hinge on the app's dynamic code only being run for logged-in users. For many apps -- imagine a Google Docs spreadsheet only accessible to people within your domain -- this is a pretty straightforwardly reasonable model. Sandstorm handles authentication for apps, so it can enforce this even if the app is 0wned.

I compromise an app, add myself admin account, log-in, download everything. What's stopping me?

The only "everything" you should be able to get, if the security is correct, is for the app you compromised, not the other ones running on Sandstorm. No, it does not magically secure applications put behind it (though IIRC it does put a couple of useful tweaks in place, but that's all it can do), but it can prevent "I compromised your WordPress and stole your entire machine's contents."

Is that because of the security of Sandstorm as a platform or because each app would need it's own DB engine bundled with it?

It's because of Sandstorm's security as a platform. Apps cannot see each other's files on disk, because each one runs in a container with only their own subdirectory mapped in.

An app does not have the ability to edit who has permissions to itself. In order to add yourself as an admin of some app, you'd have to compromise Sandstorm, not the app.

I'm not sure how that is supposed to work. You would have to rewrite every webapp so that it's data can be protected by sandstorm. Which seems hugely impractical. And as long as the webapp has access to it compromising it will compromise the data.

Not "rewrite". You do have to tweak apps to be Sandstorm-appropriate, but it's usually somewhere between five minutes and a couple days of work. Namely:

* Delete the login system and use Sandstorm's. If you build on Meteor, for instance, this is a simple matter of swapping dependencies.

* Delete your sharing system. If the app hosts multiple things that can be independently shared, change it to host only one such thing. The user can create multiple instances of the app and using Sandstorm's sharing. This is probably the hardest part, but we've done it for several apps now without too much trouble. Since it's largely deleting code, it's not very difficult.

* Find the places where your app connects to the outside world and insert a bit of code to make a Sandstorm powerbox request to get permission first, then address the requests to that permission.

None of this involves "rewriting". We have 20+ apps on the Sandstorm app list, most of which were ported by two people who certainly didn't have time to rewrite each one.

I've ported apps to Sandstorm with literally no prior experience with the languages those apps were written in. Porting to Sandstorm involves more deleting stuff you don't need than actually writing code yourself. :D

Should this vulnerability be hard to demonstrate with a proof of concept? It sounds pretty straightforward.

Reply on news.ycombinator.com