While writing with @Vincent about an security issue, I thought it’s maybe good to write down some security thoughts of me that could help others. It should give a basic overview, what potential threats exist for solid apps and some code examples how we can prevent simple/common attacks. The target audience are people with (nearly) no prior security knowledge. It is of course not exhaustive, would be good if security was so simple but sadly we’re not there yet
This is a great resource, thanks for writing this up! And just wanted to endorse this for others: some of the mistakes are pretty easy to make, and @A_A has been a tremendous help assisting me to resolve some of them in Penny.
On hosting, I’d probably say Vercel or Netlify or Render would be simplest for serving an application: as long as you can reach a point where you have html & asset files (whether by hand or compilation), they can generally serve it, and all work quite nicely with most frontend build tools (sometimes additional config is required) — that’ll give you a fully unique domain per application (and even per branch or commit). Plus they can even compile your app for you!
GitHub Pages tends to run short in that it’s strictly backed by git (the more builds the bigger your repository becomes) and that you’ve a single domain per user or organisation, instead of per repository.
As for “trusting” data, your best bet beyond those heuristics is to use something along the lines of cryptographic signatures (a good example of this is trust in activitypub/mastodon, where data outgoing is signed by the user with a private key, and the public key is publicly available to verify said signature.
BUT, there in lies a problem of how to store that private key, in Mastodon, it’s stored by the instances’ database which is assumed to be secure (yes, that means the instance can in theory impersonate you, that’s within their trust model), in Solid, there isn’t any “private” storage that’s tightly controlled & impossible to screw up the permissions on, so you’d not want to risk storing a private key in your pod (unless it’s encrypted in some way)
It does not host anything, but proxies content (one-way), meaning you can hook a domain from your choice to content. All you need is dns access and you can host the content/application in a totally different location.
What we aim for is to have broader protocol support. It is all open, feel free to read and improve the source.
Regarding the trusting, I think what you point out is important, but too complex for “basic security guidelines”. I’ll probably add a mention for interested readers, but I won’t be able to explain it in depth.
In general, I think cryptographic signatures can be necessary, but it depends on the application.
From my point of view, some applications can operate with untrusted data: A file viewer like Penny doesn’t care much if the integrity of the files is given, or if someone malicious has modified the files. As long as it does not perform security-relevant actions based on these files (eg creating new ones, modifying others, etc) it likely doesn’t matter.
Other applications will require trust in the data: a health app that interacts with medical devices must ensure the data it uses is fine. If someone tampers with the data it could have critical effects on the users health, so we’d need to prevent this.
For the latter type of applications I think all your points apply, and I think no application has tried to tackle them yet (at least in an interoperable way). I’d like to add that we also need to trust the public key, ie to verify a signature we can’t use any public key on the pod as a malicious person could potentially change this key. The best we currently have, that I know of, is Pod-Chat.com, which stores the public key in the profile and the private key in a file where only the owner has access to. But currently this means, any app I login with has access to this key, and I could mess up the access rights to it.
Thanks for bringing this up. I think SimplyDomain would be possible to use, but traditional hosting providers (such as Vercel, github.io or own domains) should be fine for apps. I guess that SimplyDomain is targeted more for Solid pods than Solid apps?
I think SimplyDomain can be used for any content you need a better-shorter URL for.
I especially like the idea it could be used for new protocols in development. Bridging new stuff to browsers with only https support. It could have made ipfs, hyper-dat easier to browse from current browsers.
Hope somebody will add dns support to it, as in, put html in a TXT records and create code for SImplyDomain where you can have a record pointing it to a dns records. The proxy will then need to do some translating between the TXT record and serving it was https. (it is almost five’o clock on friday here).
For the solidOS chat-pane to improve the key pair security (avoid unexpected modifications), the keys triples are in READ only dedicated resources like /profile/keys/publicKey.ttl and privateKey.ttl
privateKey is READ only by the webId
publicKey is READ only by everybody
Changing/deleting the keys are more complex but still be possible for one of the Owners.
An Owner (usually the webId, but it may be someone else) must first Edit the ACL and then only will be able to :
delete the key pair : a new key pair will be automatically recreated by the app
or change the keys.
In both cases the existing message signature will fail on verify.
Possibly off-topic: Let’s say a developer builds a successful application that people grant write and control access to (it currently seems necessary for the app to set permissions). One day, if the developer gets vindictive, such updated application will be able to wipe out the whole pod, or steal all the data.
People are probably working on this. But right now i don’t see how it can be prevented, if application gains trust.
Only keeping backups, or history…
My preferred UX and flow in this case would be this: App would redirect to Pod, which would ask the user directly, whether she wants to allow a specific action for specific file(s). I think mobile apps, and OAuth apps already do this kind of flow in limited scope… you click Allow or Deny, or you pick which permissions you want to grant, and that’s it. You also can tell your Pod to remember the choice.
