7 Replies Latest reply on Dec 12, 2014 3:27 AM by Arsen Bandurian

    How vulnerable are Rho apps?

    Mark Nongkhlaw

      I just stumbled on this : http://www.itworld.com/article/2842676/why-you-should-worry-about-html5-mobile-apps.html


      Wonder how safe apps built with Romobile are to code injection attacks. Anyone can throw us some light on this?

        • Re: How vulnerable are Rho apps?
          Pietro Francesco Maggi

          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.

          Showing that a WIFI SSID containing Javascript code in it's name can be executed by an hybrid app and not by a Java or Objective-C app... brilliant!


          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_html to 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::Util module and in your templates, print values with<%=html_escape @value %> or the shorthand version <%=h @value %>



          • Re: How vulnerable are Rho apps?
            Jon Tara

            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:


            - While I wouldn't consider it a vulnerability (if you've minded the points above) it would enhance security to not use the Javascript APIs. Use the Ruby APIs. The less power available fromJavascript the better.


            - Keep in mind, as well, that all of your controller endpoints can be accessed from javascript, and create an informal and probably poorly-documented "api". You can enhance security by making internal controller methods that do not need to be accessed from the WebView private. They won't be accessible from the webview.


            - In many cases (depending on platform) users can attach a USB cable and use remote browser inspection tools. Consider if you might have hostile users. This will give them a great deal of access. A USB cable and Safari Web Inspector or Chrome Developer Tools make the "random" server port easily discoverable. The user can then observe interaction between the WebView and the Rhodes server and look for vulnerabilities. Which in typical apps I presume would be numerous. Is a Rhodes app a closed system? In most cases, no. Can you rely on your Javascript code that validates form values? No.


            - Note that if you enable the Javascript API, then a user with a USB cable, inspection tools, and Rhodes documentation can do as he pleases and make any Rhodes API call whatsoever. (I'm unaware of what options may be available for locking this down - say, on specific security-enhanced Android, etc.) I think this can be locked-down for iOS for managed devices. (e.g. corporate-issued device where the company uses Apple's device-management software.)


            - In general, it will enhance security to work in Ruby as much as possible. The Ruby code is compiled to byte code and not easily read. There is no way to usefully "debug" the Ruby code, but a user with a USB cable and easily available tools can view your Javascript code, set breakpoints, look at values, etc. How many of us validate all form fields in Ruby, in addition to any validation we do in Javascript for the user's sake? If you want tight security, you have to treat the WebView just as you do a browser for a conventional website. JS validation is for the user. Server (in our case) Ruby validation is for security and integrity.


            - Don't do Ajax to external sites or even your own in Javascript! Not if there is any security issue at all. (Is there a password? Some other kind of authentication?) Access the external site in Ruby code (which also solves CORS issues.)

              • Re: How vulnerable are Rho apps?
                Jon Tara

                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

                Actually, your app doesn't have to be a WiFi Scanner. The vulnerability is in displaying an SSID in a WebView. The SSID might contain Javascript, and if you display it without removing HTML tags, the SSID might contain some Javascript which then will get executed.

                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:

                  def html_escape(s)

                    s.to_s.gsub(/&/, "&amp;").gsub(/\"/, "&quot;").gsub(/>/, "&gt;").gsub(/</, "&lt;").gsub(/\'/, "&apos;")


                  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.


                Escaping HTML-unsafe characters in view of RhoMobile


                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.


                  • Re: How vulnerable are Rho apps?
                    Mark Nongkhlaw

                    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...

                    • Re: How vulnerable are Rho apps?
                      Jon Tara

                      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).


                      Of course, you still need to be careful that user or outside-world-supplied strings embedded into a page must either be scrubbed or HTML-escaped so that Javascript scripts are not inadvertently injected into the WebView DOM. Similar to steps commonly take to make sure that SQL fragments aren't injected into database requests.

                        • Re: How vulnerable are Rho apps?
                          Mark Nongkhlaw

                          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.

                    • Re: How vulnerable are Rho apps?
                      Arsen Bandurian

                      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...