“点按劫持”发生在 Android 应用中，是与点击劫持 Web 漏洞对等的攻击：恶意应用通过添加叠加层来遮盖界面的方式或通过其他方式，诱骗用户点击与安全相关的控件（确认按钮等）。在本页中，我们将对以下两种攻击变体加以区分：完全遮盖和部分遮盖。在完全遮盖攻击中，攻击者会为触摸区域添加叠加层；而在部分遮盖攻击中，触摸区域不会被遮盖。
[null,null,["最后更新时间 (UTC)：2023-12-08。"],[],[],null,["# Tapjacking\n\n\u003cbr /\u003e\n\n**OWASP category:** [MASVS-PLATFORM: Platform Interaction](https://mas.owasp.org/MASVS/09-MASVS-PLATFORM)\n\n\nOverview\n--------\n\nTapjacking is the Android-app equivalent of the [clickjacking web vulnerability](https://owasp.org/www-community/attacks/Clickjacking): A malicious app tricks the user into clicking a security-relevant control (confirmation button etc.) by obscuring the UI with an overlay or by other means. On this page, we differentiate two attack variants: Full and partial occlusion. In full occlusion, the attacker overlays the touch area, while in partial occlusion, the touch area remains unobscured.\n\nImpact\n------\n\nTapjacking attacks are used to trick users into performing certain actions. The impact depends on the action targeted by the attacker.\n\nRisk: Full occlusion\n--------------------\n\nIn full occlusion, the attacker overlays the touch area to hijack the touch event:\n\n### Mitigations\n\nFull occlusion is prevented by setting `View.setFilterTouchesWhenObscured(true)` in the code. This blocks touches passed by an overlay. If you prefer a declarative approach, you can also add `android:filterTouchesWhenObscured=\"true\"` in the layout file for the [`View`](/reference/android/view/View#security) object that you want to protect.\n| **Note:** Android S (12, SDK 31) and higher prevent full occlusion attacks by default, by blocking touch events from non-trusted overlays from another UID. \n|\n| However, there is a caveat: for System Alert Window (SAW) and window animations, only touches from layers with opacity \\\u003e= 0.8 are blocked. The reasoning behind this behavior is that SAW requires users to grant permission, and blocking all events for time-limited animations might hurt the user experience.\n\n*** ** * ** ***\n\nRisk: Partial occlusion\n-----------------------\n\nIn partial occlusion attacks, the touch area remains unobscured:\n\n### Mitigations\n\nPartial occlusion is mitigated by manually ignoring touch events that have `FLAG_WINDOW_IS_PARTIALLY_OBSCURED` flag. There are no default protections against this scenario.\n\n**Potential caveat:** This mitigation can interfere with benign apps. In some cases, rolling out this fix isn't possible, as it would negatively affect the user experience when the partial occlusion is caused by a benign application.\u000b\n\n*** ** * ** ***\n\nSpecific risks\n--------------\n\nThis section gathers risks that require non-standard mitigation strategies or\nwere mitigated at certain SDK level and are here for completeness.\n\n### Risk: android.Manifest.permission.SYSTEM_ALERT_WINDOW\n\nThe [`SYSTEM_ALERT_WINDOW`](/reference/android/Manifest.permission#SYSTEM_ALERT_WINDOW) permission allows an app to create a window shown on top of all apps.\n\n#### Mitigations\n\nNewer versions of Android have introduced several mitigations, including the following:\n\n- On Android 6 (API level 23) and higher, users have to explicitly grant the permission for the app to create an overlay window.\n- On Android 12 (API level 31) and higher, apps can pass `true` into [`Window.setHideOverlayWindows()`](/reference/android/view/Window#setHideOverlayWindows(boolean)).\n\n*** ** * ** ***\n\n### Risk: Custom toast\n\nAn attacker can use `Toast.setView()` to customize a [toast](/guide/topics/ui/notifiers/toasts) message's appearance. On Android 10 (API level 29) and lower, malicious apps could launch such toasts from the background.\n\n#### Mitigations\n\nIf an app targets Android 11 (API level 30) or higher, the system blocks background custom toasts. However, this mitigation can be evaded in some circumstances using *Toast burst*, where the attacker queues multiple toasts while in the foreground and they keep getting launched even after an app goes to the background.\n\nBackground toasts and toast burst attacks are fully mitigated as of Android 12 (API level 31).\n\n*** ** * ** ***\n\n### Risk: Activity sandwich\n\nIf a malicious app manages to convince a user to open it, it can still launch an activity from the victim app and subsequently overlay it with its own activity, forming an *activity sandwich* and creating a partial occlusion attack.\n\n#### Mitigations\n\nSee general mitigations for partial occlusion. For defense in-depth, make sure that you don't export activities that don't need to be exported to prevent an attacker from sandwiching them.\n\n*** ** * ** ***\n\nResources\n---------\n\n- [Play Store target API level policy changes](https://android-developers.googleblog.com/2019/02/expanding-target-api-level-requirements.html)\n\n- [UI redressing and accessibility service-based Android attacks](http://Cloak-and-dagger.org)\n\nRecommended for you\n-------------------\n\n- Note: link text is displayed when JavaScript is off\n- [android:exported](/topic/security/risks/android-exported)\n- [# Key management {:#key-management}](/topic/security/data)\n- [Run embedded DEX code directly from APK](/topic/security/dex)"]]
