Protecting hybrid apps from attackers [Q&A]

In order to speed up development times and roll out their apps across multiple platforms without the need to create entirely new code, companies are increasingly turning to hybrid apps. The problem is that these rely on HTML and JavaScript code which is relatively easy to reverse engineer.

How can businesses prevent this and keep their apps and the data they handle safe from hackers? We spoke to Andrew Whaley VP of engineering for Europe at application protection specialist Arxan Technologies to find out.

BN: What makes hybrid apps uniquely vulnerable?

AW: Companies have to put their apps out there and once they do they're necessarily exposed. What some of these apps are doing is quite sensitive, the way the authentication works, biometric profiling of users and so on. There's a lot of sensitive material in there and even just the way the back end APIs work can be useful to an attacker.

Hybrid apps are quite popular because they allow companies to develop one code base and deploy across many app platforms. There are a lot of frameworks which now do this and it's attractive for organizations to use. The problem this brings is that the source code is typically JavaScript HTML that has to be embedded in the app. This requires less skill to reverse engineer and tamper with than native binary code. Also because it runs in a browser with all of the browser capabilities around it, things like remote man-in-the-middle attacks are so much easier. Again this is harder to achieve with a binary app. Hybrid technology therefore represents a very specific security weakness.

BN: How are you protecting these apps?

AW: We're using a technique that involves a combination of obfuscation and runtime protection which helps keep apps secure. Obviously it's not infallible, if someone is prepared to put enough effort in they could bypass it, but it does make it much harder for the attackers. At Arxan we've spent a lot of time creating a product for hybrid apps that will match the security capabilities that are available on the native side.

BN: How does that work, are you putting another layer in between the application and the OS or the outside world?

AW: Because the JavaScript can run in a number of environments, WebKit on iOS or Chrome on Android for example, what we wanted to do was make the script itself self-defending. We apply a number of obfuscations to the JavaScript and basically transform it so it doesn't look like the original. We then weave in various anti-tamper controls, so it has the ability to checksum itself in runtime allowing us to detect whether it's been tampered with. We can do runtime profiling too so we can see what kind of environment it's running in, whether it's in a debugger for example. Because all of this is woven into the JavaScript it doesn't matter if you then take it out of context and run it somewhere else.

We also hide data values, so even if you can debug it and see what's going on inside it, it's very hard to make sense of because the program has been transformed from its original state.

BN: Is it possible to improve the protection further?

AW: There are other things we can do such as providing custom browser components. We have a specially hardened version of the code and there are definitely benefits to doing that, it's something we’re looking at for the future. But what we wanted to do was make sure that the JavaScript code itself was as strong as it could be before adding these additional layers.

BN: So all of this is built in at the developer stage?

AW: Yes, as part of the publishing process you run the code through this process and produce a new version of the code that’s been obfuscated. We call it 'transpiling' because you're putting in source code and getting out source code. They’re both JavaScript but the result looks nothing like the original.

There are other tools that do something similar, but one of the problems is that their run time protection is layered on top after the obfuscation. That makes it too easy, in our view, to separate the two. What we wanted to do was take an approach where we applied the integrity protection first then obfuscated the whole thing. This makes it much harder for the attacker to work out what was the original code and what was the protection and to separate them.

BN: Is this platform agnostic?

AW: Yes, as long as the engine is ES5 or ES6 compatible it will work. The technology isn't just limited to mobile apps either, it works in browser apps as well.

BN: Does this tie in with protecting data at rest and in transit via encryption?

AW: Most of our customers are already encrypting their data. The problem they have is that the APIs used for that encryption are vulnerable. It can be pretty trivial for an attacker just to call the relevant functions and get information decrypted. This further highlights a need to protect the application code and make the decryption routines harder to find.

BN: Who is the target customer, is finance or eCommerce?

AW: We've had a lot of interest from different sectors, primarily it’s finance, banking and insurance. Obviously they’re very concerned to guarantee the integrity of their apps and protect their content, particularly on mobile devices. Online gaming is another area where this can be applied, we've had a lot of interest from these companies because they’re often subject to cheating. People reverse engineer the code to work out how to post high scores, or to manipulate their game save state to give themselves unfair advantages. Media distributors too want to protect the DRM of their content. There's potential to use it to protect smart TVs and set-top boxes too, as a lot of their apps are just JavaScript.

Photo Credit: alphaspirit / Shutterstock