业务逻辑漏洞

转载：https://github.com/PyxYuYu/MyBlog/issues/102

• 业务逻辑漏洞
  • 因为程序逻辑不严谨或逻辑太过复杂，致使一些逻辑分支不能正常处理或处理错误，统称为 业务逻辑漏洞
  • 关注重点
    • 业务流程
    • 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 请求分析，关注重点在各类能够用于区别的参数，绕过必要验证，跳过业务步骤