Tapjacking 攻击防护：Android 触摸劫持的安全防御实战指南

你以为点在"确认"，其实是在转钱

最近Codename One开源了一套Tapjacking防护方案，专门解决一个让人后背发凉的问题：恶意App能在屏幕上层画透明遮罩，诱导用户点击本不该点的按钮，而用户毫无察觉。

做金融类、支付类App的朋友，这块儿安全如果不做，一旦出事就是赔到底裤都不剩。

什么是Tapjacking？

Tapjacking（点击劫持）是一种老套路的新玩法。攻击者在你的App上方绘制一个透明或半透明的Overlay，用户看到的界面是安全的，但实际点击的坐标已经被偏移到了恶意区域。

典型的攻击场景：

• 用户以为在浏览商品详情，实际点击的是"转账确认"按钮
• 用户以为在关闭弹窗，实际点击的是"授权支付"
• 用户以为在点赞，实际点击的是"领取红包并分享"（然后疯狂传播）

以前这种攻击多见于原生WebView场景，现在Android 13+权限收紧后，SYSTEM_ALERT_WINDOW的使用虽然受限，但恶意App依然可以通过无障碍服务、悬浮窗等路径实现类似效果。

Codename One的解决方案

Codename One近期在输入路径层面做了加固，核心思路是：关键操作前校验屏幕顶层是否有异常Overlay。

具体实现原理：

1. 权限校验：检测当前App是否拥有`SYSTEM_ALERT_WINDOW`权限，且该权限非用户主动授权
2. 触摸事件拦截：捕获全局触摸事件，分析点击坐标与实际UI元素的匹配度
3. 分层校验：在转账、登录、授权等敏感操作触发前，调用系统API检查屏幕顶层窗口列表，排除异常Overlay干扰

这套方案的价值在于：把原本需要安全团队手动实现的能力，内置到框架中，降低独立开发者踩坑的成本。

独立开发者怎么做？

如果你是Codename One用户：直接升级至最新版本即可获取防护能力，无需额外开发。

如果你自行开发Android原生App：可参考以下思路：

1. 检测Overlay风险

   // 检查是否有异常悬浮窗
   WindowManager wm = (WindowManager) getSystemService(WINDOW_SERVICE);
   List<WindowManager.LayoutParams> overlayParams = getOverlayParams();
   for (LayoutParams params : overlayParams) {
       if (params.type >= FIRST_SYSTEM_WINDOW && params.type <= LAST_SYSTEM_WINDOW) {
           // 警惕：非应用自身的Overlay可能干扰触摸事件
           Log.w("Security", "Potential tapjacking overlay detected");
       }
   }

1. 关键操作前二次确认

对于转账、支付、授权等敏感操作，强制使用系统级对话框（AlertDialog与android:alertDialogTheme结合），避免被自定义View劫持。

1. 监听权限变化

注册Settings.ACTION_MANAGE_OVERLAY_PERMISSION的回调，当用户授予或撤销SYSTEM_ALERT_WINDOW权限时，重新评估安全状态。

为什么现在还要关注这个问题？

三个原因：

1. Android生态碎片化：厂商ROM对权限管理的差异，导致安全策略执行不一致
2. 隐私政策收紧：用户对App权限敏感度提升，但技术对抗也在升级
3. 独立开发者安全能力不足：专职安全团队成本高昂，框架内置防护成为刚需

Codename One这类多平台框架把Tapjacking防护内置，本质上是给没有安全预算的独立开发者留了条活路——别以为不用管，漏洞可能就在你让用户点"确认"的那一秒。

延伸：安全即护城河

对于移动端开发者来说，安全能力正在从"加分项"变成"必选项"。

建议行动清单：

• [ ] 检查当前App是否涉及金融/支付/授权类操作
• [ ] 升级Codename One至最新版本（如适用）
• [ ] 自行开发的原生App添加Overlay检测和触摸校验
• [ ] 敏感操作前增加二次确认环节
• [ ] 考虑接入第三方安全审计服务（如Fixate Mobile Security、Cryptography API等）

安全不是功能，是底线。一旦被Tapjacking盯上，用户体验崩塌只是时间问题。