There is an infinite number of applications and resources available to millions of users. And as these numbers grow, security concerns raise as well.
Everything nowadays is all about connectivity and delivering a great, secure and transparent browsing capability. With this in mind, web-based content can be embedded into Android applications using a resource called WebView. Using this component brings many functionalities, but it can also be a huge risk. That is why assuring WebView secure coding is so important.
WebView is a system component that allows Android apps to display content from the web directly inside an application, creating the concept of hybrid apps. An app can be Native, Hybrid or Web (HTML5).
The WebView allows a Hybrid approach, the creation of Native apps that load local or external web content. This combines the strength of Native apps (more performance and functionality) with the strength of Web apps (portability) and is the reason why many companies are using it today.
The focus of this guide is to provide ground programming guidelines that can minimize the risk of developing a vulnerable app. The WebView component has been strengthened over the years but can still be easily abused if no security measures are followed during implementation.
Loading Clear-Text Content
Loading Clear Text Content (LCTC) consists of loading web content without encrypting traffic, making it vulnerable to Man-in-the-Middle (MitM) attacks. This kind of attack can lead to the leakage of sensitive information or traffic manipulation.
If credentials are obtained during a MitM attack, the attacker can then assume the victim’s identity for that specific website. In addition to other information that may be gathered (such as the email address), the consequences can be much worse as it is well known that users reutilize the same password for several different services.
In the following image, it is possible to see an example of clear text content loaded from a login web page where credentials are easily intercepted:
Without enforcing encryption through SSL/TLS, the attacker can also make changes to the intercepted traffic to, for instance, inject a keylogger in the HTTP response and then gather much more information from the user.
The Java code in this example is shown below. The use of HTTP protocol should be replaced by HTTPS. Using SSL/TLS requires a properly signed certificate installed on the web server but it is a completely worth implementation.
Keep in mind that since API 23 (Marshmallow) there is the “android:usesCleartextTraffic” flag that can be set to false on the Manifest to prevent clear text content from being loaded. Its default value is true.
SSL Error Handling
As we previously said, improper SSL Error Handling can lead to severe security breaches. By default, a WebView will not load web content if errors are detected during the SSL/TLS negotiation. The most common scenario in which these errors happen is when the server certificate is not signed by a recognized authority.
Instead of obtaining a properly signed certificate, many development companies choose to implement bypassing mechanisms that ignore certificate errors. With this approach, there is no need for a valid certificate but the application becomes vulnerable to Man in the Middle (MitM) attacks, presenting the same risk as the situation described in the section above. With the help of a homemade invalid certificate, the attacker is able to intercept and manipulate traffic.
In the following example (starting with the image to your right), a WebView was implemented to load the webpage https://github.com. A MitM attack was performed and the result in the victim device is an empty screen because the WebView detected the invalid certificate and didn’t establish the connection to the GitHub server.
The following error is displayed on the debugger:
If a bypassing mechanism to SSL errors is implemented, the attacker is able to fulfill the attack. This is shown in the following image where traffic interception and HTML code injection were performed by the attacker after the bypassing mechanism was implemented. The GitHub page is now loaded and the injected code is executed.
As mentioned before, the default behaviour is to block improper SSL/TLS connections. Obtaining and installing a certificate signed by a recognized authority should always be the approach to take as it is the only secure option.
So, if the value “Player’s name<script>window.location.href=’http://evilpage.com’;</script>” is introduced at the end of the game, the scoreboard WebView will render this injected malicious code and instead of showing the scoreboard, it will show the contents of evilpage.com, as you can see in the following image.
Accessing Local Resources
It is possible for a WebView to access local resources by default, although some restrictions are enforced. These restrictions may vary with the API being used. Here is a list of methods that can be used to change the WebView default permissions:
- setAllowContentAccess – its default value is “true” and allows the WebView to access content providers. Content providers are usually created to allow secure data sharing between applications.
- setAllowFileAccess – its default value is “true” and allows the WebView to load content from the filesystem. For this a “file:///” schema is used.
As described above, the WebView can load local resources by default and the “file:///” schema must be used with caution because it may lead to unauthorized file access.
For awareness, a small vulnerable app was prepared and a successful attack is described next. The vulnerable app is a game and uses a WebView to display the player’s avatar, relying on the following code:
If it is possible to manipulate the player’s name in the application, controlling the result of the showPlayerName function, allowing other files to be obtained from the local system instead of the user’s avatar. If an attacker controls the showPlayerName function in a way that it returns the value “../../../storage/emulated/0/Pictures/pic001.jpg”, an image from the smartphone photo gallery is displayed in the WebView, as it is shown below.
Avoid allowing the WebView to access local files in a dynamic way. If a static implementation is not possible, analyse the option of keeping the default “false” value in the methods “setAllowFileAccessFromFileURLs” and “setAllowUniversalAccessFromFileURLs”.
Despite bringing outstanding features, they are also considered a huge security risk. This is because the attacks referred to in the sections above can have much more impact, if succeeded, by interacting with the app code.
Validating Content from Third-Parties
Knowing that WebViews are commonly vulnerable to Cross-site Scripting (XSS) and Man in the Middle (MitM) attacks it is advised to implement additional security restrictions, providing a safer environment to the application’s users.
Validating the origin of the content being loaded by the WebView is a good security precaution. It can be implemented by overriding the shouldOverrideUrlLoading and the shouldInterceptRequest methods.
The shouldOverrideUrlLoading is related to the opening of new web pages by the WebView. The shouldInterceptRequest is more intrusive, allowing the control of every resource accessed by a web page loaded in a WebView.
This is a very effective way to secure the WebView. Additional features can be added, such as an alert in case of attack detection.
Android WebView Local File Access Restriction Bypass (CVE-2014-6041 and notfound trick): https://harupuxa.blogspot.pt/2014/09/webview-local-file-access-restriction.html;
Android WebView: http://searchsecurity.techtarget.com/definition/Android-Webview;
Bug Bounty, 2 years in: https://blog.twitter.com/engineering/en_us/a/2016/bug-bounty-2-years-in.html;
Bulletproof Android: Practical Advice for Building Secure Apps, 2014
Cross-site Scripting Attacks on Android Hybrid Applications: https://www.researchgate.net/publication/316309711_Cross-site_Scripting_Attacks_on_Android_Hybrid_Applications;
Do not allow WebView to access sensitive local resource through file scheme: https://www.securecoding.cert.org/confluence/display/android/DRD02-J.+Do+not+allow+WebView+to+access+sensitive+local+resource+through+file+scheme;
Java Script Injection Vulnerability in Android Apps – Android App Security: https://www.appvigil.co/blog/2015/04/java-script-injection-vulnerability-in-android-apps/;
Secure Integration of Web Content and Applications on Commodity Mobile Operating Systems, 2017;
The Mobile Application Hacker’s Handbook, 2015;
Attacks on Android WebViews: http://resources.infosecinstitute.com/android-hacking-security-part-7-attacks-android-webviews/;
WebView Vulnerabilities in Android Applications: http://scrub.cs.berkeley.edu/wp-content/uploads/2013/05/WebViewsSCRUBPresentation.pdf;
Follow WebView Best Practices: https://github.com/nowsecure/secure-mobile-development/blob/master/en/android/webview-best-practices.md
Android Security Tips: https://developer.android.com/training/articles/security-tips.html
Adventures with Android WebViews: https://labs.mwrinfosecurity.com/blog/adventures-with-android-webviews/
Android WebKit: https://developer.android.com/reference/android/webkit/package-summary.html
Android WebView: https://developer.android.com/reference/android/webkit/WebView.html
High Performance Mobile Web, 2016;
What is a hybrid mobile app: http://developer.telerik.com/featured/what-is-a-hybrid-mobile-app/
Android WebKit WebSettings: https://developer.android.com/reference/android/webkit/WebSettings.html
Securing WebViews in Android Applications: https://datatheorem.github.io/2014/03/21/securing-webviews-android/
Secure Usage of Android WebView: http://blog.opensecurityresearch.com/2014/04/secure-usage-of-android-webview.html
Android WebView Vulnerabilities: https://hackertor.com/2017/02/13/android-webview-vulnerabilities;
Sign up today & never miss an update from the Checkmarx blog
*** This is a Security Bloggers Network syndicated blog from Blog – Checkmarx authored by Erez Yalon. Read the original post at: https://www.checkmarx.com/2017/11/16/android-webview-secure-coding-practices/