实用的业务逻辑漏洞

零基础学黑客，搜索公众号：白帽子左一

概述

传统安全测试主要依靠基于漏洞类型的自动化扫描检测，辅以人工测试，来发现如SQL注入、XSS、任意文件上传、远程命令执行等传统类型的漏洞，这种方式往往容易忽略业务系统的业务流程设计缺陷、业务逻辑、业务数据流转、业务权限、业务数据方面的安全风险。

过度依赖基于漏洞的传统安全测试方式脱离了业务系统本身，不与业务数据相关联，很难发现业务层面的漏洞，企业很可能因为简单的业务逻辑漏洞而蒙受巨大损失。

一.登录认证模块

1.暴力破解测试

概述

暴力破解测试是指针对应用系统用户登录账号与密码进行的穷举测试，针对账号或密码进行逐一比较，直到找出正确的账号与密码。

一般分为以下三种情况：

①.在已知账号的情况下，加载密码字典针对密码进行穷举测试；

②.在未知账号的情况下，加载账号字典，并结合密码字典进行穷举测试；

③.在未知账号和密码的情况下，利用账号字典和密码字典进行穷举测试。

复现过程

第一步：在目标的登陆页面输入账户名和密码，点击确定时用burp抓包。

第二步：将数据包发送给Intruder模块，并且指定爆破点

第三步：加载字典，开始攻击，根据响应来判断密码/用户名是否正确

2.Session 会话固定测试
概述

Session 是应用系统对浏览器客户端身份认证的属性标识，在用户退出应用系统时，应将客户端 Session 认证属性标识清空。

如果未能清空客户端 Session 标识，下次登录系统时，系统会重复利用该 Session 标识进行认证会话。

攻击者可利用该漏洞生成固定Session 会话，并诱骗用户利用攻击者生成的固定会话进行系统登录，从而导致用户会话认证被窃取。

漏洞复现

第一步：登陆目标网站之后，用burp查看数据包，重点查看类似SessionID的字符，并记录。

第二步：重新登陆，再次用burp查看数据包，对比两个数据包中的SessionID的字符，如果相同则漏洞存在。

3.Seesion 会话注销测试
概述

Session 是应用系统对浏览器客户端身份认证的属性标识，在用户注销或退出应用系统时，系统应将客户端 Session 认证属性标识清空。

如果未能清空 Session 认证会话，该认证会话将持续有效，此时攻击者获得该 Session 认证会话会导致用户权限被盗取。

漏洞复现

第一步：登陆目标网站之后，选择一个功能，比如结算订单等等，然后将这个数据包发送给Repeater模块。

第二步：退出网站，然后在Repeater模块将数据包再次发送，如果成功，则说明存在该漏洞。

4.Seesion 会话超时时间测试
概述

在用户成功登录系统获得 Session 认证会话后，该 Session 认证会话应具有生命周期，即用户在成功登录系统后，如果在固定时间内（例如 10 分钟）该用户与服务器无任何交互操作，应销毁该用户 Session 认证会话信息，要求用户重新登录系统认证。

漏洞复现

第一步：登陆目标网站之后，选择一个功能，比如结算订单等等，然后将这个数据包发送给Repeater模块。

第二步：网站不再动，等30分钟或者更长之间之后，将数据包发送，如果结算成功，则漏洞存在。

5.Cookie 仿冒测试

概述

服务器为鉴别客户端浏览器会话及身份信息，会将用户身份信息存储在 Cooki中，并发送至客户端存储。攻击者通过尝试修改 Cookie 中的身份标识，从而达到仿冒其他用户身份的目的，并拥有相关用户的所有权限。

漏洞复现

第一步：准备两个账号，A、B 。使用A账户登陆目标网站，然后使用burp查看数据包，记录其中的cookie数据。

第二步：再用B账号，应用网站提供的一个功能，比如删除某个数据，拦截数据包，将其中的Cookie替换成A账户的cookie，如果能删除成功，则说明存在cookie仿冒。

