攻防演练中的业务逻辑漏洞及检测思路

随着各类前后端框架的成熟和完善，传统的SQL注入、XSS等常规漏洞在Web系统里逐步减少，而攻击者更倾向于使用业务逻辑漏洞来进行突破。业务逻辑漏洞，具有攻击特征少、自动化脆弱性工具无法扫出等特点，也为检测和软件的安全性保障带来了一定的难度。

本文介绍了业务逻辑漏洞的特征并列举了一些常见的业务逻辑漏洞，同时介绍了如何使用行为分析模型对于业务逻辑漏洞来进行检测，以及如何使用应用程序威胁建模过程规范软件开发流程避免在系统里出现业务逻辑漏洞。

一、什么是业务逻辑漏洞

所有Web应用程序都是通过代码逻辑实现各种功能。即使一个简单的Web应用程序，都可能包含着数目庞大的逻辑操作。这些逻辑就是一个复杂的攻击面，但是它却常常被忽略。许多自动化的扫描工具或者代码审计工具，都只能扫出类似SQL注入、XSS等常规的漏洞，因为它们相比于业务逻辑漏洞而言具有显著的攻击特征。

业务逻辑漏洞产生的最核心原因，就是在编写程序时，只考虑常规的操作流程，即“当在A情况下，就会出现B，此时执行C即可",但是开发者却没有考虑当用户执行了意料之外的X时会发生什么.这种对于异常情况的欠考虑，最终导致了安全漏洞的产生。

应用中的缺陷通常分为两种类型:

在不同的应用中有相同的特征;

与应用程序/业务领域严格相关。

其中第一种类型的缺陷，就是类似SQL注入、XSS之类的常规漏洞。这一类漏洞的产生，主要是因为应用程序依赖用户的输入来执行某些重要的功能，但是在用户输入了一些非法字符时，应用程序又未能对于这些输入进行充分的校验和预处理。

而第二种类型的缺陷，则是指的业务逻辑漏洞。它是由错误的应用程序逻辑造成的。业务逻辑缺陷允许攻击者通过绕过应用程序的业务来规则来滥用应用程序。这些攻击被伪装成语法上有效的Web请求，这些请求带有恶意意图来违反预期的应用程序逻辑。

随着ORM框架的普及，以及新一代前端框架如AngularJS、Vue等的流行，常规的SQL注入、XSS等漏洞在实际的业务系统中越来越趋于少见。而在攻防演练过程中，可以用于突破系统的漏洞往往集中于在业务逻辑实现层面的漏洞上。

二、业务逻辑漏洞实际案例

笔者现总结一下常见的业务逻辑漏洞以及它们产生的原因，并简单介绍一下当使用这些业务逻辑进行攻击时可以用什么样的方式来进行检测。

2.1 越权访问

2.1.1 现象

所谓越权访问，即用户A访问到了自己笨没有权限访问到的页面或者接口。

越权又分为水平越权和垂直越权:

水平越权:

即用户A和用户B属于同一个权限组，水平越权就是用户A可以看到用户B才可以看到的一些内容。一个简单的例子，就是保单管理系统中，每个人都只可以看到自己的保单，如果出现用户A可以查看到用户B的保单的现象，此时就发生了水平越权。

图1 红线处即为水平越权

垂直越权:

即用户A和用户B属于不同的权限组，如用户A属于普通用户权限组，而用户B属于管理员权限组，垂直越权就是用户A可以看到用户B才可以看到的内容。一个简单的例子，用户A可以看到通讯录界面，用户B可以看到通讯录和用户管理的界面（其中用户管理界面可以看到用户密码）。如果用户A修改一下请求的URL即可以看到作为管理员才可已看到的全部用户密码，此时就发生了垂直越权。

图2 红线处即为垂直越权

2.1.2 检测思路

出现越权访问漏洞的主要原因，是因为开发人员只是在前端界面进行了简单的菜单隐藏，而没有用统一的服务端拦截器/中间件对于全部URL请求进行权限判断。这样，攻击者只需要在浏览器或者BurpSuite之类的攻击工具中，发出对于指定URL的请求，即可以实现对于特定接口的越权访问。

