近年来，信息安全体系建设趋于完善，以注入攻击、跨站攻击等为代表的传统 Web 应用层攻击很大程度上得到了缓解。但是，Web 应用的业务功能日益丰富、在线交易活动愈加频繁，新的安全问题也随之呈现：基于 Web 应用所承载的交易特性，某些利用其业务逻辑设计缺陷来构造的针对具体业务的攻击逐渐成为主流，我们称之为业务层攻击。
业务层攻击在技术上具有以下几方面特点：
一、攻击数据缺乏明显特征
与传统的应用层攻击不同，业务层攻击的报文与正常业务的报文并无明显差别。因此，基于特征检测的各种扫描工具和防护设备往往无法起到作用。
譬如“占座刷单”这一攻击—— 在商品购买过程中，攻击者利用自动化测试工具在未支付前占用商品库存，引发商品库存被快速清空，导致商品无法正常销售。诸如机票占座、电影票占座、电商购物中商品库存清空等，都是此类攻击的常见应用场景。以传统的应用层安全来讲，这种自动化的模拟完全遵循正常的业务逻辑，提交的业务数据也都是合规数据，因此并未呈现出任何安全问题。
二、与业务逻辑高度相关
业务层攻击常常针对目标应用量身定制，攻击者在发起攻击前，都会对应用的业务进行深入的测试和分析，从中挖掘出有利用价值的漏洞。
比如 Web 应用中的一项常见功能，重置密码。 每个用户都预留了用于重置密码的重要联系方式，如手机号码或邮箱。攻击者注册一个用户，并正常使用重置密码功能，在自己的邮箱获取重置密码的凭据后进行密码重置，在这一过程中，攻击者通过截包观察分析请求数据，篡改请求数据中的电子邮箱地址为其他账号的邮箱地址，重放提交，就可以使用自己邮箱中已获取的凭据成功重置其他账号的密码。
三、难以在开发环节避免
应用开发以满足用户需求为优先考量，设计者通常从功能实现而非攻击者的视角去设计系统，同时也普遍缺乏应用安全的知识储备和实践能力。
举例来说，在设计 Web 应用的用户登录功能时，从应用开发角度来看，在账号或密码输入错误时，是否要求用户在刷新验证码的同时重新输入帐号信息，是不影响登录功能的正常使用的。对攻击者来讲，这就是一个可利用的漏洞。只要不刷新 session，攻击者就可以一直不换验证码去尝试密码，进而导致暴力破解等问题；也可以去尝试用户名，从而爆破用户名列表，再利用社会工程库的数据进行撞库。
四、修补漏洞代价大
业务安全漏洞的修复，并非通过加入一两段验证代码就能达到目的，往往需要修改业务处理流程，甚至很有可能在修补一个已知漏洞时，带来更多新的漏洞。
例如，针对下单后篡改商品价格、优惠券重复利用、伪造成功结算请求等交易欺诈漏洞，常常需要开发者做如下修复：
- 生成数据签名，对用户金额和订单签名；
- 避免将敏感参数明文存放在 URL 中；
- 在服务端校验/过滤客户端提交的参数；
- 在服务端计算金额时，一定要判断是否为正数；
- 支付过程中增加一个服务器生成的key，确认用户校验参数没有被篡改；
- 用 URL 传递相关参数，后端进行签名验证；
- 对订单金额和充值接口返回的数据进行校验；
- 提交订单时，后台判断单价是否与数据库中相符，如不符则返回错误；
- 支付时应从服务器拉取数据，而不是直接读取客户端的值。
可以看到，以上漏洞修复工作中，大部分都需要对业务处理流程进行调整，绝非在局部功能上小修小补所能解决。
五、业务层攻击最能体现WEB攻击特性
业务层攻击是最能体现 Web 攻击特性的攻击方式，而 Web 攻击最大的特点就是高度的对抗性，成功的 Web 攻击永远是见招拆招。
例如，自动注册是攻击者利用自动化测试工具实现批量注册用户的一种攻击方法。 许多 Web 应用也意识到了这一安全风险，故而在其注册功能上加入各种人机验证要求，如短信验证、邮件验证、各类验证码等，此外还可能对同 IP 注册进行限制。而攻击者也通过各种奇技淫巧来突破这些措施，如利用在线短信平台来接收短信验证，自动切换代理服务器来突破同 IP 限制，或利用打码平台来识别验证码等等。
那么，防御业务层攻击有没有某种一劳永逸的通用解决方案呢？
近年来出现了一些针对业务层攻击的解决方案，例如通过使用前端 JS 技术来实现防调试、真实浏览器验证、防（自动化访问）模拟（真实访问者操作）、隐藏参数、表单提交代替链接传参等功能来增加业务层攻击的实施难度。
图1尽管手段新奇，让人有脑洞大开的感觉。但仔细分析这一类解决方案后，不难发现，它们遵循的依然是传统的网络安全防护思路：在攻击者的攻击路径上层层设卡，使攻击者实施攻击的难度和代价增大，从而缓解或封堵威胁。采用这一类解决方案，尽管攻击者更难挖掘出业务层漏洞，也更难发起业务层攻击，但漏洞依然存在于 Web 应用上。
天存信息针对业务层攻击提出一种新的解决思路，即：用户能够在不接触和修改 Web 应用程序源代码的情况下，通过快速编写虚拟补丁代码并实时上线生效的方式，即时建立一个安全策略实施层，修复已知业务漏洞。
实现这一思路需要解决几个问题。
首先，由于 HTTP 协议本身是无状态的，无论一系列请求是否来自同一个使用者，对服务器来说，都被视为一次次孤立的访问。因此，要想从业务层面而非协议层面来分析和控制访问，就需要还原出相互独立的请求背后的使用者。
我们通过在iFlow2业务安全动态加固平台上引入主体的概念来解决这一问题，客户端 IP、设备特征、会话标识乃至它们的组合均可用来定义一个主体。通过对主体的跟踪，我们就可以从一众原本孤立的请求中，还原出背后的使用者。基于主体概念，业务安全动态加固平台可以统计访问行为，做出持续的裁决。对于更复杂的跨 HTTP 事务判定逻辑，我们可以为每个主体创建称之为「容器」的变量空间，允许规则针对主体进行记录和计算信息，跟踪并干预业务逻辑。从而实现基于业务逻辑而非攻防对抗层面的真正的业务漏洞的修复。
图2其次，尽管 Web 应用的业务交互是通过 HTTP 协议进行的，但是业务信息是隐没在 HTTP 报文中的。例如，基础的用户身份鉴别和访问控制功能在 HTTP 报文中就没有直接的体现，更何况复杂的交易信息。如果要对这些信息进行甄别和判定，就需要从 HTTP 报文中将其提取出来，并按照业务逻辑进行梳理。
我们设计了一种专门用于实现 Web 应用安全加固的类编程语言。它介于配置和通用语言之间，具备编程的基本要素和针对 HTTP 协议的特有扩展，能为业务系统编写涉及复杂动态判断的逻辑。这种类编程语言具备描述业务的能力，因此，通过它能够进行轻量级的编码来还原业务。不仅如此，为了实现对业务的干预，除了可以断开连接以外，结合计算能力，我们还可以通过类编程语言来实现对报文任意内容的修改, 实现对请求和响应的完全控制。
图3当然，考虑到安全产品的使用者通常为非程序员，更习惯面对配置文件而非一段代码。因此，这种类编程语言虽包含语言要素，但仍以规则文件方式呈现，并采用可以体现层次结构并方便词法校验的 JSON 格式。
因此，在这种解决方案下，Web 安全产生了一种新玩法，即：安全测试人员在发现漏洞后，利用业务安全动态加固平台现场写出修复代码来供开发人员参考，并且在开发人员修复代码之前，可以通过测试人员编写的虚拟补丁来及时地和非侵入式地缓解或解决已发现的业务安全问题，实现对业务透明的漏洞修复。
图4
