业务逻辑漏洞

[PyxYuYu]

If you smile when no one else is around, you really mean it.

0x01 业务逻辑漏洞

---

• 业务逻辑漏洞
  • 由于程序逻辑不严谨或逻辑太过复杂，导致一些逻辑分支不能正常处理或处理错误，统称为 业务逻辑漏洞
  • 关注重点
    • 业务流程
    • 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 id）的攻击手段
        • 攻击步骤
          • 攻击者通过某种手段重置目标用户的 Session id，然后监听用户会话状态
          • 目标用户携带攻击者设定的 Session id 登录站点
          • 攻击者通过 Session id 获得合法会话
        • 攻击者重置 Session id 的方式
          • XSS
          • 如果 Session id 在 URL 中，可以通过诱导用户去点击重置了 Session id 的 URL
          • 如果使用 Cookie 来存放 Session id，可以使用以下方法
            • 使用客户端脚本来设置 Cookie 到浏览器
              • 大多数浏览器都支持用客户端脚本来设置 Cookie
              • 例如： document.cookie="sessionid=123"
              • 这种方式可以采用 XSS 攻击来达到目的
              • 防御方法
                • 设置 HttpOnly 属性，但有少数浏览器存在漏洞，即使设置了 HttpOnly，也可以重写 Cookie，所以还需要其他验证方式，比如 User-Agent、Token 等
            • 使用 HTML 的 <META> 标签加 Set-Cookie 属性
              • 服务器可以采用在返回的 HTML 文档中增加 <META> 标签的方式来设置 Cookie
              • 例如： ``<meta http-equiv=Set-Cookiecontent="sessionid=123">
              • 与客户端脚本相比，对 <META> 标签的处理目前还不能被浏览器禁止
            • 使用 Set-Cookie 的 HTTP 响应头部设置 Cookie
              • 攻击者可以使用一些方法在 Web 服务器的响应中加入 Set-Cookie 的 HTTP 响应头部
              • 例如：入侵目标服务器所在域的任一主机，或者攻击用户的 DNS 服务器
      • Cookie 仿冒攻击
        • 通过修改 Cookie 中的某个参数来实现登录其他用户
    • 弱加密
      • 未使用 HTTPS，前端加密，用密文去后台验证，可以利用 smart decode 进行解码
  • 数据篡改
    • 手机号 篡改
      • 抓包修改手机号参数为其他号码进行尝试，例如办理查询页面，输入自己的号码然后抓包，修改手机号为他人号码，查看是否可以查询他人业务
    • 邮箱或者用户 篡改
      • 抓包修改用户或者邮箱为其他用户或者邮箱
      • 例如：
        • 修改普通用户密码，抓包
        • 将 Referer 和 POST 中的普通用户改成 admin
        • 提交数据后，直接返回了 admin 的密码修改页面，利用逻辑漏洞获取超级权限
    • 订单ID 篡改
      • 查看自己订单，修改 订单ID 查看是否能查看其他订单信息
    • 商品编号 篡改
      • 积分商城，利用低积分兑换高积分礼物
      • 选取低积分礼物兑换，提交抓包
      • 修改其中的 goods_id（商品编号）为高积分的商品编号
      • 提交，就可以发现逻辑漏洞的实现
    • 用户ID 篡改
      • 抓包查看自己的 用户ID，修改 ID 查看是否能查看其他用户信息
      • 例如：
        • 查看简历处，抓包修改 简历ID
        • 提交，就可以查看其他用户的简历
    • 金额 篡改
      • 抓包修改金额等字段
      • 例如：
        • 将支付页面抓取请求中商品的金额字段，修改成任意数额的金额（如负数）
        • 提交，查看能否以修改后的金额数据完成业务流程
    • 商品数量 篡改
      • 抓包修改商品数量等字段
      • 例如：
        • 将支付页面抓取请求中商品数量字段，修改成任意数量（如负数）
        • 提交，查看能否以修改后的数量完成业务流程
      • 最大数量突破限制
        • 很多商品限制用户购买数量，服务器仅在页面通过 JS 脚本限制，未在服务端校验用户提交的数量，通过抓包修改商品最大限制数量，即将请求中的商品数量改为大于最大数值限制，查看是否能完成修改后的数量完成业务流程
  • 密码找回
    • 常见的密码找回方式
      • 邮箱找回密码
      • 根据密码保护问题找回密码
      • 根据手机号找回密码
    • 密码找回逻辑测试流程
      • 尝试正常密码找回流程
      • 选择不同的找回方式，记录所有数据包
      • 分析数据包，找出敏感部分
      • 分析后台找回机制所采用的验证手段
      • 修改数据包进行验证是否存在密码找回漏洞
    • 漏洞分类
      • 用户凭证暴力破解（验证码）
        • 四位或六位纯数字，验证码次数未限制
        • 例如：
          • 根据手机号找回密码，随便输个验证码，抓包
          • 暴力破解验证码（假如只有四位），很快就可以破解出来
        • 注意：如果验证码次数限制，破解一会就会提示请求过于频繁，这时就需要绕过限制
          • 绕过的话，这里可以考虑一个现状：
            • 国内很多情况下都没有过滤字符和限制输出长度，验证很有可能只是简单的处理
          • 例如：
            • 根据手机号找回密码，但是验证次数被限制，抓包
            • 可以尝试在手机号后面添加不为数字的字符，查看是否过滤

               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，相当于修改了密码
      • session 覆盖
        • 例如：
        • 同一浏览器，首先输入自己的账户进行邮箱密码找回，进入邮箱查看链接，接着输入他人账户，进行密码找回，返回刚刚自己的邮箱点击链接，由于 session 覆盖导致了，这个链接成为了修改他人密码的链接，成功修改他人密码
  • 绕过授权验证
    • 未授权访问
      • 用户在没有通过认证授权的情况下直接访问需要通过认证才能访问的页面或文本
    • 水平越权
      • 相同级别（权限）的用户或者同一角色不同的用户之间，可以越权访问、修改或者删除的非法操作，如果出现此漏洞，可能会造成大批量的数据泄漏，严重的甚至会造成用户信息被恶意篡改
    • 垂直越权
      • 不同级别之间或不同角色之间的越权
      • 垂直越权可以分为
        • 向上越权
          • 普通用户可以执行管理员权限，比如发布文章、删除文章等操作
          • 修复方法
            • 如果管理员和普通用户是同一张数据库表，就必须要存在权限验证字段，权限验证字段用于区分是否为管理员，如果不在同一张表，在过滤器中直接去除管理员信息即可
        • 向下越权
          • 一个高级用户可以访问低级用户信息（暴露用户隐私）
  • 验证码突破
    • 验证码暴力破解
      • 工具
        • Burpsuite
        • Hydra
    • 验证码时间、次数测试
      • 重复提交携带验证码的数据包，查看返回包，判断次数
    • 验证码客户端回显测试
      • 抓包测试，是否有回显，验证码是否会被返回
    • 验证码绕过测试
      • 抓包，删除验证码字段，查看是否可以成功发送
      • 抓包，正常流程下，记录验证码后的数据包，替换目标包中内容，直接发送，查看是否可以直接绕过验证码
  • 流程乱序
    • 顺序执行
      • 在一个逻辑流程中，按照第一步、第二步、第三步这种模式进行一步一步的验证，有顺序的执行逻辑过程
    • 常见的顺序执行漏洞
      • 密码找回的顺序执行
        • 可以绕过验证，直接跳转至重置密码页面
        • 绕过的方式有很多种
          • 更改 用户名（邮箱等等）
          • 替换正常流程数据包
          • 分析数据包中关键字符串（加密后），进行关联替换
      • 支付环节的顺序执行
        • 商品数量正负数（最大值）
        • 价格正负数（不局限与商品价格，还有运费等待）
        • 同一订单重复发送请求包，使购买数量增加
        • 抓包，分析是否有 type 之类的参数用于判断执行顺序，可直接更改跳转至支付成功页面
      • 登录验证的顺序执行
        • 登录验证处，有的厂商会先检验验证码，正确后然后检验账户密码，这样就可以实现暴力破解
  • 接口调用安全
    • 重放攻击
      • 在短信、邮件调用业务或生成业务数据环节中（类：短信验证码，邮件验证码，订单生成，评论提交等），对其业务环节进行调用（重放）测试
      • 常见类型
        • 短信轰炸
        • 恶意注册
    • 内容编辑
      • 例如
        • 点击获取短信验证码，抓包，可以修改短信内容，实施下一步攻击
• 业务逻辑漏洞终总结
  • 测试业务的时候，先了解清楚业务整体流程，可以利用思维导图快速理清各个业务之间的关系，也可以通过查看 JS 了解（JS 中可能会存在信息泄漏）
  • 重点关注的业务：个人（他人）信息、密码修改（找回）、支付流程、注册流程、需要手机（邮箱）验证的业务
  • 对每个业务模块进行抓包，分析其中各种请求，注意 特殊参数，很有可能就是这些 特殊参数 决定了业务步骤
  • 抓包重放的过程，需要多次实验，判断是否可以跳过（绕过），如何跳过（绕过），纯数字可以用 数字 + 字母 尝试绕过
  • 返回包中数据的分析，关注特殊字符串和特殊参数
  • 综上所述，业务流程需同时结合 HTTP/HTTPS 请求分析，关注重点在各种可以用于区别的参数，绕过必要验证，跳过业务步骤