Securing Cordova, One Plugin at a Time
Why did the chicken cross the road?
To fix security issues, of course.
The open-source world is a Titan on which a programmer stands to reach out for his casual goals and needs. For myself as a mobile developer, the Cordova infrastructure is such a Titan. Its vast number of extensions (a.k.a plugins) and forks of those plugins provided us with the basics needed to implement numerous features of Peerio.
Unfortunately, we found that these plugins have plenty of suboptimal solutions when it comes to security.
I wanted to share some of the fixes we introduced and the issues they aimed to address. Hopefully some of you will find these useful for your own projects.
cordova-plugin-wkwebview-engine
In iOS we use WkWebView as the UI engine. Being required to specify CORS while wanting to use JS web worker features resulted in at least a few hours of banging out heads against the wall. We found that workers loaded from local resources (as file:// or blob://) in a WkWebView are not compatible with CORS directives.
The common workaround for this is running GCDWebServer on the device and loading resources (and workers) from a proper URL (like localhost:3000). This workaround was first introduced in the Telerik team plugin.
However, the Telerik plugin has a pretty dangerous flaw — any other app running in background on the same device would be able to access the resources available over this GCDWebServer instance running on localhost:3000, thus violating per-application sandbox policy.
We introduced a simple solution to that problem — generating a random key each time the app is started and providing it to the JS side via an initial param injection, and validating this param on the server side as well.
This has worked pretty well and was approved by a team of independent auditors as well. Other than that, we provided a safe and stable way to recover from the dreaded “unload webview” situation which all hybrid developers have likely experienced in their life.
peerio-cordova-camera
This Cordova plugin requested explicit write and read access to storage on Android devices, even if the user doesn’t ever intend to use the camera. Surely you can name a few people who would not be so happy if their messaging app requested those permissions right from the start. This modification won’t request camera permissions until the user actually wants to use it.
peerio-cordova-privacyscreen
When switching apps on mobile devices, you usually see this nice little carousel of your open applications and screenshots of what you were last doing. Well, when your application is likely to contain sensitive data, preventing this application carousel from capturing a screenshoot is sort of critical. We forked Telerik’s privacy screen plugin and modified it to ensure greater reliability in hiding onscreen content for slower devices.
peerio-cordova-disablecustomkeyboards
No crypto in the world can save you from a stolen private key. And if you have a custom keyboard enabled, there’s a chance it might (not saying it will) sniff what you type. Can we prevent users from leaving their devices open at a bar? Nope. Can we prevent users from using potentially malicious keyboards? For sure.
peerio-cordova-open
Generating a random temporary resource locator to open your downloaded and cached files with an external app seems nicer than just giving the app read access to all your files, doesn’t it? That’s what we did.
peerio-cordova-socialshare
Why does a social sharing plugin need write access to your storage? Who knows! We don’t need that, though.
Conclusion
Remember — open source is not a guarantee of security. When you use open-source code, it is still your duty to check the code for possible vulnerabilities.
