datenanfragen / mobile-app Goto Github PK

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.

To build a mobile app for Datenanfragen.de, we have decided to use React Native. The question now is how we want to do that, especially with regards to sharing code between the existing https://github.com/datenanfragen/website and the new mobile app.

• Despite what the name might suggest, (P)react components cannot be used in React Native. React Native doesn't use HTML but has its own primitive components ("core components": <View>, <Text>, etc.).
• Their philosophy is not "write once, run anywhere" but "learn once, write anywhere".
• Thus, we won't be able to just reuse our existing Preact code in React Native.
• The other direction (outputting a web app from React Native code) is possible through react-native-web. It seems like this could even output a Preact instead of a React app (https://docs.expo.dev/guides/using-preact/).
• There is react-native-react-bridge which allows using (P)react components directly in React Native but only through a webview. But honestly if we decide to go that route, it would probably be better to use something more mature like Cordova.

This essentially leaves us with three options:

1. Rewrite website in React Native. I'm quite strongly opposed to that.
2. Have the mobile app be a webview.
3. Extract as much of the logic and reusable code (hooks!) from website into one or more libraries but write a separate UI for React Native.

I'm leaning quite strongly towards option 3. My reasoning:

• website isn't built as a pure Preact app, we have quite a bit of code in Hugo templates that we wouldn't be able to use anyway.
• We are planning to majorly revamp the UI for the apps anyway, there is no need to port the current generator to mobile, for example.
• Some of the new features we're planning won't work on the web.
• Other projects can benefit from our shared libs (as we're already seeing for letter-generator).
• From what I've gathered, this seems to be the preferred approach (https://www.youtube.com/watch?v=QO7SkFqRd7s, https://www.youtube.com/watch?v=O8d_42Wc-po).