Let's clear something up first:
I understand the main concept of XSS; on a regular website it could be achieved by for example redirecting someone to a URL with a manipulated query string in it.
No, XSS is when an attacker can inject code into client side code which is executed client side. The injected code can show an overlay (login screen for phishing purposes), perform requests on behalf of the user (call API endpoints to perform XYZ actions), redirect the user to malicious website etc...
The delivery point can vary. Using the query string in a URL is considered a reflected XSS. But say for example you're able to deliver an XSS payload via a comment on a forum, that's stored/persistent XSS. Check out the OWASP XSS page for more information.
The above explanation is usually explained in the context of a browser. Now WebViews are essentially "embedded browsers" in a mobile application. The above attack scenarios apply to WebViews as well. There's a small variation though!
First, in the context of Android and iOS, there are two types of WebViews: WebViews that essentially launch a new browser (SFSafariViewController on iOS, Chrome Custom Tabs on Android) and traditional WebViews. As far as I understand, the former is more isolated (process/permission wise) than the latter. Accessing "app data" in non-traditional WebViews is therefore harder since it requires sandbox escape exploits. For reference, each app inside Android/iOS have their own user/group ID. The app data for each app can only be accessed by the app itself (sandbox restriction).
Second, WebViews can be hardened by disabling JavaScript entirely. Most interesting XSS payloads are delivered via JS. HTML/CSS payloads can still redirect or change the layout of the webpage though!
Third, since WebViews are part of the app, it means that they can access own local app data via file://
handler. The problem? Browsers and therefore WebViews disallow Cross Origin requests. Meaning that a website served on example.com
, cannot make requests to www.evilwebsite.com
or file://
unless some CORS headers are set. There's one edge case though: sometimes mobile apps download a webpage via a custom HTTP client, save it locally and then open the saved webpage in a WebView. Now we don't have a Cross Origin issue, and it's possible to access app data. This is however one of those cases where the moon and stars need to align:
- Successfully deliver a XSS payload
- Vulnerable webpage is used by the mobile app
- The mobile app programmatically downloads the page, saves it and displays it in a WebView (cross origin ✅)
- Mobile app WebView is configured to allow JavaScript (in Android for example, you need to explicitly enable JS)
- Interesting (unencrypted) data needs to be available in app data folder (such as shared preferences file) in order to make this attack viable in the first place.