Capacitor security considerations

[baltpeter]

Now that I've started working on implementing the mobile version of the app using Capacitor, I have noticed a few things that concern me w/r/t security.

For Electron, essentially the big revelation in terms of security was the concept of context isolation. In the initial versions and with Node integration, all privileged APIs were simply made available through the window object. While this allowed for great developer ergonomics, it also meant that every XSS vulnerability could be turned into full RCE for free. These days, if you follow the recommendations in the docs, you have a strict separation between the privileged main process and the renderer processes. If someone manages to achieve XSS in your app, they are constrained to the renderer process and can only access the APIs that you explicitly make available. This makes it quite easy to severely restrict the attack surface and effectively limit the damage that can be done through an XSS vector. (I'm somewhat oversimplifying here, but I do think that this is a fair summary for our purposes here.)

This evolution doesn't seem to have taken place in the Cordova/Capacitor ecosystem. There doesn't seem to be any isolation between the content process and the privileged APIs. If you look at the window (and window.navigator) through the Chrome remote dev tools, you can see also sorts of dangerous-looking stuff.

The only reference I have found for this issue at all, is this post from 2017 talking about Cordova: https://research.securitum.com/security-problems-of-apache-cordova-steal-the-entire-contents-of-the-phone_s-memory-card-with-one-xss/

That is pretty much the exact issue I'm concerned about and the response from the maintainers wasn't great:

The Apache security team was informed about the behavior before the publication of the article. Apache will not make corrections to Cordova, as it is the developer that is responsible for the security of the application.

Capacitor does have security docs but those (as well as all of the other blog posts on the topic I've found) don't go into this isolation problem at all, they mostly talk about stuff like not embedding API keys in the app, using HTTPS, problems of deep links, etc.

They do however also mention that you should use a secure CSP. That should be enough to effectively mitigate any XSS vulnerabilities that we might have. At least, I can't think of any way an attacker could still get access to the privileged functions with a secure CSP, so this might not actually be too much of a problem for us. But I'm not sure.

[zner0L]

Could we overwrite the dangerous APIs in the window object and replace it with stubs? To be save?

[zner0L]

We decided to only show plain text emails on mobile to mitigate the largest attack surface. While iframes do support sandboxing and Web Policies, these features are relatively new in Android WebView and Safari on iOS, so we don't want to use it to show HTML emails.

[keks]

Hi, Jan from LeastAuthority here.

I agree that Electron's context separation approach is a lot better than what Cordova/Capacitor do. However, a good CSP should be able to prevent attacks.

I recommend using hashes or nonces for all resources, if that's possible. I am not sure which templating/components framework you are planning to use, but it seems that at least ionic's stencil does not support this (ionic-team/stencil#1392, ionic-team/stencil#2996). I don't know the space of component frameworks very well, so I can't make informed suggestions. The Tonic framework seems to have support (though it might be missing other important stuff, no idea).

For resources where this is not possible, the policy should still be very strict as well. For example, the policy for images should also be used to prevent tracking pixels (Note that in this scenario the attacker is the sender of an email, and if they are able to embed a <script> tag in the source which is not evaluated due to CSP, they could still be able to embed an <img> tag).

A mitigation that I am not sure would work well is to overwrite the problematic resources in window with undefined after page load. I could imagine that either Capacitor will just set the value again later or that it just breaks with e.g. window.Capacitor unset.

Hope that helped!