Vulnerabilities that lead to account takeover in banking and fintech mobile apps | Oversecured Blog

What it is

Oversecured's vendor guide lists eight vulnerability classes that give an attacker a valid session token in Android and iOS banking and fintech apps without the user's password. The page's central claim is that these flaws sit in chains across components, so single-line pattern scanners miss them. The summary lists the categories. This document keeps the mechanisms, the controls that break each chain, and the page's triage advice.

How it works

• WebView token leakage: a deeplink such as bankapp://open?url=... loads an unvalidated URL into a WebView that exposes addJavascriptInterface() methods like getAuthToken(). Attacker JavaScript on the loaded page calls the bridge and sends the token out with fetch. The page ties this to Samsung SmartThings (CVE-2022-30746).
• Intent Redirection: an exported Activity, Service or BroadcastReceiver takes a nested Intent and passes it to startActivity(), startService() or sendBroadcast() without checking the target. The attacker uses it as a relay to protected components such as OAuth callback handlers or WebViews holding session data.
• Hardcoded tokens: API keys, OAuth client secrets or signing keys are extracted by decompiling the APK or IPA. The attacker then authenticates as the app itself.
• Deeplink hijacking: a malicious app registers the same URL scheme and receives the authorization code.
• Insecure storage: tokens sit in unencrypted SharedPreferences, in external storage, or in Logcat through forgotten Log.d("Auth", "Token: " + token) lines. The page says Logcat is the most common of the three.
• Localhost OAuth listener: Android does not isolate loopback sockets between apps, so another app can poll the callback port and race to exchange the code.
• AIDL abuse: onBind() or AIDL methods do not check the caller's UID or package. In SmartThings, REQUEST_AUTH_CODE, WEB_AUTH_MANAGER and ACTION_WEBVIEW_WITH_PASSWORD_EXTERNAL had no caller restrictions.
• Weak biometrics: BiometricPrompt or LocalAuthentication is not bound to a CryptoObject, or allows fallback to device credentials. Biometric re-enrollment also does not invalidate stored keys, so an attacker who enrolls their own biometric on a compromised device inherits the victim's state.

What to do

The page names these controls:

• Pair custom-scheme deeplinks with Android App Links verification or iOS Universal Link entitlements. The page says these bind the link to the app and stop other apps claiming it.
• Use PKCE for every OAuth redirect. A stolen authorization code is then useless without the code verifier.
• Replace localhost OAuth servers with the AppAuth library or Custom Tabs with PKCE.
• Validate the caller UID or package in onBind() and in AIDL methods.
• Bind biometrics to a CryptoObject. The page says this restricts the key to biometric access, forces reauthentication on every key use, and invalidates the key when a new biometric is enrolled.
• Validate the target of every nested Intent before forwarding it.
• Remove token logging before release.

For process, the page recommends:

• Check your SAST tool against the eight categories.
• Require a working proof of concept for findings rather than severity labels alone.
• Scan the compiled APK or IPA, including third-party SDKs, not only first-party source.

Taint analysis should trace sources (deeplink parameters, exported components, third-party intents, public file storage) to sinks (WebView URL loads, startActivity(), network requests, file writes, returned tokens). Dynamic testing then confirms exploitability by fuzzing exported components and sending crafted deeplinks.

Caveats

• The page is marketing for Oversecured's scanner. Its claims that pattern scanners catch "most" of these categories poorly, and that dynamic PoC generation yields "almost none" false positives, have no data behind them.
• Only the WebView chain has a code PoC. The other seven categories get descriptions only.
• The compliance mapping is brief. It names MASVS-AUTH, MASVS-STORAGE and MASVS-PLATFORM, and PCI DSS v4.0 CWEs (CWE-287, CWE-288, CWE-306, CWE-798), and lists PSD2 SCA and FFIEC guidance without control-level detail.
• The threat statistics (Kaspersky's 3.6× growth in banking Trojan encounters in 2024, Zimperium's 34 malware families) are context and not evidence for any specific category.
• The page admits that unencrypted SharedPreferences is a loss of control over credentials, not a flaw exploitable from inside the app's own process.