业务逻辑漏洞

概述

由于程序逻辑控制不够严谨或逻辑设计太过复杂，导致一些逻辑分支不能正常处理或处理错误，统称为 业务逻辑漏洞。

特点

1、业务流程

2、HTTP/HTTPS 请求分析

漏洞分类

身份认证

暴力破解

在 没有验证码限制或者验证码可以 多次 使用的情况下

• 使用已知用户名对密码进行暴力破解
• 使用一个弱口令密码对用户进行暴力破解

工具

• Burpsuite
• Hydra

暴力破解可参考此篇文章：逻辑漏洞之暴力破解

Cookie&Session

• Cookie：机制采用的是在客户端保持状态的方案，用来记录用户的一些信息，也是实现 Session 的一种方式.

Session：机制采用的是在服务器端保持状态的方案，用来跟踪用户的状态，可以保存在集群、数据库、文件中.

• Cookie：的内容主要包括：名字、值、过期时间、路径和域名，其中路径和域名一起构成 Cookie 的作用范围，若不设置过期时间，则表示这个 Cookie 的生命周期为浏览器会话期间，关闭浏览器窗口，则消失，这种生命期为浏览器会话期的 Cookie 被称为会话 Cookie

• Session：机制是一种服务端的机制，当程序需要为某个客户端的请求创建一个 Session 时，服务器会首先检查这个客户端的请求里是否包含了一个 Session 标识（Session id），如果已包含说明此前已经为此客户端创建过 Session，服务器会按照 Session id 将这个 Session 检索出来使用（检索不到，会新建一个），如果客户端请求不包含 Session id，则会为此客户端创建一个 Session 并且生成一个 Session id，这个 Session id 将被在本次响应中返回给客户端保存，保存这个 Session id 的方式可以采用 Cookie，如果客户端浏览器禁用了 Cookie，一般这种情况下，会使用一种 URL 重写的技术来进行会话跟踪，即每次 HTTP 交互，URL 后都会被附加一个诸如 sid=xxxxxxxx 这样的参数，服务端根据此来识别用户。

一些网站会利用 Cookie 是否为空、Session 是否为 true 来判断用户是否可以登录，只要构造一个 Cookie 或 Session 为 true 就可以绕过认证登录。

Session会话固定攻击

​ 会话固定（Session fixtation）是一种诱骗用户去访问攻击者构造后的会话标识（session id）（攻击者构造的session id是非服务器分配出来的，而普通账户具有网站相应权限。如果用户访问了攻击者构造好的URL，导致原本的session id不具有相应权限经过用户访问后具有与服务器正常通信的session id了。

攻击步骤

1. 攻击者通过其他手段获得用户与服务器进行通信<非session id>信息
2. 构造URL附带自己设置的session id<个人觉得这里最难，如果构造的URL中包含了session id值易被发现>
3. 用户访问攻击者构造好的URL（其中包含攻击者设定的session id）
4. 攻击者构造的session id具有与服务器通信权限

Cookie伪造攻击

​ 通过修改 Cookie 中的某个参数来实现登录其他用户，例如：uid或其他信息。

弱加密

​ 传输未使用 HTTPS、前端加密，用密文去后台验证，可以利用 smart decode 进行解码。

数据篡改

手机号篡改

​ 抓包修改手机号参数为其他号码进行尝试，例如办理查询页面，输入自己的号码然后抓包，修改手机号为他人号码，查看是否可以查询他人业务或个人信息等。

邮箱或用户篡改

​ 抓包修改用户或者邮箱为其他用户或者邮箱。

例如

• 修改普通用户密码，抓包
• 将 Referer 和 POST 中的普通用户改成 admin
• 提交数据后，直接返回了 admin 的密码修改页面，利用逻辑漏洞获取超级权限

订单ID篡改

​ 查看自己订单，修改 订单ID 查看是否能查看其他订单信息

参考：某旅游系统越权/篡改

商品编号篡改

可测试积分兑换功能处测试

• 积分商城，利用低积分兑换高积分礼物
• 选取低积分礼物兑换，提交抓包
• 修改其中的 goods_id（商品编号）为高积分的商品编号
• 提交，就可以发现逻辑漏洞的实现

用户ID篡改

​ 抓包查看自己的 用户ID，修改 ID 查看是否能查看其他用户信息

例如：

• 查看简历处，抓包修改 简历ID
• 提交，就可以查看其他用户的简历

金额篡改

​ 抓包修改金额等字段再进行重放查看是否被修改。

例如：

• 将支付页面抓取请求中商品的金额字段，修改成任意数额的金额（如负数）
• 提交，查看能否以修改后的金额数据完成业务流程