6.登录失败信息测试

概述

在用户登录系统失败时，系统会在页面显示用户登录的失败信息，假如提交账号在系统中不存在，系统提示“用户名不存在”、“账号不存在”等明确信息；假如提交账号在系统中存在，则系统提示“密码/口令错误”等间接提示信息。攻击者可根据此类登录失败提示信息来判断当前登录账号是否在系统中存在，从而进行有针对性的暴力破解口令测试。

漏洞复现

第一步：在系统登录页面中输入不存在的账号信息并提交，或者输出错误的密码，如果网站会进行相应的账号错误/密码错误等的提示，就说明存在该漏洞。

二.业务办理模块

1.订单 ID 篡改测试
概述

在有电子交易业务的网站中，用户登录后可以下订单购买相应产品，购买成功后，用户可以查看订单的详情。

当开发人员没有考虑登录后用户间权限隔离的问题时，就会导致平行权限绕过漏洞。

攻击者只需注册一个普通账户，就可以通过篡改、遍历订单 id，获得其他用户订单详情，其中多数会包括用户的姓名、身份证、地址、电话号码等敏感隐私信息。

黑色产业链中的攻击者通常会利用此漏洞得到这些隐私信息。

漏洞复现

第一步：在目标网站查看订单时，抓包，修改订单号。

第二步：如果修改订单号之后，能看到其他人的订单，就说明漏洞存在。

2.手机号码篡改测试
概述

手机号通常可以代表一个用户身份。当请求中发现有手机号参数时，我们可以试着修改它，测试是否存在越权漏洞。系统登录功能一般先判断用户名和密码是否确，然后通过 Session 机制赋予用户令牌。

但是在登录后的某些功能点，开发者很容易忽略登录用户的权限问题。

所以当我们用 A 的手机号登录后操作某些功能时，或通过其他方式尝试篡改手机号，即可对这类问题进行测试。

漏洞复现

第一步：比如修改密码时，存在手机号验证，那么发送验证码时抓包，然后将手机号修改成其他人的手机号，如果能收到信息，则说明漏洞存在。

3.邮箱和用户篡改测试
概述

在发送邮件或站内消息时，篡改其中的发件人参数，导致攻击者可以伪造发信人进行钓鱼攻击等操作，这也是一种平行权限绕过漏洞。

用户登录成功后拥有发信权限，开发者就信任了客户端传来的发件人参数，导致业务安全问题出现。

漏洞原理

第一步：在目标网站发送邮箱处，点击并且拦截数据包，找到邮箱对应的参数。

第二步：在邮箱对应的参数处，进行修改成其他的邮箱号，如果邮箱能发送，并且邮箱内容发送给了指定的邮箱号，则漏洞存在。

4.竞争条件测试
概述

竞争条件通常是在操作系统编程时会遇到的安全问题：当两个或多个进程试图在同
时刻访问共享内存，或读写某些共享数据时，最后的竞争结果取决于线程执行的顺序（线程运行时序），称为竞争条件（Race Conditions）。在 Web 安全中，我们可以沿用这个概念，在服务端逻辑与数据库读写存在时序问题时，就可能存在竞争条件漏洞，如图 5-25 所示。攻击者通常利用多线程并发请求，在数据库中的余额字段更新之前，多次兑换积分或购买商品，从中获得利益。

漏洞复现

第一步：某网站退款提现时存在竞争条件漏洞。申请退款时，点了两次，生成了两单退款申请。

ps：将功能的数据包发送到Intruder模块，更容易实现。

5.业务授权访问模块
概述

非授权访问是指用户在没有通过认证授权的情况下能够直接访问需要通过认证才
能访问到的页面或文本信息。可以尝试在登录某网站前台或后台之后，将相关的页面链接复制到其他浏览器或其他电脑上进行访问，观察是否能访问成功。

漏洞复现

第一步：在 IE 浏览器中登录某网站进行交费

