Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessing indexedDB through aragon apps #702

Open
Schwartz10 opened this issue Apr 16, 2019 · 6 comments

Comments

@Schwartz10
Copy link
Contributor

commented Apr 16, 2019

Is your feature request related to a problem? Please describe.
Problem:

I'm working on integration between orbitdb (through 3box) and an aragon-app - in order to work properly, orbitdb needs to store private keys in indexedDB.

Currently the sandbox settings restrict access to indexeddb from within an aragon app, and I'm wondering if there's a way around this, so we can continue forward with this 3box integration.

indexedDB is a helpful tool for building dapps, so I feel like giving apps access to it will only help create better apps

Describe the solution you'd like

A PR that gives approved applications a looser sandbox setting

We could sense that the profile app is being loaded and render an iframe with a different sandbox.

One thing I'm not sure about is how we block imitation attacks where malicious developers mimic a profile application and get by this check, with looser sandboxing in their mimicked profile application.

Describe alternatives you've considered

One alternative is to make the profiles application part of aragon/aragon

A naive alternative is to enable allow-same-origin in the sandbox iframes, but that seems to be a bad option given the comments in the code.

A (potential) future alternative is use the storage access api, where storage access can be granted from within an iframe sandbox. However, this api is not supported on chrome yet, is not production ready, and may require changes to orbitdb.

@sohkai

This comment has been minimized.

Copy link
Member

commented Apr 16, 2019

Will have to look into the security assumptions of allowing access to this. We've specifically taken the hardline approach where we don't want apps to have access to localstorage (and extending it, indexeddb).

@Schwartz10

This comment has been minimized.

Copy link
Contributor Author

commented Apr 16, 2019

Understood. It's a bummer the storage access api isnt ready yet.

For now, I'm going to disable the setting in my local environment, so i can keep moving with the integration. I'm confident we'll find some solution for this.

@Schwartz10

This comment has been minimized.

Copy link
Contributor Author

commented Apr 23, 2019

Thinking out loud here - it seems like we should be able to give each iframe its own sandboxed instance of indexedDB (is this possible?). There's no reason each individual iframe needs to access any parent or sibling's localStorage, everything can be contained within that iframe.

@oed

This comment has been minimized.

Copy link

commented Apr 23, 2019

Does all aragon apps live under the same domain? To me it would be reasonable to have the apps live under different domains so that they would get their own indexedDB.

@sohkai

This comment has been minimized.

Copy link
Member

commented Apr 23, 2019

Indeed, that is essentially what the origin sandboxing should be doing; living in isolated domains.

Haven't looked to see if there's a way to enable it separately inside the sandbox though. To achieve the sandboxing the browser is essentially assigning them to "null" domains and I assume this doesn't play well with the storage APIs (how would the browser know if the next session is the same as a prior one?).

Perhaps sessionStorage is accessible, but it likely isn't a great place to store private keys for orbitdb's usecase (which I assume requires persistence?).

@sohkai sohkai added the help wanted label Apr 23, 2019

@sohkai

This comment has been minimized.

Copy link
Member

commented May 21, 2019

After a little experimentation after noticing https://github.com/3box/3box-js/issues/443#issuecomment-494147205:

localStorage seems to be available in the iframe (just ran a quick test on my own, and can persist a key value pair there)

localStorage is indeed available on the sandboxed iframe, but attempting to read from it (or sessionStorage) should result in an origin error:

Screen Shot 2019-05-21 at 10 32 12 AM

I had hoped that the iframe would at least have access to sessionStorage, to persist values across its current session, but it falls under the same rules as localStorage. But for most intents and purposes, sessionStorage will be pretty similar to just using an in-memory cache.

Interestingly though, it appears that if the iframe was loaded from the same origin (was poking around with an example), it has access to localStorage even without the allow-same-origin flag (which to me seems to be opposite of what the spec says about sandboxing without the allow-same-origin flag).

This will present a security problem if someone loads the client through an ipfs gateway (rather than our web2 origin).

This is likely what you saw @Schwartz10, while testing with localhost (I imagine both aragon/aragon and the custom app were served from the same localhost origin).


During this exploration though, I did notice that the WebWorkers we currently create (through blob urls) can actually access the top level indexedDB, and that they were not created in opaque origins. I've now changed them to use data: urls, to force their origins to be opaque: #797.

Note that allowing these workers global access to indexedDB is really, really bad, as they could do anything they wanted to with another app's cache. AFAIK there's no way to isolate particular databases to specific contexts :(.

@Schwartz10 Schwartz10 referenced this issue May 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.