商品数量篡改

​ 抓包修改商品数量等字段再进行重放查看是否被修改。

例如：

• 将支付页面抓取请求中商品数量字段，修改成任意数量（如负数）
• 提交，查看能否以修改后的数量完成业务流程

最大数量突破限制

• 很多商品限制用户购买数量，服务器仅在页面通过 JS 脚本限制，未在服务端校验用户提交的数量，通过抓包修改商品最大限制数量，即将请求中的商品数量改为大于最大数值限制，查看是否能完成修改后的数量完成业务流程

密码找回

常见的密码找回方式

• 邮箱找回密码
• 根据密码保护问题找回密码
• 根据手机号找回密码

密码找回逻辑测试流程

• 尝试正常密码找回流程
• 选择不同的找回方式，记录所有数据包
• 分析数据包，找出敏感部分
• 分析后台找回机制所采用的验证手段
• 修改数据包进行验证是否存在密码找回漏洞

用户凭证爆破(验证码)

• 四位或六位纯数字，验证码次数未限制

例如

• 根据手机号找回密码，随便输个验证码，抓包
• 暴力破解验证码（假如只有四位），很快就可以破解出来

参考：逻辑漏洞之验证码爆破

注意：如果验证码次数限制，破解一会就会提示请求过于频繁，尝试以下绕过限制：

• 根据手机号找回密码，但是验证次数被限制，抓包可以尝试在手机号后面添加不为数字的字符，查看是否过滤

1

phone=18888888888abc

• 只要更换手机号后面的字符，就可以绕过请求过于频繁的限制
• 但是校验时，手机号后面的字符会被过滤，也就是可以利用暴力破解验证码
• 所以只要在暴力破解的同时，改变手机号后面的字符即可达到漏洞效果

返回凭证(验证码或token)

​ 对整个请求进行抓包重放分析，是否会把敏感信息泄漏至响应体内。

例如

• 根据手机号找回密码、抓包，可以发现验证码直接显示 verifycode=xxxx，或者由 md5 加密后显示，解密即可（同理，有的时候输入用户名，抓包可以看到返回的手机号等其他信息）
• 根据邮箱找回密码
  • 抓包，可以发现返回的数据中有一个加密的字符串（token），先记录下这个加密字符串
  • 继续按照正常流程，登录邮箱获得验证码，返回填写验证码后，进入下一个填写新密码页面，发现 URL 后新增了一个加密验证的字符串
  • 这个字符串就是之前数据包中记录的字符串，所以邮箱验证码这个环节可以绕过，直接用他人邮箱抓包获得加密字符串就可以重置他人密码

页面存储凭证

​ 通过密保问题找回密码，查看源码，密保问题和答案就在源码中显示。

邮箱弱token

• 重置密码链接直接使用用户名来区别，改变用户名即可更改他人密码
• Unix时间戳 + md5
  • 通过邮箱找回密码，正常流程去邮箱查看重置密码链接，发现链接处有一串 md5 加密字符串
  • 字符串解密，类似 1491293277（10位），可以判断为 Unix时间戳
  • 重置他人密码只需要利用他人邮箱发送重置密码邮箱，在短时间内对 Unix时间戳 进行暴力破解，即可获得重置密码的链接

服务器时间

例如

• 利用两个帐号同时点击找回密码，去邮箱查看找回密码的链接，发现两者的随机 token 只差 1-2，而且可以猜测出为服务器时间
• 所以可以用一个未知帐号和一个已知帐号同时点击找回密码，稍微遍历一下随机 token，就可以构造出未知帐号的密码找回链接

用户凭证有效性

短信验证码

例如

• 通过他人手机号找回密码，抓包，将他人手机号替换成自己的手机号，获取验证码，提交后修改密码
• 通过自己手机号找回密码，获取验证码后抓包，将数据包中的 username 改为他人用户名，提交后成功修改他人密码

邮箱 token

例如

• 通过邮箱找回密码，访问链接重置密码，输入新密码后提交时抓包，虽然有 token，但是依然可以直接修改 用户ID 进而修改他人密码

重置密码 token

例如

• 正常流程下，对每个功能模块进行抓包，分别是发送验证码，验证验证码是否正确，获取 token，重置密码
• 接下来，用他人帐号通过邮箱验证，抓包，将其中 Cookie 内从 JSESSIONID 开始的内容替换至正常流程的发生验证码包内，同时替换自己接受验证码的邮箱，提交
• 通过邮箱获取验证码后，将验证码、Cookie、他人帐号、自己邮箱替换至验证验证码模块，提交（不用在意返回是否错误）
• 继续替换内至获取 token 模块，提交获取 token
• 最后将获取的 token 和上面的内容替换至最后的重置密码模块，提交成功修改密码

