Mobile application testing has progressed significantly over the past few years. Whereas the early days of mobile security were more or less a wild west, efforts such as the Mobile Top 10 and testing guide from OWASP and courses like SANS 575 have helped to standardize both methodologies and expectations for testing. Tools like MobSF and expanded support in Metasploit and other industry touchstones have lowered the bar to entry for mobile testing as well.
That all being said, the attack surface for mobile applications is surprisingly huge with app testing including aspects of web app, traditional network, hardware, and even wireless pentesting. There is always room for new perspective and interesting techniques with new functionality, capabilities, and an ever evolving landscape constantly realigning the play field. One particular area where I don’t see a significant amount of emphasis currently being place is on WebView.
What is WebView?
WebView is a fully functional, configurable browser that can be embedded in apps to display web content. It is used within applications across all common mobile platforms. WebView isn’t a mobile specific function, but that’s the context in which I’ll be writing this article. The easiest way to recognize it on your mobile device is after clicking on a link within an app; if the page opens within the app itself rather than opening and switching over to your browser app, you’re in a WebView session. WebView can also be used to display ads and other embedded content right alongside other items within an app. Kirupa.com has put together a fantastic article which covers WebViews in a more detail, technical write-up.
Like a normal browser, WebView has controls and best practices. But unlike a normal browser, they are set at the individual app level during the development process. This inevitably leads to oversights and misconfigurations of which we can take advantage during a pentest. The chances of most of these exposures leading to a complete compromise of the app is slim, but WebView is nevertheless a facet of app testing that too frequently is overlooked.
Finding WebView
Identifying instances where a target app makes use of WebView is pretty straightforward. Anywhere you find links to external resources, you may discover WebView in use. Here are some common, obvious examples of pages where you might find WebView in use:
- Terms of Service (see Figure 1 for a general example)
- Account/Payment management pages
- Help/Frequently Asked Question functions
Once you’re “in” the browser, it’s time to start poking around.
Remote Chrome Debugging
It’s not uncommon to find instances where Android apps are released with debugging enabled. This can present all kinds of problems though nothing specific I’ll cover in this article. However, there is a separate debugging issue specific to WebView that is relevant to this discussion. Applications can be set to permit remote debugging of WebView through Chrome. With USB Debugging permitted on the test device on which the target application is installed, it is possible to view and manipulate traffic passed to and from the application in real time with any Chrome browser. The technique cannot be used to debug all of an app’s traffic outside of WebView. Nevertheless, it’s a useful technique and noteworthy oversight for production apps.
Breaking Out
Testing some of the security controls around WebView usually requires finding away out of whatever corner it places you. As previously mentioned, WebView is usually intended to display very specific pages or functionality for an app. This saves on development time and maintenance as a developer can simply call to an existing site rather than building this same functionality into the app to display the same information. Issues can arise if it is possible to navigate away from the intended functionality.
As WebView won’t give you a URL bar, as a tester, it occasionally takes some creativity to get to the general web. If possible, spidering the site which WebView is wrapping can streamline the whole process and paint a straightforward path. Otherwise, there are several frequently useful pages/functions to seek out.
- Social media links (usually to the app company or developer profiles)
- Youtube media links
- External, third party links (opens up your potential pathways)
- Search functions within the page can help by giving you a direct line to all of these
You ultimately want to get to a page that you control. There, you’ll be able to poke at WebView’s security in a controlled manner. There are a thousand ways to accomplish this. I will frequently find my way to Twitter, having created a one-off, temporary account, and have a public tweet with a shortened link that redirects to a private IP where I’m hosting a site hosting malicious JavaScript. The reason for the shortened link is to force Twitter to recognize it as a web address (IP address won’t do, even with the protocol specified). Secondly, it keeps the active testing off the Internet and in a controlled space.
Where’s the beef?
The browser exploitation framework (beef) is a penetration testing tool focused on browsers. Since WebView is really just a browser, we can easily use beef to check it for misconfigurations and other vulnerabilities. Once you have beef up and running, the defaults are sufficient for testing purposes. The terminal output provides links to the management portal and test pages with the ‘infecting’ JavaScript.
Directing WebView to one of these test pages provides two vulnerability checks automatically. If you can get to the page uninhibited, and the management portal shows your session as ‘hooked,’ there are no controls in place for either:
- JavaScript execution is permitted if the browser shows as hooked
- Cleartext transmission is allowed (since neither test page makes use of HTTPS by default)
beef also gives you tons of options for running additional tests from browser fingerprinting to session theft. I also typically will add cross site scripting and clickjacking vectors to my pages for additional checks.
Conclusions
There are all kinds of other testing that can be performed against WebView; anything that you would test for in a browser or web agent should be examined for instances of WebView in a mobile app. But hopefully these few examples are enough to get you started!