越权访问请求，本身是不具有攻击特征的，如果要进行检测，需要采取UEBA的检测思路。

假设对于独立的用户A在时间间隔N内的Web访问行为进行刻画，即可以得到他惯常访问的URL合集：

图3 用户A及用户A的惯常访问URL合集

如果将用户A与他所属的权限组/不同权限组用户群体的惯常访问URL合集进行比对，可以发现有些URL是多个用户都会访问的，而有的URL（或者请求中含有的特定的参数）是各个用户访问时都存在差异的。这类具有差异性的URL即为敏感URL。

当用户A访问了不在惯常访问URL合集内的URL，且此URL为敏感URL，即可以判定为发生了越权访问。

图4 水平越权和垂直越权的判定

2.2 Cookie提权

2.2.1 现象

由于本身HTTP请求是无状态的，所以为了可以记录用户的登录状态，Web站点通常在Cookie中记录SessionId来实现对于用户登录状态的识别。

但是，有的Web站点的开发者，除了在Cookie里记录SessionId外，还记录了该用户的权限。后续在做用户的权限判定时，都直接从Cookie里取值判定一个用户是普通用户还是管理员。

由于Cookie本身在浏览器侧是可以手动修改的，这样攻击者一旦修改了Cookie里记录的权限值，即可以将一个普通用户提权为该Web站点的管理员。

如下，就是一个站点在Cookie里使用websitesuperid判定时普通用户(值为0)还是管理员(值为1)。这样，当将该值修改为1后，即可以实现对于登录用户的提权，从而看到站点内只有管理员才可以看到的相关菜单:

图5 修改cookie内的权限字段进行提权

2.2.2 检测思路

此种攻击主要是针对Cookie内的参数进行修改，达到提权的目的。与针对Cookie的SQL注入、XSS攻击不同的是，攻击者虽然也存在针对Cookie内参数的修改行为，但是所输入的值却不存在攻击特征。

针对Cookie提权攻击，我们可以基于Cookie参数对于返回内容的影响进行检测：

1.提取历史时间段，一个用户在一个Web站点访问一个URL的Cookie参数;

2.Cookie参数内值不变的部分为观察对象;

3.当在历史时间内为定值的Cookie在实时流量中出现了变化，且影响了返回内容，则表明存在Cookie提权攻击。

在检测Cookie参数对于返回内容的影响时，主要是需要检测返回内容中菜单的变化情况。而一般菜单在页面开发的过程中，标签的class属性都会带上menu关键字，可以基于此关键字识别返回的DOM结构里的菜单标签及其内容，并检测Cookie参数对于它的影响。

图6 识别DOM结构里的菜单标签

2.3 验证码更新逻辑绕过导致可暴破

2.3.1 现象

为了防止登录界面被暴力破解，很多Web站点都增加了验证码。有很多Web站点的验证码刷新逻辑如下:

图7 存在漏洞的验证码刷新逻辑

乍一看，按照上图所示的验证码校验与刷新逻辑仿佛没有问题。但其实，攻击者通过工具或者脚本直接调用红框里的用户名密码校验接口，就桡骨了验证码的校验和刷新逻辑，即可以对于登录接口进行暴力破解。在这种场景下，验证码虽然在界面存在，但实际并未起到可以防范暴力破解攻击的效用。

2.3.2 检测思路

在绕过验证码暴力破解登录界面的攻击行为中，我们有2种方法进行检测：

1.检测登录接口的暴力破解行为;

2.检测绕过验证码校验的异常访问行为.

2.3.2.1 检测登录接口的暴力破解行为

检测登录接口的暴力破解行为，最核心的就是从Web站点的访问日志中，识别出哪个URL是登录接口。

我们可以定义用户名/密码参数字典，例如用户名在HTTP请求中的参数名通常为username,uname,而密码在HTTP请求中的参数名通常为password,pwd。当一个Web访问请求的GET参数或者POST参数里包含用户名/密码参数字典里的字符串，则认为该接口为登录接口。