第二步：复制交费成功的 URL，在火狐浏览器里访问，成功访问。

三.回退及流程模块

1.回退测试
概述

很多 Web 业务在密码修改成功后或者订单付款成功后等业务模块，在返回上一步重新 修改密码或者重新付款时存在重新设置密码或者付款的功能，这时如果能返回上一步重复 操作，而且还能更改或者重置结果，则存在业务回退漏洞。

漏洞复现

第一步：密码修改成功后，进行回退测试（检查是否可以回退，并进行操作，如果存在，可能存在回退漏洞）

第二步：尝试是否可以进行回退，结果可以回到重置密码这一步，即第三步，可以修改密码，成功且无限制

2.业务流程乱序测试
简述

该项测试主要针对业务流程的处理流程是否正常，确保攻击者无法通过技术手段
绕过某些重要流程步骤，检验办理业务过程中是否有控制机制来保证其遵循正常流程。例如业务流程分为三步：第一步，注册并发送验证码；第二步，输入验证码；第三步，注册成功。在第三步进行抓包分析，将邮箱或手机号替换为其他人的，如果成功注册，就跳过了第一步和第二步，绕过了正常的业务流程。

漏洞复现

第一步：使用网站的充值按钮，并用 Burp Suite 工具进行数据包截取，金额可随意填写，截获支付订单数据包，放弃支付，获取生成的订单号。

第二步：利用获取的订单号构造链接 http：//www.xxx.com/index.php？controller=site&action=payok&out_trade_no=充值订单号，直接访问这个链接即可成功充值

四.验证码模块

1.验证码暴力破解测试
简述

验证码机制主要被用于防止暴力破解、防止 DDoS 攻击、识别用户身份等，常见的
验 证码主要有图片验证码、邮件验证码、短信验证码、滑动验证码和语音验证码。

以短信验证码为例。短信验证码大部分情况下是由 4～6 位数字组成，如果没有对验证码的失效时间和尝试失败的次数做限制，攻击者就可以通过尝试这个区间内的所有数字来 进行暴力破解攻击。

漏洞复现

第一步：填写任意号码进行注册，本案例使用手机号码为 16666666666，单击获取手机动态码，会向手机发送一条验证码信息

第二步：抓包，并且将验证码的部分进行爆破。

2.验证码重复使用测试
简述

在网站的登录或评论等页面，如果验证码认证成功后没有将 session 及时清空，将会导致验证码首次认证成功之后可重复使用。测试时可以抓取携带验证码的数据包重复提交，查看是否提交成功。

漏洞复现

第一步：在客户投诉建议处，输入要投诉的内容，并输入验证码，抓取数据包并修改投诉内容参数 complaintsContent 的值，通过 BurpSuite 工具重复提交投诉信息

第二步：经过暴力重复提交后，客户端显示提交成功，

3.验证码客户端回显测试
简述

当验证码在客户端生成而非服务器端生成时，就会造成此类问题。当客户端需要和服务器进行交互发送验证码时，可借助浏览器的工具查看客户端与服务器进行交互的详细信息。

漏洞复现

第一步：使用浏览器访问该网站，在找回密码页面中任意输入一个手机号码和开户证件号

第二步：按F12，查看网络中的网络请求信息。

4.验证码绕过测试
简述

在一些案例中，通过修改前端提交服务器返回的数据，可以实现绕过验证码，执行我们的请求。

漏洞复现

第一步：首先输入任意手机号码和密码，我们此处以 18888888886 为例，单击“获取手机验证码”，由于我们无法获取到 18888888886 这个手机的真实验证码，我们随意填写一个验证码 1234，然后抓包，拦截它的响应包。

第二步：单击 Forword 后，burp 工具里显示的就是网站返回的数据包。

因为我们填写的手机验证码 1234 肯定是错误的，而此时 res_code 的值为 1，证明了当手机验证码错误时 res_code 的值为 1。

我们将返回数据包中的 res_code 的值改为 0，从而实现绕过验证码