The original paper is a fascinating reading http://www.cis.syr.edu/~wedu/Research/paper/code_injection_most2014.pdf
I can summarize it with, if you do something stupid in your app, like injecting data directly into the DOM, you're in danger.
Going back to your question: "how safe are RhoMobile apps to code injection attacks?"
With a RhoMobile app you're less vulnerable to code injections due to low-level errors that are handled by the framework and should be well ironed at this point. Building the interface in HTML5, and attaching "data" coming from the outside world to the DOM without validation... is dangerous and can beat you.
BTW, the framework include "escape_html": http://docs.rhomobile.com/en/5.0.0/guide/uichoices
If you need to output values that might contain HTML-unsafe characters, you can use ERB’s
escape_htmlto ensure that your code is escaped properly. This will help against accidental breakage as well as intentional XSS attempts. In your controller, include the
ERB::Utilmodule and in your templates, print values with
<%=html_escape @value %>or the shorthand version
<%=h @value %>
I don't understand this point, it sounds like nonsense. I'd like to see the details of this. Other points are well-taken.
For example, code can be injected as part of the SSID for a Wi-Fi hotspot
- The biggest point of vulnerability is using the WebView to access external sites. Don't do it. External sites are more appropriately opened in the device's browser, anyway, so that it doesn't interfere with your navigation. (Seen plenty of PhoneGap apps that go off to some external site, the site has no back button, and then you have to close and re-open the app!) You might be tempted to use a Rhodes tab to load an external site. Don't!
- Next is loading the WebView directly from your own site, using http:. Don't. Use https:
I don't think many of us have to be concerned about the "SSID attack". Your app would need to be a WiFi Scanner!
Wi-Fi Access Point. To find nearby Wi-Fi access points, many smartphone users install some Wi-Fi scan- ner apps, which scan for all the available Wi-Fi hotspots nearby, and display their Service Set Identifiers (SSIDs) and other information to users. Figure 3(a) shows the display results from WIFI Analyzer, which is a free app downloaded from Google Play. There are more than 250 similar apps in Google Play, some of which are quite popular with more than ten million downloads.
Because of the popularity of such apps, it is not hard to imagine that in the near future, some of the apps like this will be HTML5-based
This really a more general vulnerability. You should always HTML-escape ANY data from ANYWHERE being displayed in a WebView. Rhodes provides a handy helper for this.
Here's a handy helper for this. Somehow, I had though that this was provided in browser_helper.rb, but I see (at least in 5.x) it isn't. So, this is code from our own apps:
s.to_s.gsub(/&/, "&").gsub(/\"/, """).gsub(/>/, ">").gsub(/</, "<").gsub(/\'/, "'")
alias h html_escape
Use it on EVERY value (e.g. from a variable) that you embed in page text!
If there is HTML embedded in a string, then, it will display the HTML source and the HTML will not be interpreted.
Edit: Here's an undocumented bit that might explain why this was (apparently - need to look at old projects...) removed from helpers. There's an escape function available in ERB::Util.
Hmmm... I'm uncertain if that is correct, though. ERB::Util is part of Rails. Is it now available in Rhodes?
Edit: No, sorry, the above link is a misinformed blog post. Rhodes does not have ERB::Util. Provide your own definition of html_escape, unless Rhodes has moved it somewhere else. I don't see it in the supplied helper files for 5.x.
Hi Pietro, Jon, Thank you for the constructive comments. We're looking at the future when our apps (especially the consumer facing ones) need to get thru security audits. We're looking at the perceived advantages of Rho allowing the use of good old Ruby instead of JS to mitigate such attacks. I've always had the lurking suspicion that dumping Ruby for JS is never a good idea. I just needed to re-read my classic Active Server Pages book to remind myself about it. I think using web technology in a mobile app exposes the app to the same risks as web apps. JS, CSS, JQM and other client-side technologies that might help to make your app look or function more fancily might in fact open up more security holes. My concern is the stress on JS lately. I feel there's no excuse for not learning and using Ruby, and none for not supporting more APIs in Ruby. In fact, there should be more focus on fortifying the 'server'.
These are some of my thoughts...
Then danger from a user with a USB cable is less than I stated above, at least for iOS.
It's not possible (at least trivially) to use remote Safari Web Inspector on an app delivered by iOS App Store. I believe that's also true for TestFlight. It has to have been installed by USB with a developer profile.
This does give Rhodes and PhoneGap apps some security leg up on "web apps". A user with a USB cable (or just a desktop browser!) can inspect a Web App, easily discover REST endpoints, "secret" request parameters, etc.
Rhodes apps are of course subject to inspection with WireShark, etc. to discover communication with any Internet resources. But the interface between JS and the Rhode server seems reasonably secure. (at least for iOS).
Another concern is database encryption. From the docs :
As of Rhodes version 3.3.3, Rhom data encryption
is removed from Rhodes. This feature is only supported in Motorola
RhoMobile Suite. If you wish to use this feature, you will need to
upgrade to RhoMobile Suite purchase a RhoElements license is required.
There's no point in taking all the other precautions when a user can in fact access an unencrypted database. Wonder why this feature was removed at all as it is a glaring risk for both enterprise as well as consumer-facing apps.
OMG, a 15-page paper that can be summarized by one sentence every programmer should know anyway: "Sanitize your inputs!".
No framework will protect from bad programming...