一个源IP（如果攻击者挂了代理，可以使用X-Forward-For字段里记录的真实IP代替），在短时间内对于一个站点的登录接口发出大量的请求，且用户名/密码的参数的值在不断变化，则可以判定为在对于此登录接口进行暴力破解。

2.3.2.2 检测绕过验证码校验的异常访问行为

检测绕过验证码校验的异常访问行为，可以基于访问图基线进行实现。

通过采集N天的Web访问日志，我们可以对于一个站点的访问行为，以及在各个页面的跳转关系(referer，uri以及url访问的先后顺序以及时间间隔)绘制出访问图基线:

图8 基于图基线检测绕过验证码校验

如图8所示，在历史的图基线中，我们发现通常的访问顺序都是：

验证码校验url -> 登录校验url -> 验证码刷新url

如果突然出现了在图基线中并不存在的边，如图所示即用户直接访问登录校验url的行为，则认为属于发生异常访问行为。具体到这个例子，即为绕过验证码校验的异常登录行为。

从上面的几个例子中可以看出来，基于业务逻辑漏洞的攻击通常都没有或者只有较少的攻击特征。随着攻击者手法的丰富多样化，防守方不能只专注于基于攻击特征的检测方式，只有将基于攻击的检测方式与基于异常行为的检测方式结合起来，才能让自己更好的在未来的安全运营过程中发现威胁。

三、如何避免系统存在业务逻辑漏洞

OWASP在描述业务逻辑漏洞时指出它虽然不如OWASP TOP10中的漏洞那样常见，但也依旧在许多重要的业务系统中存在。然而业务逻辑漏洞属于无法自动扫描出的漏洞，我们该如何避免系统中出现业务逻辑漏洞呢？OWASP指出可以使用应用程序威胁建模过程来避免系统中出现业务逻辑漏洞。

图9 应用程序威胁建模过程

在系统生命周期里引入威胁建模可以带来如下方面的好处：

1.进行安全设计

2.更充分的对资源进行调研;更合理的对于安全、开发以及其他任务排定优先级;

3.将安全和开发结合到一起，更好的互相理解以及构建系统;

4.确定威胁和兼容性的需求，并且评估它们的风险;

5.定义和构建需求控制;

6.平衡风险、控制和易用性;

7.基于可接受的风险，确定哪块的控制是不需要的.

8.文档化威胁和缓解措施;

9.确保业务需求(或目标)在面对恶意参与者、事故或其他影响因素时得到充分保护;

10.定义安全测试用例来验证安全方面的需求;

比较重要的安全步骤如下:

1.每一个应用程序都需要使用事务数据流和访问控制矩阵来描述业务逻辑;

2.在设计业务逻辑时，就将它设计为防止业务逻辑滥用的。使用过程验证和控制假设应用程序业务逻辑可能被滥用的一些情况.

3.使用应用程序威胁建模来识别业务逻辑中存在设计缺陷的地方;

4.对于OWASP/WASC/SANS-25-CWE中描述的业务逻辑漏洞进行测试;

5.对于业务逻辑的滥用建立确定的测试用例;

6.分析风险并应用对策来减轻业务逻辑攻击的可能性和影响.

微软也提供了威胁建模工具以供下载：

https://aka.ms/threatmodelingtool

图10 威胁建模的五个关键步骤

微软威胁建模的五个关键步骤如下：

1.定义安全需求;

2.创建应用程序简图;

3.确定威胁;

4.缓解威胁;

5.校验威胁是否被缓解;

参考文献：

【1】《黑客攻防技术宝典Web实战篇》

【2】《黑客大曝光-Web应用安全》

【3】《What is a Business Logic Flaw Vulnerability》

【4】《OWASP Business Logic Vulnerability》

【5】《How to Prevent Business Flaws Vulnerabilities In Web Applications》

【6】《Microsoft Threat Modeling》