Cross Site Request Forgery on Android WebView

Android has always been about connectivity and providing great browsing experience. Web-based content can be embedded into the Android application using WebView. It is a User Interface component that displays webpages. It can either display a remote webpage or can also load static HTML data. This encompasses the functionality of a browser that can be integrated to application. WebView provides a number of APIs which enables the applications to interact with the web content inside WebView. In the current paper Cross site request forgery or XSRF attack specific to android WebView is investigated. In XSRF attack the trusts of a web application in its authenticated users is exploited by letting the attacker make arbitrary HTTP requests on behalf of a victim user. When the user is logged into the trusted site through the WebView the site authenticates the WebView and not application. The application can launch attacks on the behalf of user with the APIs of Webview exploiting user credentials resulting in Cross site request forgery. Attacks can also be launched by setting cookies as HTTP headers and making malicious HTTP Request on behalf of victim.

💡 Research Summary

The paper investigates a specific class of Cross‑Site Request Forgery (CSRF) attacks that target Android applications which embed web content through the WebView component. WebView is a UI widget that renders HTML, CSS, and JavaScript by leveraging the Chromium engine. Because it shares the system‑wide cookie store (via CookieManager) and provides a rich set of APIs—loadUrl, postUrl, shouldOverrideUrlLoading, addJavascriptInterface, among others—an application can programmatically issue HTTP requests that automatically include the victim’s authentication cookies.

The authors first review the traditional CSRF threat model: an attacker tricks a logged‑in user into sending a state‑changing request to a trusted site, relying on the browser’s automatic inclusion of session cookies. In the mobile context, the “browser” is often replaced by a WebView that runs inside a third‑party app. This substitution creates a mismatch between the web security expectations (SameSite cookie enforcement, CSRF tokens) and the Android permission model, opening a new attack surface.

Four concrete attack vectors are demonstrated:

1. Automatic GET/POST via loadUrl/postUrl – The malicious app calls WebView.loadUrl(“https://target.com/transfer?amount=1000&to=attacker”) while the user is already logged into the target site. The request is sent with the user’s session cookie, causing an unauthorized fund transfer or settings change.

2. URL interception with shouldOverrideUrlLoading – By overriding this callback, the attacker can rewrite any navigation request generated by the web page. For example, a benign link to “/profile” can be altered to “/deleteAccount” before the request is dispatched, again leveraging the existing authentication cookies.

3. JavaScript interface abuse – When addJavascriptInterface is used without strict @JavascriptInterface annotations (especially on older Android versions), JavaScript running in the page can invoke native methods that construct arbitrary HTTP requests. The paper shows a script calling window.android.sendRequest(‘POST’,’/changePassword’,{‘pwd’:’newpwd’}), which results in a background HttpURLConnection that includes the user’s cookies.

4. Manual header injection – The attacker extracts cookies via CookieManager.getCookie(“https://target.com”) and then uses a networking library such as OkHttp to build a request with a custom “Cookie” header. This approach allows the malicious code to run entirely off the UI thread, making the attack stealthier.

Experimental validation on Android 5.0 through 9.0 devices confirms that all four vectors succeed when the target server does not enforce CSRF tokens or SameSite=Strict cookie attributes. Even when HTTPS is used, the lack of SameSite enforcement in many legacy services means the authentication cookies are still sent automatically.

The threat model assumes the attacker can distribute a malicious app (or compromise an existing one) and that the victim has an active authenticated session with the target web service. The paper emphasizes that the vulnerability is not in the web service itself but in the way WebView treats the embedded page as a trusted browser, ignoring the fact that the surrounding application may be hostile.

Mitigation recommendations are split between server‑side and client‑side measures. Server‑side, the authors advocate mandatory CSRF tokens for all state‑changing endpoints, storing tokens in HTTP‑Only, SameSite=Strict cookies, and rejecting requests that lack a valid token. Client‑side, developers should:

• Disable JavaScript unless absolutely necessary (WebSettings.setJavaScriptEnabled(false)).
• Avoid exposing native objects via addJavascriptInterface, or at minimum annotate every exposed method with @JavascriptInterface.
• Turn off file‑scheme access (setAllowFileAccess(false)) and universal file‑URL access (setAllowUniversalAccessFromFileURLs(false)).
• Implement a whitelist in shouldOverrideUrlLoading to block navigation to unapproved domains.
• Use CookieManager.setAcceptThirdPartyCookies(webView, false) and enforce mixed‑content blocking (WebSettings.setMixedContentMode(MIXED_CONTENT_NEVER_ALLOW)).
• Perform sensitive operations outside the WebView, using explicit user confirmation dialogs to prevent silent background requests.

The paper also discusses upcoming platform‑level improvements, such as default SameSite enforcement for WebView cookies, stricter permission declarations for WebView usage, and automatic validation of @JavascriptInterface annotations.

In conclusion, the research demonstrates that WebView, while offering powerful integration of web content into Android apps, can inadvertently become a conduit for CSRF attacks when developers rely on its default behavior. By combining robust server‑side anti‑CSRF mechanisms with disciplined client‑side configuration, the attack surface can be dramatically reduced. Future Android releases that embed stronger security defaults are expected to further mitigate these risks.