deardaniel/secdata-raw huggingface dataset:
OWASP Mobile Application Security Testing Guide: MASTG DEMO 0104

---
platform: android
title: App Requesting SYSTEM_ALERT_WINDOW Permission
id: MASTG-DEMO-0104
code: [xml]
test: MASTG-TEST-0340
tools: [semgrep]
kind: info
---

## Sample

The manifest below is from an attacker app that requests the `SYSTEM_ALERT_WINDOW` permission, which allows it to draw overlays over other apps.

{{ AndroidManifest.xml # AndroidManifest_reversed.xml # MastgTest.kt }}

You can use this attacker app to demonstrate the vulnerability shown in @MASTG-DEMO-0103: install and run it while the victim app is in the foreground, then activate the overlay. This lets you verify whether the unprotected button in the victim app accepts touch events through the overlay.

Note that the `SYSTEM_ALERT_WINDOW` permission itself isn't a vulnerability in the app that declares it. It's a legitimate Android feature used by apps such as screen overlay tools, chat heads, or accessibility services. However, its presence means the app can display overlays over other apps, which can be used to conduct overlay attacks against victim apps that don't implement proper protections.

## Steps

Let's run our @MASTG-TOOL-0110 rule against the reversed manifest to check for the `SYSTEM_ALERT_WINDOW` permission.

{{ ../../../../rules/mastg-android-system-alert-window.yml }}

{{ run.sh }}

## Observation

The rule detected the `SYSTEM_ALERT_WINDOW` permission in the manifest:

{{ output.txt }}

## Evaluation

The finding confirms that this app declares the `SYSTEM_ALERT_WINDOW` permission. This isn't a vulnerability in this app itself; it shows that the app has the capability to draw overlays over other apps. The actual vulnerability lies in victim apps (like the one in @MASTG-DEMO-0103) that don't implement overlay protections on sensitive UI elements.

When assessing an app for overlay attack vulnerabilities, the threat model should include apps that can request `SYSTEM_ALERT_WINDOW` to create overlays.
OWASP Mobile Application Security Testing Guide: output

                   
                   
┌─────────────────┐
│ 2 Code Findings │
└─────────────────┘
                           
    MastgTest_reversed.java
     ❱ rules.mastg-android-overlay-protection-setfiltertoucheswhenobscured
          [MASVS-PLATFORM-3] setFilterTouchesWhenObscured is used to protect against overlay attacks
                                                                                                    
           54┆ $this$mastgTest_u24lambda_u245.setFilterTouchesWhenObscured(true);
   
     ❱ rules.mastg-android-overlay-protection-onfiltertoucheventforsecurity
          [MASVS-PLATFORM-3] onFilterTouchEventForSecurity is overridden for custom overlay protection
                                                                                                      
           64┆ @Override // android.view.View
           65┆ public boolean onFilterTouchEventForSecurity(MotionEvent event) {
           66┆     Intrinsics.checkNotNullParameter(event, "event");
           67┆     if ((event.getFlags() & 1) != 0) {
           68┆         Toast.makeText(getContext(), "Blocked obscured touch", 0).show();
           69┆         return false;
           70┆     }
           71┆     return super.onFilterTouchEventForSecurity(event);
           72┆ }
OWASP Mobile Application Security Testing Guide: MASTG DEMO 0103

---
platform: android
title: Missing Overlay Protection on a Sensitive View
id: MASTG-DEMO-0103
code: [kotlin, java]
test: MASTG-TEST-0340
tools: [semgrep]
---

## Sample

The sample demonstrates three buttons performing sensitive actions, each using a different overlay protection approach:

1. **Vulnerable button:** A button without any overlay protection, making it susceptible to tapjacking attacks.
2. **Protected button:** A button with `filterTouchesWhenObscured = true` to block touches when the window is obscured.
3. **Custom protected button:** A button with a custom `onFilterTouchEventForSecurity` override that manually checks for the `FLAG_WINDOW_IS_OBSCURED` flag.

{{ MastgTest.kt # MastgTest_reversed.java }}

To demonstrate this vulnerability in a live environment, you can use @MASTG-DEMO-0104, which shows an attacker app that requests the `SYSTEM_ALERT_WINDOW` permission to draw overlays over other apps. Running the attacker app while the victim app is in the foreground lets you verify whether the unprotected button accepts touch events through an overlay.

## Steps

Let's run our @MASTG-TOOL-0110 rule against the decompiled code to detect overlay protection mechanisms.

{{ ../../../../rules/mastg-android-overlay-protection.yml }}

{{ run.sh }}

## Observation

The rule detected two instances of overlay protection mechanisms in the decompiled code:

{{ output.txt }}

- Line 54: `setFilterTouchesWhenObscured(true)` is set on the protected button.
- Lines 64-72: `onFilterTouchEventForSecurity` is overridden to implement custom overlay protection, including a check for the `FLAG_WINDOW_IS_OBSCURED` flag (literal value `1`) at line 67.

## Evaluation

The test partially passes and partially fails:

**FAIL:** The first button ("Vulnerable: Confirm Payment") doesn't appear in the output, meaning it implements no overlay protection. This button performs a sensitive action (payment confirmation) and is susceptible to tapjacking attacks.

**PASS:** The second button (line 54) correctly implements overlay protection using `setFilterTouchesWhenObscured(true)`, which filters out touch events when the view is obscured by another window.

**PASS:** The third button (lines 64-72) implements custom overlay protection by overriding `onFilterTouchEventForSecurity` and checking the `FLAG_WINDOW_IS_OBSCURED` flag. This provides fine-grained control over how the app responds to overlay attempts.

In a real-world assessment, the unprotected button should be flagged as a finding. Sensitive UI elements such as payment confirmations, permission grants, or authentication controls should implement overlay protection using one of the demonstrated mechanisms.
OWASP Mobile Application Security Testing Guide: output

                   
                   
┌─────────────────┐
│ 4 Code Findings │
└─────────────────┘
                           
    MastgTest_reversed.java
    ❯❱ rules.mastg-android-sensitive-data-in-notifications
          [MASVS-PLATFORM-3] Ensure that notifications do not contain sensitive information
                                                                                           
           41┆ Notification notificationBuild = new                     
               Notification.Builder(this.context).setContentTitle("MASTG
               Test").setContentText(sensitiveString).build();          
            ⋮┆----------------------------------------
           41┆ Notification notificationBuild = new                     
               Notification.Builder(this.context).setContentTitle("MASTG
               Test").setContentText(sensitiveString).build();          
            ⋮┆----------------------------------------
           48┆ Notification notificationBuild = new Notification.Builder(this.context,                  
               "TEST_CHANNEL_ID").setContentTitle("MASTG Test").setContentText(sensitiveString).build();
            ⋮┆----------------------------------------
           48┆ Notification notificationBuild = new Notification.Builder(this.context,                  
               "TEST_CHANNEL_ID").setContentTitle("MASTG Test").setContentText(sensitiveString).build();
OWASP Mobile Application Security Testing Guide: MASTG DEMO 0078

---
platform: android
title: App Leaking Sensitive Data via Notifications
id: MASTG-DEMO-0078
code: [kotlin]
test: MASTG-TEST-0315
tools: [MASTG-TOOL-0110]
---

## Sample

The following sample code contains:

- the Kotlin code that creates a notification with the `NotificationManager` class and exposes sensitive data.
- the AndroidManifest.xml that declares the runtime permission `POST_NOTIFICATIONS` permission that allows the app to post notifications (Android API 33 and higher).

!!! note
    To execute the test on a device, we must ensure that the app has the `POST_NOTIFICATIONS` permission granted. This can be done either via the @MASTG-TOOL-0004 command, such as `adb shell pm grant org.owasp.mastestapp android.permission.POST_NOTIFICATIONS` or by navigating to the app settings on the device and manually enabling the permission.

{{ MastgTest.kt # AndroidManifest.xml }}

## Steps

Let's run our @MASTG-TOOL-0110 rule against the reversed Java code.

{{ ../../../../rules/mastg-android-sensitive-data-in-notifications.yml }}

And another one against the sample manifest file.

{{ ../../../../rules/mastg-android-sensitive-data-in-notifications-manifest.yml }}

{{ run.sh }}

## Observation

The rule detected two instances in the code where the `setContentTitle` API is used to set the notification title, and 2 cases where the `setContentText` API is used to set the notification text. It also identified the location in the manifest file where the `POST_NOTIFICATIONS` permission is declared.

{{ output.txt # output2.txt }}

## Evaluation

After reviewing the decompiled code at the location specified in the output (file and line number), we can conclude that the **test fails** because the notification contains sensitive data, specifically a first and a last name (PII).
OWASP Mobile Application Security Testing Guide: output2

                   
                   
┌─────────────────┐
│ 2 Code Findings │
└─────────────────┘
                                
    AndroidManifest_reversed.xml
     ❱ rules.mastg-android-minsdkversion
          [MASVS-PLATFORM-3] Ensure that the minSdkVersion is evaluated for notification exposure on older
          Android versions                                                                                
                                                                                                          
           11┆ android:minSdkVersion="29"
   
    ❯❱ rules.mastg-android-sensitive-data-in-notifications-manifest
          [MASVS-PLATFORM-3] Ensure that notifications do not contain sensitive information
                                                                                           
           14┆ <uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>
OWASP Mobile Application Security Testing Guide: output

                   
                   
┌─────────────────┐
│ 2 Code Findings │
└─────────────────┘
                                                     
    ComposableSingletons$MainActivityKt_reversed.java
    ❯❱ rules.mastg-android-input-field-usage
          [MASVS-PLATFORM] Detected TextFields and SecureTextField.
                                                                   
          142┆ TextFieldKt.TextField(TextFieldStateKt.m1440rememberTextFieldStateLepunE(null, 0L,        
               $composer, 0, 3), PaddingKt.m830padding3ABfNKs(Modifier.Companion,                        
               Dp.m8394constructorimpl(4)), false, false, null, null,                                    
               ComposableSingletons$MainActivityKt.INSTANCE.m10512getLambda2$app_debug(), null, null,    
               null, null, null, null, false, null, null, null, null, null, null, null, null, null, null,
               null, $composer, 1572912, 0, 0, 33554364);                                                
            ⋮┆----------------------------------------
          143┆ SecureTextFieldKt.m3241SecureTextFieldXvU6IwQ(TextFieldStateKt.m1440rememberTextFieldStateL
               epunE(null, 0L, $composer, 0, 3), PaddingKt.m830padding3ABfNKs(Modifier.Companion,         
               Dp.m8394constructorimpl(4)), false, null, null,                                            
               ComposableSingletons$MainActivityKt.INSTANCE.m10513getLambda3$app_debug(), null, null,     
               null, null, null, null, false, null,                                                       
               TextObfuscationMode.Companion.m1459getVisiblevTwcZD0(), (char) 0, null, null, null, null,  
               null, null, null, $composer, 196656, 0, 0, 8372188);
OWASP Mobile Application Security Testing Guide: MASTG DEMO 0079

---
platform: android
title: App Exposing Access and Verification Codes in Text Input Fields
id: MASTG-DEMO-0079
code: [kotlin]
test: MASTG-TEST-0316
---

## Sample

The following sample demonstrates a pair of username and password input fields in Compose.

{{ MainActivity.kt # MainActivityKt_reversed.java # ComposableSingletons$MainActivityKt_reversed.java }}

## Steps

Let's run our @MASTG-TOOL-0110 rule against the Kotlin code.

{{ ../../../../rules/mastg-android-input-field-usage.yml }}

{{ run.sh }}

## Observation

The rule detected one instance of `SecureTextField` and one of `TextField`.

{{ output.txt }}

## Evaluation

After reviewing the decompiled code at the location specified in the output (file and line number), we can conclude that the test fails because the `SecureTextField`, found in line 143, is used with `textObfuscationMode` set to `TextObfuscationMode.Visible` (in Java this appears as `SecureTextFieldKt.m3241SecureTextFieldXvU6IwQ(..., TextObfuscationMode.Companion.m1459getVisiblevTwcZD0(),...)`).

We also conclude that the `TextField` instance (line 142) is a false positive, as it's used for a username field and not a password field. We conclude this by trailing back its label parameter, which is set to "Username": its seventh (label) parameter calls `m10512getLambda2$app_debug()` function, which returns `f61lambda2` instance, which in turn creates the Text label composable `TextKt.m3574TextNvy7gAk("Username", ...`.
OWASP Mobile Application Security Testing Guide: output

                   
                   
┌─────────────────┐
│ 3 Code Findings │
└─────────────────┘
                                  
    MastgTestWebView_reversed.java
     ❱ rules.mastg-android-webview-settings
          [MASVS-PLATFORM-2] Detected WebView settings.
                                                       
           27┆ WebSettings $this$mastgTest_u24lambda_u240 = webView.getSettings();
            ⋮┆----------------------------------------
           28┆ $this$mastgTest_u24lambda_u240.setJavaScriptEnabled(true);
            ⋮┆----------------------------------------
           29┆ $this$mastgTest_u24lambda_u240.setAllowUniversalAccessFromFileURLs(true);
OWASP Mobile Application Security Testing Guide: MASTG DEMO 0029

---
platform: android
title: Uses of WebViews Allowing Content Access with semgrep
id: MASTG-DEMO-0029
code: [kotlin]
test: MASTG-TEST-0250
---

## Sample

This sample demonstrates how a WebView in an Android app, when configured to allow content access, can be exploited by an attacker to interact with exposed `content://` URIs. While `content://` URIs are simply interfaces to content providers, a misconfigured or overly permissive content provider may grant access to sensitive resources—such as internal app files. In this example, internal file access is used as a representative impact to illustrate the full attack chain, though actual impacts depend on the specific behavior of the content provider.

In this demo we focus on the static analysis of the code using semgrep and don't run the app nor the attacker server.

See @MASTG-DEMO-0030 for all the details about the sample and the attack.

{{ MastgTestWebView.kt # MastgTestWebView_reversed.java # AndroidManifest.xml # AndroidManifest_reversed.xml # filepaths.xml }}

## Steps

Run @MASTG-TOOL-0110 rules against the sample code.

{{ ../../../../rules/mastg-android-webview-allow-local-access.yml }}

{{ run.sh }}

## Observation

The output shows **4 results** related to WebView configuration calls. However, it is important to note that the method `setAllowContentAccess` is not explicitly called in the code.

{{ output.txt }}

## Evaluation

The test **fails** due to the following WebView settings being configured:

{{ evaluation.txt }}

The method `setAllowContentAccess` is not explicitly called in the code, which means it remains at its default value (`true`).
OWASP Mobile Application Security Testing Guide: output

                  
                  
┌────────────────┐
│ 1 Code Finding │
└────────────────┘
                           
    MastgTest_reversed.java
     ❱ rules.mastg-android-flag-secure-enable-flags
          [MASVS-PLATFORM] Make sure you use this flag for all screens with sensitive data
                                                                                          
           32┆ ((Activity) this.context).getWindow().addFlags(8192);
OWASP Mobile Application Security Testing Guide: MASTG DEMO 0061

---
platform: android
title: Uses of FLAG_SECURE with semgrep
id: MASTG-DEMO-0061
code: [kotlin]
test: MASTG-TEST-0291
---

## Sample

The sample uses the `addFlags` method to set the `FLAG_SECURE` window flag on an activity that displays sensitive data.

{{ MastgTest.kt # MastgTest_reversed.java }}

## Steps

Let's run our @MASTG-TOOL-0110 rule against the reversed java code.

{{ ../../../../rules/mastg-android-sensitive-data-in-screenshot.yml }}

{{ run.sh }}

## Observation

The rule has identified one location in the code file where the app has set the `FLAG_SECURE` window flag using the `addFlags` method.

{{ output.txt }}

## Evaluation

This test passes because the app used the `addFlags` method to set the `FLAG_SECURE` window flag on an activity that displays sensitive data.
OWASP Mobile Application Security Testing Guide: output

                  
                  
┌────────────────┐
│ 1 Code Finding │
└────────────────┘
                                               
    AndroidManifest_reversed.xml
    ❯❱ mastg-android-debuggable-flag
          [MASVS-RESILIENCE-4] debuggable detected as true.
                                                           
            5┆ <application android:allowBackup="true"                                           
               android:appComponentFactory="androidx.core.app.CoreComponentFactory"              
               android:dataExtractionRules="@xml/data_extraction_rules" android:debuggable="true"
               android:extractNativeLibs="false" android:fullBackupContent="@xml/backup_rules"   
               android:icon="@mipmap/ic_launcher" android:label="@string/app_name"               
               android:roundIcon="@mipmap/ic_launcher_round" android:supportsRtl="true"          
               android:theme="@style/Theme.MASTestApp">
OWASP Mobile Application Security Testing Guide: MASTG DEMO 0040

---
platform: android
title: Debuggable Flag Enabled in the AndroidManifest with semgrep
id: MASTG-DEMO-0040
code: [kotlin]
test: MASTG-TEST-0226
---

## Sample

The code snippet below shows a sample manifest file with the debuggable flag enabled.

{{ AndroidManifest.xml # AndroidManifest_reversed.xml }}

## Steps

Let's run our @MASTG-TOOL-0110 rule against the manifest file.

{{ ../../../../rules/mastg-android-debuggable-flag.yml }}

{{ run.sh }}

## Observation

The rule has identified the `android:debuggable` attribute in the AndroidManifest.

{{ output.txt }}

## Evaluation

The test case fails because the `android:debuggable` attribute is explicitly set to `true`.
OWASP Mobile Application Security Testing Guide: output

                  
                  
┌────────────────┐
│ 1 Code Finding │
└────────────────┘
                           
    MastgTest_reversed.java
    ❯❱ rules.mastg-android-sdk-version
          [MASVS-PLATFORM] Make sure to verify that your app runs on a device with an up-to-date OS version to
          make sure it satisfy your security requirements                                                     
                                                                                                              
           26┆ return Build.VERSION.SDK_INT;
OWASP Mobile Application Security Testing Guide: MASTG DEMO 0025

---
platform: android
title: Uses of Build.VERSION.SDK_INT with semgrep
id: MASTG-DEMO-0025
code: [kotlin]
test: MASTG-TEST-0245
---

## Sample

The following sample uses the `Build.VERSION.SDK_INT` API to check the operating system version.

{{ MastgTest.kt # MastgTest_reversed.java }}

## Steps

Let's run @MASTG-TOOL-0110 rules against the sample code.

{{ ../../../../rules/mastg-android-sdk-version.yml }}

{{ run.sh }}

## Observation

The output file shows usages of the API that verifies the operating system version.

{{ output.txt }}

## Evaluation

The test passes because the output shows references to SDK version check API.
OWASP Mobile Application Security Testing Guide: MASTG DEMO 0050

---
platform: android
title: Identifying Insecure Dependencies in Android Studio
id: MASTG-DEMO-0050
code: [java]
test: MASTG-TEST-0272
---

## Sample

{{ build.gradle.kts }}

## Steps

Execute `gradle` in Android Studio to trigger @MASTG-TOOL-0131.

{{ run.sh }}

## Observation

The scan identified 303 unique dependencies, four of which are vulnerable, as well as five vulnerabilities. More vulnerabilities may be found over time, so this number may increase. If you have used the `suppress.xml` file, there are 57 suppressed vulnerabilities.

{{ output.txt }}

## Evaluation

Due to the number of vulnerabilities, the `dependency-check` report can be lengthy and can contain false positives. Review each of the reported instances. The dependency `okhttp-4.9.1.jar` added in the `build.gradle.kts` has known vulnerabilities and should be updated to the latest version.
OWASP Mobile Application Security Testing Guide: output

                   
                   
┌─────────────────┐
│ 2 Code Findings │
└─────────────────┘
                           
    MastgTest_reversed.java
    ❯❱ rules.mastg-android-sql-injection-contentprovider
          [MASVS-CODE-4] Possible SQL Injection: unvalidated user input from `Uri.getPathSegments()`
          concatenated into `SQLiteQueryBuilder.appendWhere()`                                      
                                                                                                    
           95┆ qb.appendWhere("id=" + id);
            ⋮┆----------------------------------------
           99┆ qb.appendWhere(filter);
OWASP Mobile Application Security Testing Guide: output

                   
                   
┌─────────────────┐
│ 7 Code Findings │
└─────────────────┘
                           
    MastgTest_reversed.java
    ❯❱ mastg-android-local-storage-input-validation
          [MASVS-CODE-4] SharedPreferences value loaded. Review whether integrity and authenticity are
          validated before the value is trusted.                                                      
                                                                                                      
          140┆ String string = prefs().getString(key, defaultValue);
            ⋮┆----------------------------------------
          146┆ String value = prefs().getString(key, null);
            ⋮┆----------------------------------------
          147┆ if (value == null || (storedHmac = prefs().getString(key + "_hmac", null)) == null) {
   
     ❱ mastg-android-hmac-validation-present
          [MASVS-CODE-4] HMAC or MAC related integrity logic detected. Review whether it protects the reported
          local storage read and whether the secret is attacker accessible.                                   
                                                                                                              
          156┆ Mac mac = Mac.getInstance(HMAC_ALGORITHM);
            ⋮┆----------------------------------------
          159┆ SecretKeySpec key = new SecretKeySpec(bytes, HMAC_ALGORITHM);
            ⋮┆----------------------------------------
          160┆ mac.init(key);
            ⋮┆----------------------------------------
          163┆ byte[] bArrDoFinal = mac.doFinal(bytes2);