重新绑定

手机绑定

例如

• 给已知账户绑定手机，发现绑定手机的 URL 链接中有 uid 参数，修改 uid 参数为他人的，即可实现将他人的账户绑定上自己的手机，之后通过手机来修改密码
• 修改个人资料处抓包，修改 userId 为他人，修改 mobilePhone 为自己的手机，即可实现将他人的账户绑定上自己的手机，之后通过手机来修改密码

邮箱绑定

例如

• 通过邮箱找回密码，URL 链接中修改 用户ID 为他人，邮箱不变，之后通过链接可以将他人账户绑定为自己的邮箱，之后通过邮箱找回密码

服务器验证

最终提交步骤

例如

• 通过邮箱找回密码，最后通过链接至修改密码页面，修改密码后提交，抓包，获得 Uid 参数，修改为他人，即可修改其他用户密码

服务器验证可控内容

例如

• 正常流程，通过手机号提交验证码找回密码处抓包，记录下这个包的内容
• 通过已知用户名找回密码，查看源代码可以发现用户其他信息（比如：手机号、邮箱）
• 通过发现的手机号选择通过手机找回密码，随便输入短信验证码，抓包
• 修改之前记录下的包的内容，将其中 Session id、用户ID 修改为刚刚从其他用户名抓包获得的内容，提交这个包，即可成功修改他人密码

绕过认证

例如

• 通过密码保护问题找回密码，抓包，将密码保护问题删除，直接修改密码，提交
• 注：此处密保问题和新密码在同一页面

用户身份认证

帐号与手机号的绑定

例如

• 通过手机找回密码，输入验证码和新的密码，F12 审查元素，修改自己的手机为他人手机，提交成功修改他人手机（也可以抓包修改）

帐号与邮箱的绑定

例如

• 通过邮箱找回密码，点击请重新发送邮件处抓包，将邮箱改为自己的邮箱，通过链接成功修改密码

找回步骤

跳过验证步骤、找回方式、直接到设置新密码页面

例如

• 正常流程下，密码找回，查看最后设置新密码页面的 URL，记录下来
• 继续返回密码找回处，输入其他用户名，提交找回申请，直接访问上面记录下的修改密码页面，成功修改密码
• 也可以正常流程下，修改密码页面抓包，修改其中的 USERNAME_COOKIE 为其他用户（有可能会经过编码，比如 base64），提交即可修改其他用户密码
• 如果抓包其中有 step 参数，可以修改这个参数为最后一步（比如：5），提交便可略过之前的步骤

本地验证

​ 在本地验证服务器的返回信息，确定是否执行密码重置，但是其返回信息是可控的内容，或者是可以获得的内容。

例如

• 通过手机找回密码，随便输入验证码，抓包，发送，拦截返回包（Burpsuite 中可以选取 do intercept --> response to this request）

• 修改返回包中的返回码，继续发送，说不定就可以绕过验证，直接跳到修改密码的页面

• 通过手机找回密码，正常流程下到重置密码页面，抓包查看返回数据中有一段加密字符串

• 利用他人手机找回密码，URL 跳转到验证身份页面，链接中就有一段加密字符串，记录下，随便输入验证码，抓包，修改包中数据为正常流程下的数据，替换加密字符串，Forward 发送，就可以绕过验证码，直接修改密码

发生短信等验证信息的动作在本地执行，可以通过修改返回包进行控制。

例如

• 通过用户名找回密码，提交后会自动发送验证码到手机中，所以抓包，修改手机为自己的手机（如果其中有 type 之类的参数，也可以尝试修改，有 email 之类的参数，可以尝试删除内容），发送修改后的包，手机成功接收验证码
• 输入验证码，继续发送，抓包，如果有 type 之类的参数，可以继续尝试修改，发送就可以成功修改密码

注入

找回密码处存在注入漏洞

• 输入用户名，加个单引号报错，说明可能存在报错，抓包，保存为 txt 文件，导入 Sqlmap 中跑一遍

token 生成

token 生成可控

• 通过邮箱找回密码，正常流程下，抓包查看提交验证码后返回的数据，发现有加密字符串，这个加密字符串和后面重新设置新密码 URL 链接中的加密字符串一样，所以可以利用这个加密字符串
• 根据上面提交验证码的抓包，修改其中的 User 为其他用户（User 有可能会使用 md5 加密），发送，就可以返回其他用户的加密字符串
• 重新返回到找回密码首页，利用其他用户找回，点下一步，到输入验证码处（也有可能需要点击发送验证码），直接修改 URL 链接，加入加密字符串，可以直接绕过验证码，重置密码

