在上次《手机银行业务安全评估方法》介绍手机银行业务安全评估方法后，这次来说说评估中经常发现的问题及其防范措施，以便客户加强自己的手机银行业务安全。
小编注：同上次文章一样，《手机银行业务安全评估 常见问题及防范措施》将刊登在绿盟科技技术刊物上
验证强度不足
客户身份验证是银行业务的关键工作之一，是保证业务活动安全性的必要手段。传统的银行业务在柜台面对面地进行，客户本人与银行柜面业务人员交流，提出业务申请，柜面人员通过身份证件、凭证等凭据验证客户的身份并确认其具有相关权限，然后进行业务处理。手机银行业务活动同样是由客户端（手机）和服务端（银行系统）两方通过交互来完成的，当在远程的一部手机提出将最近的交易记录传送过去时，银行系统是否应进行查询这些记录并传送给对方的手机？这种场景下，手机客户端的身份验证就成为关键性的问题。
而在业务评估中，我们经常发现身份验证强度不足的问题，给手机银行带来很大风险。常见的手机银行验证手段有：
- 用户名+口令，安全可信度低，通常用作手册银行登录。
- 动态口令，安全可信度较高，通常用作支付或转账操作的确认。
- 音频Key，存储客户的电子证书，安全可信度相对最高，通常用作转账等高风险交易的确认。
下面介绍一个在评估中发现的在”收款人管理”功能中存在的比较典型验证不足的问题。
上表是本例中”收款人管理”的业务流程分解与风险分析，在第4步中，发现了新增和删除收款人时没有进行验证的问题，攻击者可能通过撞库获得手机银行的登录权限，在查看用户账户情况后，可能会用伪装的其他账户信息替换掉真实收款人信息，导致用户被误导，自己将资金转入攻击者的账户。
业务操作中可能面临什么级别的风险，其验证强度就应达到什么级别的要求。本例中的”收款人管理”功能中，对收款人进行新增、修改、删除等操作时，就应当进行身份验证，而且应采取这个账户所具有的最高级别身份验证手段，如果有动态口令验证机制就采用动态口令，如果有音频Key就采用音频Key，二者方式都没有的，至少采取用户名+口令的方式验证。
常见的验证不足的问题可以分类为：
- 没有在每一个需要验证的业务操作中进行验证。例如：用户登录后，对其后续操作不再进行必要的权限核实。这可能导致攻击者使用正常用户登录后，利用命令构造工具，非法查看其他账户信息，甚至非法对其他账户资金进行操作。2011年6月，花旗银行的21万信用卡用户信息失窃，就是因为这个问题。
- 虽然进行了验证，但在高风险的业务操作中采用强度低的验证方法，例如：经用户名+口令验证后即可进行大额资金转账。这类问题近年来已经较少。
是否应在某一个业务操作中进行权限验证？所采用的验证强度是否足够？应在每一个业务环节考虑验证手段的合理性，验证措施的强弱需要与相应操作面临的风险相匹配。
业务中提供了不必要的功能或信息
从安全角度看，业务设计中提供的功能和信息越多，出问题的概率就越大，敏感信息就越有可能泄露。在手机银行业务评估中，我们发现存在不必要的功能或提供了不必要信息的情况，给手机银行安全带来了隐患。
业务系统包含不必要的功能
业务上线时包含了不必要的功能，我们在手机银行评估中发现很多这类情况，包括：仅用于测试的功能、此版本中还不需要上线的功能等；上线了不必要的文件，如源代码管理文件、多余的可执行代码文件甚至源代码文件等。
下面是一个实际案例：2014年3月，某旅游服务网站用于处理用户支付的服务器开启了处理用户支付服务的调试功能，把用户向网站提交的信用卡的持卡人卡号、CVV码等敏感信息直接打印到日志并保存在本地服务器。同时由于服务器自身未做必要的安全检查与加固，存在目录遍历漏洞，导致这些信息可被攻击者读取。其中泄露的信息包括：持卡人姓名、持卡人身份证、所持银行卡卡号、所持银行卡CVV码、所持银行卡6位Bin（验证支付信息的6位密码）等。
本例事件的根源就是因为上线时检查不严格，业务中增加了多余的功能。
提供不必要的提示信息
由于业务设计，手机银行服务端有时会输出不必要的提示信息，多数原因是为了加强客户体验。
如某银行信用卡的手机银行功能存在提供信息过多的问题，通过这些信息可枚举信用卡CVV码。该手机银行系统的信用卡注册功能中，要求用户提交包括CVV码在内的相关信息进行验证，如果CVV码错误，则会提示”CVV码输入错误，请重新输入”。由于CVV码只有三位，因此，攻击者可以利用这一提供信息进行枚举猜测，从而获得该信用卡的三位CVV数字，并在猜测出正确的CVV码后，进一步继续枚举而获得信用卡有效期。攻击者继续采用此方式，对其他用户的信用卡重复上述操作，可能使大量用户的信用卡信息泄露。
在业务设计中，对CVV码输入错误的情况进行准确提示，能够使客户更明确地获知问题，提升了客户体验，但提升体验应在安全的前提下进行。当不能保证安全时，只能牺牲一些客户体验度来获得安全。在本例中，可以模糊提示”您的信息输入有误，请检查后重新输入”，就能够有效地避免这个问题。
对客户端输出不必要的信息内容
银行有时为了做业务方便，向客户提供的信息中包含不必要的内容。如在交易记录查询结果中显示全部的银行卡号信息，包括银行卡主的身份证号码等，由于”撞库攻击”可能性的存在，应当对银行卡号进行部分屏蔽，不返回身份证号码，或在返回身份证号码的时候也进行部署屏蔽。 下面是一个业务中提供不必要内容的实例：2013年2月此问题被发现。通过某保险公司的合作方”XX风险管理网”，可直接在线查询到近80万条保险公司客户的信息。在网站的搜索中输入姓氏等信息，会显示大量姓氏相同的用户信息，包括投保险种、手机号、身份证号、密码等敏感内容。保险公司声称是由于”XX风险管理网”升级操作失误，导致信息泄露，该网紧急关闭该查询模块。此次事件造成投保人信息数据库中共80万条用户信息被泄露。根据业务需要，实际上保险公司的合作方不需要这么多信息内容，尤其是密码没有必要向合作方提供，保险公司对这些信息内容管理不严格，也是造成信息泄露的主要原因之一。
防范提供不必要的功能或信息的问题，在业务中传递的信息和功能应遵循”最小必需”原则，即在保证满足业务功能的前提下，只向用户或其他机构提供必需的信息和功能，使业务与安全达到平衡，在业务设计和系统开发各环节中进行控制：
- 需求分析阶段对涉及信息查询、下载、导出、日志记录、打印、第三方接口等功能需求，应组织业务需求人员、项目组安全员等评审功能必要性，不必要的功能不纳入正式系统需求。
- 设计阶段应根据信息系统系统需求，仅对必需的功能进行设计，对于信息系统中的敏感信息应识别其流经的各环节，对于其查询、显示、存储、传输等都应设计相应的脱敏机制。
- 编码阶段：严格遵守编码安全规范，屏蔽不必要的提示信息和出错信息，对涉及身份鉴别等敏感时，提示信息应避免明确错误位置；调试信息或日志中仅记录能定位错误最小必需的信息。
- 投产上线阶段：应对发布的文件与功能进行审核，确保只发布适当的文件与功能。投产版本中必须将代码中的调试信息、单元测试代码、不使用的功能代码、源代码管理文件等进行清理。对Web默认提示信息也应进行清理，避免暴露Web服务器、中间件和数据库等方面的信息。
（待续）