There has recently been a high profile ‘Same Origin Bypass’ security issue regarding the Android browser, prior to Android 4.4 KitKat, that allows a client session on one site to affect a client session on another. TrendLabs have just posted some information that shows that this vulnerability has wider reach than first thought. Like me, you might have thought it was only a web browser problem in that visiting one infected site can then cause problems when you visit further sites. However, as TrendLabs state…
"A more significant problem right now might be apps that show a website within their own user interface. Messaging apps, or other apps where users can view an arbitrary URL, are a particular problem if the site is opened within the app and not sent to the user’s default browser."
There’s a new informative article at IOActive on how personal banking apps leak information. While the article concentrates on banking apps and iOS, the information is just as applicable to other types of apps and other mobile operating systems such as Android.
Ariel Sanchez of IOActive Labs took a look at 40 banking apps from the top banks in the world. Tests included SSL (session handling, valid certs), compiler protection, use of webviews, use of SQLite as well as anti-tampering analysis.
The analysis is very alarming. Put simply, banking apps, that should be more secure than most other apps, can’t be trusted.
However, security isn’t just for banking apps. Snapchat is a very recent example of an app exposing 4.6 million users’ usernames and phone numbers. Poor security can damage your reputation. So what can you do? IOActive gives some pointers…
- Ensure that all connections are performed using secure transfer protocols
- Enforce SSL certificate checks by the client application
- Protect sensitive data stored on the client-side by encrypting it using the iOS data protection API
- Improve additional checks to detect jailbroken devices
- Obfuscate the assembly code and use anti-debugging tricks to slow the progress of attackers when they try to reverse engineer the binary
- Remove all debugging statements and symbols
- Remove all development information from the production application
I have covered many of these areas in previous posts…
In 2007, I observed that most of the few non-game Java ME applications that had become successful, performed most of their processing at the server. Last year I wrote about WebView applications and commented on how useful these are for some types of application.
WebView applications are just a web site embedded inside an application. It’s easy to create these on most platforms:
With Java ME, up until now, you have had to hand-craft your own mini HTML rendering engine. However, LWUIT now supports a new HTMLComponent. This makes it much easier to create cross-platform WebView applications that include Java ME.
Around two years ago I asked why there weren’t that many successful Java ME consumer applications that weren’t games. I went on to conclude that the few that were successful were just a window on more open, capable and consistent processing somewhere else.
It’s interesting to see that a number of development frameworks for several development platforms have evolved around this model of having a view on what’s essentially mainly happening at a server somewhere. In fact, even without these frameworks most platforms (except Java ME) have some kind of webView that can be embedded within an application.
WebView apps give many of the advantages of full native applications (use of phone APIs/features and discoverability via app stores) with the main disadvantage that the application itself needs a data connection at the time the user uses the application. Also, using a web oriented interface sometimes isn’t as usable as an equivalent interface made up of the phone’s native controls.
Sometimes it’s possible to use a webview instead of a plain text view to show application information. This allows information such as help or troubleshooting to actually reside online somewhere where it can be changed easily. Alternatively, it allows advertisements to be easily embedded in applications results because most ad systems are oriented towards embedding code in web pages.
I have done a few feasibility studies recently where a webView type application made a lot of sense. They tend to be applications that people will use for the specific unique content as opposed to those that need to compete with other applications on features or user experience.