Port MASTG-TEST-0035: Testing for Android overlay attack protections

[Copilot]

Port MASTG-TEST-0x35: Testing for Android overlay attack protections

Ports v1 test for overlay/tapjacking attacks to v2 format. The v1 test included both static and dynamic analysis; v2 focuses exclusively on static detection of touch filtering mechanisms.

Checklist

• Create v2 test MASTG-TEST-0x35
• Create demo MASTG-DEMO-0x83 with working code
• Create semgrep rule for overlay protection detection
• Create best practice MASTG-BEST-0029
• Update knowledge article MASTG-KNOW-0022
• Deprecate v1 test
• Add setHideOverlayWindows API to knowledge and best practices
• Fix demo MastgTest.kt to follow proper structure with class and mastgTest() method
• Reorganize recommendations by robustness (HIDE_OVERLAY_WINDOWS first)
• Add HIDE_OVERLAY_WINDOWS permission documentation
• Separate prevention mechanisms from detection mechanisms
• Consolidate related mechanisms (XML attributes with programmatic methods)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>MASTG v1->v2 MASTG-TEST-0035: Testing for Overlay Attacks (android)</issue_title>
<issue_description>
Create a new MASTG v2 test covering for:

• Title: Testing for Overlay Attacks
• ID: MASTG-TEST-0035
• Link: https://mas.owasp.org/MASTG/tests/android/MASVS-PLATFORM/MASTG-TEST-0035/
• Platform: android
• MASVS v1: ['MSTG-PLATFORM-9']
• MASVS v2: ['MASVS-PLATFORM-3']

Focus on static analysis and ignore the dynamic analysis section in the old MASTG-TEST-0035.

Create also:

• a demo in demos/
• a best practice in best-practices/

Follow the guidelines in .github/instructions/porting-mastg-v1-tests-to-v2.instructions.md as well as other .github/instructions/

References:

• https://developer.android.com/privacy-and-security/risks/tapjacking
• https://mas.owasp.org/MASTG/knowledge/android/MASVS-PLATFORM/MASTG-KNOW-0022/ (link this to the test as knowledge: [MASTG-KNOW-0022] and update the knowledge if needed)

</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes MASTG v1->v2 MASTG-TEST-0035: Testing for Overlay Attacks (android) #2983

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[cpholguera]

Update ID to fake ID here and in the file name and demo

Suggested change

	id: MASTG-TEST-0035
	id: MASTG-TEST-0x35

[cpholguera]

Demo is missing:

class MastgTest (private val context: Context){

    fun shouldRunInMainThread(): Boolean = true

    fun mastgTest(): String {

[cpholguera]

@copilot please do the following:

1. mention setHideOverlayWindows to best-practices/MASTG-BEST-0029.md and knowledge/android/MASVS-PLATFORM/MASTG-KNOW-0022.md

2. The Demo's MastgTest.kt is missing this (it must be like this, as any other demo, see .github/instructions/mastg-demo.instructions.md and demos/):

class MastgTest (private val context: Context){

    fun shouldRunInMainThread(): Boolean = true

    fun mastgTest(): String {

[Copilot]

@copilot please do the following:

1. mention setHideOverlayWindows to best-practices/MASTG-BEST-0029....

Done in commit dbe8198:

1. Added setHideOverlayWindows to both MASTG-KNOW-0022 and MASTG-BEST-0029 with proper API reference links
2. Fixed MastgTest.kt to follow the proper demo structure with class MastgTest(private val context: Context) and mastgTest(): String method. Updated both the Kotlin and decompiled Java versions.

[serek8]

@copilot In the 1st and 2nd bullet points above you described one mechanism but applied in two different ways. The 3rd bullet points(this one) also has another way to apply the same technique by setting HIDE_OVERLAY_WINDOWS. I would even say this might be the most reliable way to stop overlays on supported API versions. I would add it too to the list.

Also, how about we sort this list by the most robust solutions. I believe HIDE_OVERLAY_WINDOWS / setHideOverlayWindows would be first one.

Then I would mention android:filterTouchesWhenObscured / setFilterTouchesWhenObscured.

Checking FLAG_WINDOW_IS_OBSCURED and FLAG_WINDOW_IS_PARTIALLY_OBSCURED might belong to a different category. They don't prevent touching UI if there is an overlay on the screen. Instead, they detect these overlays and allow to response accordingly. This might be worth mentioning.

[cpholguera]

@copilot In the 1st and 2nd bullet points above you described one mechanism but applied in two different ways. The 3rd bullet points(this one) also has another way to apply the same technique by setting HIDE_OVERLAY_WINDOWS. I would even say this might be the most reliable way to stop overlays on supported API versions. I would add it too to the list.

Also, how about we sort this list by the most robust solutions. I believe HIDE_OVERLAY_WINDOWS / setHideOverlayWindows would be first one.

Then I would mention android:filterTouchesWhenObscured / setFilterTouchesWhenObscured.

Checking FLAG_WINDOW_IS_OBSCURED and FLAG_WINDOW_IS_PARTIALLY_OBSCURED might belong to a different category. They don't prevent touching UI if there is an overlay on the screen. Instead, they detect these overlays and allow to response accordingly. This might be worth mentioning.

Also, let's add Let's also add HIDE_OVERLAY_WINDOWS in knowledge/android/MASVS-PLATFORM/MASTG-KNOW-0022.md

[cpholguera]

@copilot

in best-practices/MASTG-BEST-0029.md

In the 1st and 2nd bullet points of the "## Recommendation", you described one mechanism but applied in two different ways. The 3rd bullet point also has another way to apply the same technique by setting HIDE_OVERLAY_WINDOWS. I would even say this might be the most reliable way to stop overlays on supported API versions. Please add it too to the list but as one bullet only (the API and the Manifest version of the same thing; and do this with the other bullets where applicable).

Also, sort this list by the most robust solutions. e.g. make HIDE_OVERLAY_WINDOWS / setHideOverlayWindows be first one and then android:filterTouchesWhenObscured / setFilterTouchesWhenObscured.

Checking FLAG_WINDOW_IS_OBSCURED and FLAG_WINDOW_IS_PARTIALLY_OBSCURED belong to a different category so put these apart from the previous list. They don't prevent touching UI if there is an overlay on the screen. Instead, they detect these overlays and allow to response accordingly. This might be worth mentioning.

in knowledge/android/MASVS-PLATFORM/MASTG-KNOW-0022.md

Add HIDE_OVERLAY_WINDOWS where it belongs. Check and add anything else that's missing to keep it in sync with MASTG-BEST-0029. But remember to keep knowledge as theory (what's available for devs) vs MASTG-BEST-0029 which should focus on the best practice (how to do/use it properly/securely).

[Copilot]

@copilot

in best-practices/MASTG-BEST-0029.md

...

Done in commit 3e67a11:

In MASTG-BEST-0029.md:

• Added HIDE_OVERLAY_WINDOWS permission alongside setHideOverlayWindows as a single bullet point
• Reordered mechanisms with most robust first (HIDE_OVERLAY_WINDOWS, then filterTouchesWhenObscured, then onFilterTouchEventForSecurity)
• Separated into "Prevention Mechanisms" (which prevent/block overlays) and "Detection Mechanisms" (FLAG checks that only detect overlays)
• Consolidated XML attributes with their programmatic method equivalents
• Added clarification that detection mechanisms require custom implementation

In MASTG-KNOW-0022.md:

• Added HIDE_OVERLAY_WINDOWS permission with description
• Organized mechanisms into Prevention and Detection categories matching best practices
• Maintained theoretical focus (what's available) vs best practices (how to use securely)