声明：该文章仅供安全学习和技术分享，请勿将该文章和文章中提到的技术用于违法活动上，切勿在非授权状态下对其他站点进行测试，如产生任何后果皆由读者本人承担！ 如有侵权，请联系后台进行删除。转载请注明出处，感谢！ 0x06 Android 安全策略上一篇文章中我们讲解了「Android 密码软键盘安全」，本文则对第五个 Android 渗透测试基础项中的大项「Android 安全策略」做了相关的讲解。 本章的内容主要分为十个部分：
安全策略都设置对于 APP 安全性和隐私性肯定是最好的，但也并不一定需要完全遵守，这需要根据 APP 的类型和官方对于各项综合评估后作出决定。那么接下来让我们一起看下相关的操作吧。 1. 密码复杂度1.1 问题说明检查移动客户端 APP 是否对用户输入的密码进行了复杂度检测，禁止用户设置弱口令。如果 APP 没有对输入的密码进行复杂度检测，有些用户图方便会设置弱口令，从而可能导致攻击者通过弱口令爆破用户名的方式进行密码猜解。 1.2 测试步骤检查 APP 是否允许设置弱口令密码，下图就是允许设置弱口令的例子。  而下图的情况就是有密码复杂度检测的。  1.3 修复建议建议在服务器端编写检查密码复杂度的安全策略，并将该策略运用到账号注册，密码修改等需要进行密码变更的场景，以防止攻击者通过弱口令爆破的方式进行暴力猜解。 2. 账户锁定策略2.1 问题说明检查移动客户端 APP 是否有限制登录尝试次数，如果没有设置则可能导致攻击者通过爆破、撞库等方式对系统用户密码进行破解。 2.2 测试步骤对 APP 不断进行错误密码尝试，查看 APP 是否有验证码出现或者是否有某种账户锁定策略。 如果输入错误密码后提示还有几次尝试机会，或者输入错误密码后弹出验证码等限制措施，这些都是满足账户锁定策略的。 2.3 修复建议建议在服务端编写账户锁定策略的逻辑，当一天内某个账户多次输入错误密码时根据 IP 进行账号锁定以防止攻击者通过暴力猜解密码。 3. 会话安全设置3.1 问题说明检查移动客户端 APP 在一段时间内无操作后，会话是否会超时并要求重新登录，超时时间设置是否合理。如果会话超时设置不合理则会增加用户账户的安全风险。 3.2 测试步骤一段时间内无操作检查 APP 是否要求用户重新登录，退出应用再打开检查 APP 是否要求用户登录。 3.3 修复建议建议在 APP 服务端编写会话安全设置的逻辑，当 10 分钟或 20 分钟无操作时自动退出登录状态或是关闭移动客户端。当然该策略也需要根据 APP 类型进行设置，对于金融类 APP 建议设置该策略，而对于聊天类 APP 则可以适当增加会话超时时间或者增加更为复杂的会话安全设置。 4. 界面切换保护4.1 问题说明检查移动客户端 APP 在切换到后台或其他应用时，是否能正确响应（如清除表单或退出会话等），防止用户敏感信息泄露。如果没有设置则可能造成用户敏感信息泄露。 4.2 测试步骤主要测试两个方面：
4.3 修复建议建议移动客户端 APP 添加响应的逻辑策略，在进行进程切换操作时提示用户确认是否为本人操作。 5. 登录界面设计5.1 问题说明检查登录时是否返回「用户名不存在」或「密码错误」等详细的登录错误提示信息，如果有则攻击者可通过该漏洞遍历已注册的 APP 用户。 5.2 测试步骤使用未注册的用户名进行登录，使用已注册的用户名及错误的密码进行登录，检查 APP 登录界面是否会根据不同情况返回不同的信息。 如果是下图返回的信息，则该 APP 登录界面设计存在问题。  5.3 修复建议建议无论是用户名或密码，只要有一个是错误的均提示「用户名或密码错误」，如果 APP 还想保证用户使用的友好性，可以在登录界面提示输入错误的次数，密码安全策略等信息，以防用户多次输入密码错误导致账号锁定。当然更建议在登录界面设置验证码等限制措施。 6. UI 敏感信息泄露6.1 问题说明检查移动客户端 APP 的各种功能否存在敏感信息泄露问题，如果有则可能造成用户的敏感信息泄露。 6.2 测试步骤查看 APP 的各界面是否对用户的真实姓名、身份证号、银行卡号、手机号等用户个人敏感信息进行适当遮掩处理。 下图中情况就是未对用户的敏感信息进行遮掩处理（图中马赛克是我后期自己加上的），而主流 APP 都是以部分敏感信息星号进行显示。  6.3 修复建议建议对用户个人的敏感信息，如手机号、身份证号等在服务端返回时进行遮掩处理。 7. 账号登录限制7.1 问题说明检查 APP 能否在两个设备上同时登录同一个账号，如果可以的话该问题会使得用户账户被盗后不能及时发现，增加账户的安全风险。 7.2 测试步骤尝试使用同一账号同时登录多个设备，如下图显示的就是不允许登录多个设备的情况。  7.3 修复建议建议在服务器端编写账号登录限制相应逻辑的代码，可以通过 Session 或数据库标志位的方式控制同一时间只有一个设备可以登录某一账号。当然该问题也需要视 APP 类型而定，如影视类 APP 大部分允许多设备登录，此时编写账号登录限制的策略可以改为非常用 IP 登录同一账户时进行下线操作。 8. 安全退出8.1 问题说明检查移动客户端 APP 在用户退出登录时是否会和服务器进行通信以保证本次退出的及时性。如果用户退出登录后服务器端还未退出，当会话被攻击者获取，就可能对账号进行持久性控制。 8.2 测试步骤在客户端退出账号之后，继续使用之前的会话 token 进行操作（可以直接重放直接抓取的数据包），检查用户登出后会话 token 是否在服务端被正确销毁。 下图就是退出后未销毁原 token，重放数据包仍然可以使用。  8.3 修复建议建议在服务器端编写响应移动客户端 APP 提出退出登录时的逻辑代码，以保证移动客户端 APP 在用户退出时同服务器端完成数据交互，完成退出（而不是通过心跳包判定退出），以防止攻击者进行重放攻击。 9. 验证码安全性9.1 问题说明检查移动客户端 APP 使用的验证码的安全性是否够强，如图片验证码在客户端验证，或图片验证码可被其他程序识别等，这些都会造成验证码失效。 9.2 测试步骤使用 pytesser 编写脚本尝试进行验证码识别，检查验证码是否可被程序轻易识别，还要检查验证码是否存在其他失效的方式。 下图数据包中验证码就是在客户端验证，可以抓包重放验证码，这样就可以对密码进行爆破从而绕过验证码的限制了。  9.3 修复建议建议验证码在服务端进行验证，并且符合图形验证码安全策略。 10. 密码修改验证10.1 问题说明检查移动客户端 APP 在密码修改时的安全性，如果 APP 密码修改验证不合理则可能导致用户密码被恶意修改。 10.2测试步骤尝试在修改密码时使用错误的旧密码，检查服务端是否验证旧密码的正确性，或者在修改密码时使用自己正确的密码看是否能抓包修改成他人的账号信息从而修改他人的密码。 10.3 修复建议建议在用户修改密码时验证旧密码或进行二次认证，以防止被其他人恶意修改密码。 关注我们，微信公众号：余生安全团队。
上一篇：【通知】微擎应用市场支持个人开发者入驻啦！ 下一篇：SSI注入漏洞总结 |