注册覆盖

​ 注册重复的用户名，例如 admin，相当于修改了密码

seesion覆盖

例如

• 同一浏览器，首先输入自己的账户进行邮箱密码找回，进入邮箱查看链接，接着输入他人账户，进行密码找回，返回刚刚自己的邮箱点击链接，由于 session 覆盖导致了，这个链接成为了修改他人密码的链接，成功修改他人密码

授权绕过

未授权访问

• 用户在没有通过认证授权的情况下直接访问需要通过认证才能访问的页面或文本。

水平越权

• 相同级别（权限）的用户或者同一角色不同的用户之间，可以越权访问、修改或者删除的非法操作，如果出现此漏洞，可能会造成大批量的数据泄漏，严重的甚至会造成用户信息被恶意篡改

垂直越权

不同级别角色或不同角色之间的越权。

垂直越权可以分为

• 向上越权
  • 普通用户可以执行管理员权限，比如发布文章、删除文章等操作
  • 修复方法
    • 如果管理员和普通用户是同一张数据库表，就必须要存在权限验证字段，权限验证字段用于区分是否为管理员，如果不在同一张表，在过滤器中直接去除管理员信息即可
• 向下越权
  • 一个高级用户可以访问低级用户信息（暴露用户隐私）

验证码

验证码暴力破解

工具

• Burpsuite

• Hydra

• 验证码时间、次数测试

  • 重复提交携带验证码的数据包，查看返回包，判断次数

• 验证码客户端回显测试

  • 抓包测试，是否有回显，验证码是否会被返回

• 验证码绕过测试

  • 抓包，删除验证码字段，查看是否可以成功发送
  • 抓包，正常流程下，记录验证码后的数据包，替换目标包中内容，直接发送，查看是否可以直接绕过验证码

流程乱序

顺序执行

在一个逻辑流程中，按照第一步、第二步、第三步这种模式进行一步一步的验证，有顺序的执行逻辑过程

常见的顺序执行漏洞

• 密码找回的顺序执行

  • 可以绕过验证，直接跳转至重置密码页面
  • 绕过的方式有很多种
    • 更改 用户名（邮箱等等）
    • 替换正常流程数据包
    • 分析数据包中关键字符串（加密后），进行关联替换

• 支付环节的顺序执行

  • 商品数量正负数（最大值）
  • 价格正负数（不局限与商品价格，还有运费等待）
  • 同一订单重复发送请求包，使购买数量增加
  • 抓包，分析是否有 type 之类的参数用于判断执行顺序，可直接更改跳转至支付成功页面

• 登录验证的顺序执行

  • 登录验证处，有的厂商会先检验验证码，正确后然后检验账户密码，这样就可以实现暴力破解

API安全

重放攻击

• 在短信、邮件调用业务或生成业务数据环节中（类：短信验证码，邮件验证码，订单生成，评论提交等），对其业务环节进行调用（重放）测试
• 常见类型
  • 短信轰炸
  • 恶意注册

参考：API及客户端漏洞挖掘

内容编辑

例如

• 点击获取短信验证码，抓包，可以修改短信内容，实施下一步攻击

总结

1. 首先了解清楚业务整体流程，可利用思维导图快速理清各个业务之间的关系，也可以通过查看 JS 了解（JS 中可能会存在信息泄漏：前后端会把路由泄漏在JS源码中）
2. 关注业务：个人（他人）信息、密码修改（找回）、支付流程、注册流程、需要手机（邮箱）验证的业务。
3. 测试过程中各功能进行抓包，分析其中各种请求，注意 特殊参数，很有可能就是这些 特殊参数 决定了业务步骤。
4. 抓包重放的过程，需要多次实验，判断是否可以跳过（绕过），如何跳过（绕过），纯数字可以用 数字 + 字母 尝试绕过
5. 响应数据分析，关注特殊字符串和特殊参数
6. 业务流程需同时结合 HTTP/HTTPS 请求分析，关注重点在各种可以用于区别的参数，绕过必要验证，跳过业务步骤

实战汇总

API及客户端漏洞挖掘

逻辑漏洞—-越权类

逻辑漏洞—-Session会话攻击–待更新

逻辑漏洞—-密码找回–待更新

逻辑漏洞—-验证码漏洞–待更新

Refrere

1
2

https://github.com/PyxYuYu/MyBlog/issues/102
http://www.luckyzmj.cn/posts/4abdabd1.html