Showing posts with label Android security. Show all posts
Showing posts with label Android security. Show all posts

Sunday, 16 November 2014

Tuesday, 11 November 2014

Showing posts with label Android security. Show all posts
Showing posts with label Android security. Show all posts

Sunday, 16 November 2014

Security Considerations for Hybrid Android Applications

In Android versions before 4.2 (Jelly Bean, targetSdkVersion 17), the JavaScript layer, upon getting access to the exposed Java object, can access all of the object's public members using reflection. Reflection is a powerful set of APIs, commonly used by programs that require the ability to examine or modify the runtime behavior of applications running in the Java Virtual Machine. For platforms before API level 17, you can use reflection inside of JavaScript by calling something like:

function execute(cmdArgs) {

boundObj.getClass().forName("Java.lang.Runtime").getMethod("getRuntime",

null).invoke(null,null).exec(cmdArgs);

}

var p = execute(["/data/data/com.yourapp/malicious-app"]);

document.write(getContents(p.getInputStream()));

This could allow an attacker to run malicious Java code in the host application's context, which could pose a security risk. As an application developer, care must be taken to ensure that we expose the Java object to WebView only as necessary, especially in the case of running JavaScript from untrusted sources such as external websites and so on.

 

HttpOnly Cookies and the Secure Flag

 

Cookies are one of the most common ways developers store application data. Among other things, it is used to remember the state of the web application in the previous run. Access to this data by untrusted JavaScript could pose a huge risk to your application. To prevent this, you can make your cookies HttpOnly in the HTTP response. The HttpOnly cookie flag became a standard with the RFC #6265 document that can be found at the ietf.org website.

 

An HttpOnly flagged cookie cannot be stolen easily via non-HTTP methods, such as JavaScript or Flash using document.cookie as a pervasive attack technique. Here's an example of how the HttpOnly attribute is visible in the HTTP headers:

 

HTTP/1.1 200 OK

Content-Type: text/html; charset=utf-8

Set-Cookie: id=cdb6352b48e62e0691efe552e3e4cecb; path=/; HttpOnly

 

If you use the SSL protocol for delivering your web content and need to set cookies using JavaScript, then you need to enable the secure flag in your cookie function in order to set a secure cookie.

 

document.cookie = "name=value; expires=date; path=path; domain=domain; secure";

 

Preventing Local Files from Being Loaded in the WebView

 

The setAllowFileAccess() API allows developers to control access to local files by the WebView. This API is one of several WebView settings you can configure at runtime. By default, this setting is enabled for accessing files in the filesystem. This setting does not restrict the WebView to load local resources from the file:///android_asset (assets) and file:///android_res (resources) directories. For security reasons, if your app does not require access to the filesystem, it is a good practice to turn this setting off.

 

settings.setAllowFileAccess(false);

Tuesday, 11 November 2014

Interception of HTTPS Traffic between Android Device and External Server

Sometimes it's interesting to see what different Android applications exchange through HTTP and HTTPS protocols. Sometimes, when developing one's own SW it's convenient to see the whole traffic in real time. To solve these tasks many different and good applications have been developed, e.g. Charles or Fiddler2. In fact, they are more numerous, but only the two mentioned allow seeing not only HTTP but also HTTPS.

Troubles appear in the interception of traffic between an Android device and an external server. With encoded (HTTP) traffic all is rather obvious (here's a guide) — external links are allowed with Fiddler2, in Android the address of our machine with Fiddler2 is set as a server — and voila, all is up and running. But it took me a bit longer to set up HTTPS traffic interception.

Theory

So, what's the trouble? The trouble is that using HTTPS the client verifies by default whether the server it connects to is the right one. For this purpose certificates are used. So, the real server has, of course, a real certificate that matches the open URL, while our proxy does not have one. To deal with the problem in desktop OS, Fiddler2 offers a possibility to generate a fake certificate and import it to the trusted ones — now the client will always believe that connection to Fiddler2 is quite safe. Unfortunately, mobile devices did not buy this dummy.

Primarily, it is impossible to import certificates in Androids older than v.4.0. There are some doubtful options with routed devices but they don't suit us. Secondly, it is impossible to import a Fiddler2 certificate even in Android 4.0. The thing is the certificate generated by default fails to meet some security criteria of Android and can't be installed. It should be generated in a special way. Finally, we can't take it for granted that all applications will trust a fake certificate. There are some niceties.

Usage

  1. Take an Android 4.0 or higher device. No, a 2.3 device won't suit. Yes, a 4.0 emulator will suit.
  2. Install the latest version of Fiddler2 on your PC.
  3. Install special libraries to generate Android-compatible safety certificates (here).
  4. Export the security certificate from Fiddler2 («Tools > Fiddler Options > HTTPS > Export root certificate to Desktop»). Save it on your flash drive, into the root directory (or in your emulator, if you're using one).
  5. Add the security certificate to the trusted ones in Android («Settings > Security > Install from SD card»)

  6. Start Fiddler2, allow remote connections in Options.

  7. Enter the address of the PC with Fiddler2 as the proxy in network settings of Android.

  8. Open browser on Android, enter google.com and observe the request and response in the Fiddler2 window.

So, it worked with the browser, but, unfortunately, not all applications are as trustful as the browser. E.g. my soft, where I use Apache HTTP Client, didn't buy it the Apache client couldn't care less about the OS trusted certificates. In this case I had to disable this verification manually as follows:

Protocol.registerProtocol("https", new Protocol("https", new EasySSLProtocolSocketFactory(), 443));  

where EasySSLProtocolSocketFactory comes from here and allows trusting any certificates