1 业务安全概述

1.1 业务安全背景

近年来，随着信息化技术的迅速发展和全球一体化进程的不断加快，计算机和网络已经成为与所有人都息息相关的工具和媒介，个人的工作、生活、娱乐，企业的生产、管理，乃至国家的发展和改革都无处其外。
信息和互联网带来的不仅仅是便利和高效，大量隐私、敏感和高价值的信息数据资产成为恶意攻击者攻击和威胁的主要目标，从早期以极客为核心的黑客黄金时代，待现在利益链驱动的庞大黑色产业，网络安全已经成为任何个人、企业、组织和国家必须面临的重要问题。

1.2 业务安全现状

随着互联网+的发展，经济形态不断发生演变。众多传统行业逐步地融入互联网，并利用信息通信技术和互联网平台进行频繁的商务活动，这些平台（如银行、保险、证券、电商、P2P、020、游戏、社交、招聘、航空等）由于涉及大量的金钱、个人信息、交易等重要隐私数据，已经成为黑客攻击的首要目标，而由于开发人员安全意识淡薄（往往只注重功能的实现而忽略了在用户使用过程中个人行为对Web应用程序的业务逻辑功能的安全性影响）、开发代码频繁迭代导致这些平台业务逻辑层面的安全风险层出不穷。

这些漏洞主要是开发人员业务流程设计的缺陷，不仅存在于网络层、系统层、代码层等。比如登录验证的绕过、交易中的数据修改、接口的恶意调用等，都属于业务逻辑漏洞。

1.3 黑客攻击的目标

一方面随着社会和科技的发展，购物、社交、P2P、020、游戏、招聘等业务纷纷具备在线支付功能，同时还保存大量隐私、敏感数据。如电商支付系统保存着用户手机号、姓名、家庭住址、银行卡信息及支付密码等，这些信息都是黑客感兴趣的敏感信息。攻击者可以利用程序员的设计缺陷进行交易数据篡改、敏感信息盗取、资产窃取等操作。现在的黑客不在以炫耀技能为主要目的，而主要以经济利益为目的，攻击的目的逐渐转变为趋利化。

另一方面，如今的业务系统对于传统安全漏洞防护的技术和设计越来越成熟，基于传统漏洞入侵也变得越来越困难，增加了黑客攻击的成本。而业务逻辑漏洞可以逃逸大部分的安全防护，迄今为止没有很好的解决办法。这也是为什么黑客偏好使用业务逻辑漏洞攻击的一个原因。另外，代码审计也很难防御业务逻辑漏洞。例如星巴克由于优惠券引发的经济损失。

2 业务安全测试流程

2.1 测试准备

准备阶段内容：主要是对业务系统的前期熟悉工作。
针对白盒性质的测试，可以结合相关开发文档去熟悉相关系统业务。
针对黑盒测试，可以通过实际操作还原业务流程的方法理解业务。

2.2 业务调研

调研阶段内容：主要针对业务系统相关负责人进行访谈调研，了解业务系统的整体情况，包括部署情况、功能模块、业务流程、数据流、业务逻辑以及现有的安全措施等内容。

根据以往测试实施经验，在业务调研前可先设计访谈问卷，访谈后可能会随着对客户业务系统具体情况和随着了解的深入不断调整、更新问卷。
黑盒测试可忽略此步骤。

2.3 业务建模

业务场景建模：针对不同行业、不同平台的业务系统，如电商（登录、注册、交易、积分等）、银行（登录、注册、交易、转账等）、金融、证券、保险、游戏、社交、招聘等业务系统，识别出其中的高风险业务场景进行建模。即针对不同的业务系统，测试的点是不一样的。

建模完成后，需要对重要业务场景的各个业务模块逐一进行业务流程梳理。

2.4 业务流程梳理

分析维度：从前台、后台、业务和支撑系统等4个维度进行分析；

目的：识别各业务模块的业务逻辑、业务数据流和功能字段等。

原则：

• 区分业务的主要流程和分支流程，业务流程梳理工作主要围绕主流程进行分析，而主流程一定是核心业务流程，因此业务流程重点梳理的对象应该放在核心主流程上，务必梳理出业务的关键环节。
• 概括归纳业务分支流程，业务分支流程往往存在通用点，可将具有业务相似性的分支流程归纳成某一类型的业务流程，无需单独对其进行测试。
• 识别业务流程数据信息流，特别是业务数据流在交互方双方之间传输的先后顺序、路径等。先后顺序很重要，测试时经常需要测试业务流程是否会乱序。
• 识别业务流程数据信息流功能字段，识别数据流中包含的重要程度不等的信息，理解这些字段的含义有助于下阶段风险点分析。

例子：用户登录流程。

图中涉及到的用户字段为用户名、密码、图形验证码短信验证码等。

2.5 业务风险点识别

在完成前期不同维度的业务流程梳理工作后，针对前台业务应着重关注用户操作每一步可能的逻辑风险；针对后台业务应着重关注数据安全、数据流转以及处理的日志和审计。

业务风险点识别应主要关注以下安全风险内容
（1）业务环节存在的安全风险，指的是业务使用者可见的业务存在的安全风险。如：在注册、登录的密码找回等身份认证环节，需要考虑的问题：

• 是否存在完善的验证码机制、数据一致性校验机制、Session和Cookie校验机制等。
• 是否能规避绕过、暴力破解和SQL注入等漏洞。

（2）支持系统存在的安全风险。如：

• 用户访问控制机制是否完善，是否存在水平越权或垂直越权漏洞。
• 系统内加密存储机制是否完善。
• 业务数据是否明文传输。
• 业务使用的业务接口是否可以未授权访问、调用；是否可以调用重放、遍历。
• 接口调用参数是否可以篡改。

（3）业务环节间存在的安全风险，如：

• 系统业务流程是否存在乱序问题，导致某个业务环节可绕过、回退、或某个业务请求可以无限重放；
• 业务环节间传输的数据是否有一致性校验机制；
• 业务环节间传输的数据是否可被篡改的风险。

（4）支持系统间存在的安全风险，如：

• 系统间传输的数据是否加密。
• 系统间传输的参数是否可篡改。
• 系统间输入参数的过滤机制是否完善。
• 是否可能导致SQL注入、XSS跨站脚本、代码注入命令注入、代码执行等漏洞。

（5）业务环节与支持系统间存在的安全风险，如：

• 数据传输是否加密。
• 加密方式是否完善，是否采用前端加密、简单MD5编码等不安全的加密方式。
• 系统处理多线程并发请求的机制是否完善。
• 服务端逻辑与数据库读写是否存在时序问题，导致竞争条件漏洞（如QQ刷钻漏洞）。
• 系统间输入参数的过滤机制是否完善。

例子：

tips:
关于身份验证与访问控制：

• 失效的身份验证是指验证身份时出错（可能是被攻击者如何绕过或欺骗）；
• 失效的访问控制是指用户没有欺骗行为而系统在判断其是否能访问目标资源时出错。

2.6 开展测试

对前期业务流程梳理和识别出的风险点，进行有针对性的测试。

2.7 撰写报告

针对业务安全测试过程中发现的风险结果进行评价和建议，综合评价利用场景的风险程度造成影响的严重程度，最终完成测试报告的编写。

3 总结

（1）了解业务安全的背景及重要性。
（2）掌握业务安全测试流程。
（3）掌握理解业务建模和流程梳理的处理思路。
（4）掌握风险点识别的内容。

参考文章

[1]《浅谈互联网业务安全》