该文章仅供安全学习，切勿用作非法用途，一切后果自负！ 转载请注明出处，感谢！ 0X04 IOS 安全策略检测上一篇文章中我们讲解了「IOS 移动端敏感信息安全」，本文则对第三个 IOS 渗透测试基础项中的大项「IOS 安全策略检测」做了相关的讲解。 本章的内容主要分为九个部分：
接下来让我们一起看下相关的操作吧。 1. 密码复杂度检测1.1 问题说明我们需要测试 IOS APP 是否检查了用户输入密码的强度和常见的弱口令，以免攻击者通过字典爆破攻击得到用户密码。此外，对于金融类客户端，还应该检查手机银行的登录密码是否与交易密码相同，是否与银行卡交易密码相同，以此来增加安全性。如果客户端没有对密码的复杂度进行要求的话，用户很可能因为方便而使用弱密码或者使用相同密码，从而会造成攻击者可尝试通过弱口令攻击用户账户。 1.2 测试步骤尝试将密码设置为弱口令，检测 APP 是否允许设置弱口令密码。如 APP 没有密码复杂度策略，可以将密码设置为 1 或者 123456 等这种弱口令。还有一种是 APP 虽然要求用户设置密码为 6-20 字符，但并未对密码复杂度进行检测，仍然可以设置为 123456 等弱密码。 而正常的情况下输入弱口令或者不符合复杂度策略的应该予以拒绝设置。  1.3 修复建议建议增加检测密码复杂度的安全策略，并将其运用到账号注册，密码修改等需要进行密码验证和变更的场景，以防止攻击者通过弱密码遍历账户或者对某一账户遍历密码的方式进行暴力猜解。 2. 账户锁定策略2.1 问题说明测试移动客户端时需要查看 APP 是否对登录尝试次数进行了限制，如果没有登录错误次数进行限制的话，那么攻击者就可通过爆破的方法攻击用户的账户。 2.2 测试步骤2.2.1 密码尝试测试的方法很简单，在登录界面对用户的密码进行错误尝试，看 APP 是否有错误次数的限制，如下图所示，该 APP 只有 3 次密码尝试的机会，那么就说明该 APP 是有账户锁定策略的。  并且在尝试 3 次错误密码后账户确实被锁定，如果 APP 只是有显示次数限制，但服务端并未做相应的限制，那么存在问题的。  2.2.2 特殊情况如果 APP 没有错误次数限制，但是存在不能被破解的验证码等限制措施，这样的话也是没有问题的。 但如果没有任何的其他限制措施且没有账户锁定策略，那么就可以尝试爆破，该 APP 在此项测试中就是存在问题的。
建议在服务端编写账户锁定策略的逻辑，当一段时间或一天内多次输入错误密码时根据 IP 或者账号进行账号锁定以防止攻击者通过暴力猜解密码。 3. 会话安全设置3.1 问题说明测试移动客户端在一定时间内无操作后，是否会使会话超时并要求重新登录，超时时间设置是否合理，如果设置有问题就可能存在会话被攻击者获取后造成长期劫持。 3.2 测试步骤一段时间（如 20 分钟）不进行操作，检测应用是否会要求用户重新登录。退出应用后重新打开，检测应用是否要求用户重新登录。当然这个需要根据 APP 的类型做相应的评判，比如是 QQ、微信这种聊天类型的对于会话安全设置就可以忽略或者时间设置长一点，而对于金融类的则为了安全起见还是建议设置会话超时时间。 3.3 修复建议建议在移动客户端编写会话安全设置的逻辑，当 20 分钟或 1 小时无操作时自动退出登录状态或是关闭移动客户端。 4. 登录界面设计4.1 问题说明在测试 APP 登录时，查看登录返回的登录错误提示信息是否有「用户名不存在」或「密码错误」等，因为这些错误信息有利于攻击者获取注册用户的信息，从而通过该问题使用用户名字典遍历 APP 已注册用户。 4.2 测试步骤在登录界面，分别输入已注册和未注册的账号或者手机号，查看页面返回的信息如何，如果对这 2 种情况做出了不同的响应，那么此时就存在问题，攻击者可以通过判断不同的显示从而获取到已注册的用户并进行下一步的动作。而如果账号不存在或者账号与密码不匹配都只显示登录失败一类的信息，则攻击者不能分辨账号是否已经注册，也就不能进一步攻击了。下图是存在问题的一种情况。  4.3 修复建议建议用户名或密码输入错误均提示「用户名或密码错误」，或者在登录界面增加图形验证码等限制措施防止攻击者进行遍历获取已注册用户的账号。 5. UI 信息泄露5.1 问题说明检查移动客户端的各种功能，看是否存在敏感信息泄露问题，如果 UI 信息未做遮掩处理，就可能造成用户敏感信息泄露。 5.2 测试步骤查看 APP 的各种功能，看是否有存在着电话、银行卡号、地址等敏感信息未做遮掩处理的，即直接将信息完整的显示在 APP 中，如下图情况。这样就会被他人看见手机号，并有可能用此手机号尝试登录或进行相关攻击，或者在知道敏感信息的情况下进行诈骗等。还有的情况是 APP 对于公示信息未做遮掩处理，将用户的手机号等敏感信息公布与众，这也是会造成 UI 信息泄露的。  此外，还有的 APP 在做遮掩处理时只做了前端的处理，后端并未做处理，此时抓包可以看到相关的敏感信息。这种利用难度相对来说很大，但是同样存在问题。  5.3 修复建议对 UI 中的敏感信息进行打码遮掩处理。当然了，这个也可以视情况和 APP 的类型进行对应处理，对于金融类 APP 最好还是做好相关的敏感信息遮掩处理。 6. 账号登录限制6.1 问题说明测试能否在两个设备上同时登录同一个账号，用户账号异常登录难以被及时发现。 6.2 测试步骤在两台不同的设备上登录同一个账号，看后登录的设备是否会将之前登录的设备挤下线，如下图所示，这种情况就是没有问题的。  当然了，也不是说所有的 APP 都不允许多设备同时登录，根据 APP 的类型以及开发者的需求可以不将此项作为问题项，亦或者采取其他的办法提示多设备的登录。 6.3 修复建议建议在服务器端编写账号登陆限制的逻辑代码，通过 Session 或数据库标志位的方式来控制在同一时间只能一个设备可以登录某一账号。当然对于那些有多端操作需求的可以视情况而定，增加一些其他的防护措施，如使用非常规地区 IP 登录时不允许多端同时在线，或者多端设备登录时在最早登录的设备上进行相关的警告信息提醒。 7. 安全退出7.1 问题说明验证 APP 在退出登录状态时是否会和服务器进行通信以保证退出的及时性，简单地说就是看 APP 在用户退出后，之前登录状态抓取到的数据包是否还能继续使用。 7.2 测试步骤首先在登录状态下抓取一些数据包，如查询个人信息，交易等设计个人内容的操作，之后退出登录，重放这些数据包，查看响应包是否和登录时返回的一样。如果提示已经退出则说明该 APP 是安全退出的，如果数据包仍然能使用则说明该 APP 的退出并不是安全退出，会话并没有被销毁。下图就是正常的安全退出。  7.3 修复建议建议在服务器编写在移动客户端提出退出登录状态时响应的逻辑代码，以保证移动客户端在用户退出登录状态时同服务器完成数据交互，真正完成退出（而不是通过心跳包来判定退出），以防止攻击者进行重放攻击。 8. 验证码安全性8.1 问题说明验证移动客户端使用的验证码的安全性，如果验证码存在问题，则可能造成基于验证码的访问控制失效。 8.2 测试步骤首先查看 APP 存在哪些验证码，如短信验证码、图形验证码等，然后分别对这些验证码的安全进行验证。 举个例子，短信验证码可能存在着爆破，复用，未强校验等问题，而图形验证码可能存在着爆破、复用、被轻易识别等问题。 如果 APP 中的验证码存在相关的安全问题，那么该项就是存在问题的。 8.3 修复建议建议 APP 从服务端处获取图形验证码相关信息，并且图形验证码符合图形验证码安全策略，如增加验证码的位数，复杂度，强校验性等。 9. 密码修改验证9.1 前言验证移动客户端进行密码修改时的安全性，如果存在问题则可能造成用户密码被非法修改。 9.2 测试步骤查看 APP 修改密码的地方是否存在问题，我遇到的情况有以下几种：
9.3 修复建议建议在修改密码时，移动客户端及服务器系统增添原密码输入验证身份的逻辑，以防 Cookie 登录修改密码的攻击。 上一篇：暴力引流方法,实战引流平台每天精准流量200+ 下一篇：微擎“领航计划”第一波|开发大赛+新应用大额优惠码开启! |
