业务逻辑漏洞｜最容易被忽略，SRC 高分漏洞

业务逻辑漏洞最容易被忽略SRC 高分漏洞免责声明本文仅面向授权 SRC 白帽爱好者、渗透测试人员做安全学习与思路科普所有测试行为仅允许在厂商 SRC 公开授权范围内、使用自己注册的测试账号进行验证。严禁越权访问真实用户数据、恶意薅取平台资金、批量遍历用户信息、破坏业务系统。未经授权对互联网业务系统进行测试违反《网络安全法》《刑法》将承担法律责任。本文不提供可直接用于恶意攻击的自动化批量利用脚本。前言很多新手入坑 SRC 挖洞第一反应就是打开 AWVS、Xray 等扫描器疯狂扫 SQL 注入、XSS、文件上传。扫了几周拿到一堆低危信息泄露赏金寥寥无几。看着别人提交高危漏洞拿高额赏金自己十分困惑为什么别人能持续产出高分漏洞而扫描器几乎扫不出有价值的洞答案很简单SRC 平台绝大多数中高危高分漏洞不是 SQL 注入、XSS 这类传统 Web 漏洞而是业务逻辑漏洞。SQL 注入、XSS 这类漏洞属于 OWASP Top10 经典技术漏洞扫描器可以自动化识别。厂商安全团队日常巡检、WAF 防护、代码审计都会重点关注这类问题存量漏洞越来越少。而业务逻辑漏洞是业务设计层面的缺陷扫描器完全无法自动发现必须依靠白帽理解业务流程、站在用户角度思考业务规则人工测试挖掘。开发人员很容易忽略安全测试阶段也常常被遗漏大量业务系统都存在这类缺陷一旦验证成功往往直接评定为高危赏金远高于普通注入和 XSS。业务逻辑漏洞本质代码按照开发写的逻辑正常执行但是业务规则本身存在缺陷。程序没有崩溃、没有报错它完全按照代码指令运行只是业务校验逻辑缺失、校验放在前端、状态机没有严格控制攻击者可以篡改参数、跳过步骤、并发请求突破业务规则造成资金损失、用户信息泄露、权限越权等严重后果。很多白帽新手对业务逻辑漏洞存在巨大误解认为逻辑漏洞很难需要懂业务开发、懂复杂业务架构或者认为逻辑漏洞就是简单的越权。实际上业务逻辑漏洞覆盖场景极广从账号登录、密码重置、短信验证码、订单支付、优惠券活动、积分抽奖、审核流程几乎每一个业务模块都存在逻辑漏洞挖掘空间。它不需要高深的底层知识不需要熟练的代码审计功底核心能力只有两点读懂业务流程 学会抓包篡改参数、打乱业务流程。本文将完整拆解业务逻辑漏洞的底层原理、分类、大量实战场景案例、标准化挖掘方法论、Burp 实操思路、漏洞报告撰写模板、修复加固方案同时讲解 SRC 提交的评分逻辑、新手高频踩坑点与法律红线。读完本文你会建立一套完整的业务逻辑漏洞挖掘思维不再单纯依赖扫描器把挖洞重心从 “扫漏洞” 转向 “测业务”。面向读者SRC 白帽新手、渗透测试工程师、安全服务人员、Web 安全学习者。前置基础掌握 BurpSuite 基础抓包改包理解 HTTP 请求了解基础 Web 漏洞概念。第一章业务逻辑漏洞到底是什么为什么 SRC 评分普遍偏高1.1 业务逻辑漏洞定义业务逻辑漏洞Business Logic Flaw是应用系统业务设计层面的缺陷。开发人员在设计业务流程时预设了正常用户的操作行为但是没有考虑恶意用户会篡改请求参数、打乱业务步骤、并发提交请求导致业务校验被绕过触发业务规则之外的行为。和 SQL 注入、XSS 做对比SQL 注入属于输入解析漏洞恶意输入被数据库引擎执行属于代码层面的安全缺陷扫描器可以自动检测。XSS恶意脚本被页面渲染执行属于输出过滤缺陷WAF、扫描器都能识别。业务逻辑漏洞代码执行没有错误只是业务规则校验缺失。程序严格按照代码执行但是业务规则被绕过。自动化扫描器无法理解业务因此无法发现。举一个最简单例子电商下单。前端页面展示商品价格 999 元提交订单时前端把 price999 传给后端。开发错误地直接信任前端传入的 price 参数后端没有从数据库读取商品真实价格重新计算金额。攻击者抓包把 price 修改为 0.01后端直接生成 0.01 元订单。这个过程没有注入、没有 XSS程序正常运行但是业务规则被破坏这就是典型的支付业务逻辑漏洞。1.2 为什么业务逻辑漏洞在 SRC 更容易拿到高分SRC 平台评定漏洞等级、计算赏金核心看影响范围、危害程度、利用难度三个维度。危害直接很多场景直接关联资金、用户隐私支付篡改、优惠券无限领取、越权查看用户手机号、身份证、订单收货地址这类漏洞直接造成企业资金损失、大批量用户敏感信息泄露。在 SRC 评分体系中资金类、大批量用户数据泄露类漏洞天然属于高危赏金远高于普通 XSS、反射型 URL 跳转这类低危漏洞。而 SQL 注入如果只能读取少量非敏感库很多时候评级仅为中危。自动化工具无法检测存量漏洞多厂商安全建设大部分资源投入到 WAF、漏洞扫描、代码审计重点防御注入、XSS、文件上传。业务逻辑需要理解业务场景扫描器无法读懂业务流程开发、测试人员很容易忽略逻辑校验大量业务系统长期存在逻辑漏洞存量远多于传统 Web 漏洞。利用门槛适中但是修复成本更高很多业务逻辑漏洞只需要 Burp 抓包修改参数、重放请求、并发发包不需要复杂 EXP。但是修复往往需要修改业务底层逻辑、重构业务状态机不是简单增加一个过滤函数就能解决。厂商对这类漏洞重视程度更高评级更高。漏洞复现证据清晰不容易被驳回只要复现步骤完整、截图抓包完整证明业务校验失效审核人员很容易确认漏洞真实存在。对比很多 SQL 注入存在 WAF 拦截、环境差异容易被厂商以无法复现驳回。业务逻辑漏洞只要在授权测试账号复现说服力很强。1.3 业务逻辑漏洞和 OWASP Top10 的关系很多人会疑惑OWASP Top10 里好像没有 “业务逻辑漏洞” 这个独立分类。在新版 OWASP Top10 2025 中业务逻辑漏洞主要归类在A06: 不安全设计Insecure Design同时大量越权场景归类在 A01 访问控制失效。OWASP 专门推出了《OWASP Business Logic Abuse Top10》业务逻辑滥用专项清单专门针对这类扫描器无法发现的业务缺陷。传统 OWASP Top10 更多聚焦代码层面的输入输出漏洞业务逻辑漏洞属于设计层面的安全缺陷是更高维度的安全风险。很多时候业务逻辑漏洞会和访问控制失效、未授权访问重叠但业务逻辑漏洞范围更广包含流程绕过、并发竞争、业务规则滥用等独立场景。1.4 业务逻辑漏洞的核心根源所有逻辑漏洞的底层共性所有业务逻辑漏洞根源基本都属于下面四类之一记住这四点后续所有场景都可以套用过度信任客户端传入的数据价格、数量、用户 ID、订单状态、优惠券 ID 这类业务核心参数由前端提交后端不做数据库二次校验直接使用客户端传来的值。这是最常见的根源。前端页面可以随意篡改绝对不能信任。业务流程缺少状态机校验允许跳过步骤、乱序执行。业务流程设计是 A→B→C但是后端没有记录当前业务状态攻击者可以直接跳过 B直接访问 C 接口完成业务操作。例如不提交订单直接调用支付核销接口。业务限制仅在前端实现后端无校验。前端 JS 限制只能领取 1 次优惠券前端 JS 可以直接绕过后端没有记录领取次数多次请求即可无限领取。原子性缺失并发竞争TOCTOU检查与使用时间差。先查询库存 / 余额再执行扣减操作。两个请求几乎同时到达两次查询都读到充足库存同时执行扣减造成超卖、重复核销优惠券、余额重复使用。第二章业务逻辑漏洞高频分类与实战场景SRC 高分漏洞核心场景本章是全文重点覆盖 SRC 提交最高频、最容易拿到中高危赏金的业务逻辑漏洞场景附带原理、复现思路、危害说明。所有案例均为 SRC 公开历史案例仅用于学习禁止直接在公网业务复现。2.1 越权类漏洞水平越权、垂直越权SRC 出洞之王越权是 SRC 白帽挖到最多的业务逻辑漏洞很多新手的第一笔 SRC 赏金就来自水平越权。越权本质属于访问控制逻辑缺陷后端在查询、修改数据时没有校验这条数据是否属于当前登录用户。水平越权平行越权同权限用户之间互相访问场景描述同等级普通用户 A登录自己账号访问订单查询接口请求参数携带order_id10001查询 A 自己的订单。修改 order_id10002后端没有校验这个订单归属用户直接返回用户 B 的订单详情包含手机号、收货地址、姓名、商品信息。原理后端查询订单时只根据 order_id 查询没有同时带上当前登录用户的 uid 做联合校验。挖掘思路注册两个测试账号 A、B使用 A 账号创建订单抓包拿到查询订单请求包修改 order_id 为 B 账号的订单 ID提交请求如果成功返回 B 的订单数据存在水平越权。危害批量遍历订单 ID可批量获取全站用户手机号、收货地址、个人隐私一般评定高危。常见参数id、order_id、user_id、info_id、log_id、apply_idURL 参数、POST JSON 参数都有可能。拓展场景个人信息越权、收货地址越权、售后申请越权、消息查看越权。很多小程序、APP 接口 JSON 传输 uid直接修改 uid 即可读取别人信息。垂直越权纵向越权低权限用户获取高权限能力场景描述普通用户登录抓包请求中携带roleuser修改参数roleadmin直接访问后台管理接口查询全站用户、修改系统配置或者普通用户直接调用管理员审核接口跳过审核流程直接把自己的申请状态改为审核通过。原理后端权限校验只读取前端传入的 role 参数没有从会话、数据库读取当前用户真实权限。挖掘思路普通账号登录尝试访问后台接口修改请求中的权限参数尝试执行管理员操作。危害拿下后台权限管理全部业务数据一般为严重 / 高危漏洞。区分要点水平越权是同级用户互相看数据垂直越权是普通用户干管理员的操作。2.2 密码重置 / 找回密码逻辑漏洞中高危常客密码重置模块是业务逻辑漏洞的重灾区一旦存在缺陷攻击者可以直接重置任意用户密码接管账号属于 SRC 高分漏洞。高频子场景场景 1验证码可遍历 / 爆破无次数限制用户找回密码输入手机号获取 4 位数字验证码。后端没有限制验证码错误次数验证码有效期过长。攻击者可以批量爆破 4 位数字验证码重置任意手机号账号密码。场景 2验证码直接在响应包返回提交获取验证码请求HTTP 响应包直接返回验证码明文。攻击者不需要接收短信直接读取返回包拿到验证码重置任意用户账号。场景 3手机号参数可篡改验证码和手机号没有绑定核心经典漏洞A 手机号获取验证码然后在重置密码接口把手机号参数修改为 B 的手机号填入 A 收到的验证码后端只校验验证码是否正确没有校验验证码所属手机号成功重置 B 账号密码。原理后端只校验验证码是否存在没有绑定验证码对应的目标手机号验证码和手机号解耦。这是历史上大量 SRC 高分漏洞的经典场景。场景 4重置链接 token 可预测、可遍历密码重置链接形如reset?token123456token 是简单自增数字。攻击者遍历 token即可重置任意用户账号。安全设计中token 应当是高熵随机字符串不可预测。场景 5重置流程可跳过验证步骤直接调用重置密码接口跳过手机号验证步骤直接修改用户密码。2.3 支付、订单、优惠券、积分类漏洞资金类高危天花板SRC 赏金最高资金相关业务逻辑漏洞一旦验证成功绝大多数直接判定高危是 SRC 高分漏洞的代表。这类漏洞的核心根源金额、折扣、商品数量由前端可控后端没有从数据库重新计算校验。场景 1订单金额篡改漏洞下单提交请求请求包携带 price、total_amount 参数前端传入商品价格。攻击者抓包修改价格为 0.01、甚至负数后端直接使用客户端提交金额生成订单完成支付。正确设计前端只传递商品 ID、购买数量后端读取数据库内商品单价在服务器端计算总金额不接受前端传入的价格参数。场景 2负数数量 / 负数金额漏洞后端仅简单判断金额不为空没有校验数值必须大于 0。修改购买数量为负数总金额变成负数平台需要给用户账户返还余额。场景 3优惠券叠加滥用无限叠加、跨品类使用、过期券复用业务规则一个订单只能使用一张优惠券优惠券仅限新用户使用优惠券过期失效。漏洞场景抓包多次提交优惠券参数后端没有校验优惠券是否已经核销允许多张优惠券叠加抵扣或者修改优惠券 ID使用过期优惠券、非本用户的优惠券。场景 4并发竞争漏洞TOCTOU 时间差漏洞超卖、重复核销最经典的并发逻辑漏洞优惠券只能核销一次。逻辑流程请求 1查询优惠券状态未核销请求 2几乎同时查询同样读取到未核销请求 1 执行核销请求 2 也执行核销。同一张优惠券两次并发请求完成两次核销。挖掘方式Burp Intruder 发送并行多请求同时调用核销接口。同类场景库存超卖、余额重复扣减、抽奖次数并发绕过。场景 5退款逻辑漏洞下单支付之后申请退款。业务逻辑退款之后商品权益、虚拟币、积分应该回收。但后端没有同步回收退款成功后用户仍然保留购买的虚拟商品、积分。用户可以无限下单、退款免费获取虚拟资产。这也是大量羊毛事件的底层逻辑。⚠️重要红线测试支付类漏洞绝对不能发起真实支付不能产生真实订单、真实资金交易。仅在厂商 SRC 授权测试环境使用测试账号、测试支付渠道验证。在正式生产环境尝试 0 元购直接触犯法律不属于白帽行为。2.4 短信 / 验证码逻辑漏洞短信轰炸、验证码绕过场景 1短信轰炸接口无频率限制无验证码校验获取短信验证码接口没有 IP 限制、手机号每日次数限制不需要图形验证码即可无限调用。攻击者循环请求接口向目标手机号大量发送短信造成骚扰。一般中危大量手机号可批量触发则升级高危。场景 2验证码前端校验后端不校验前端页面输入验证码前端 JS 校验验证码格式但是提交登录 / 重置接口时后端完全不校验验证码。抓包删除验证码参数直接提交请求登录或者重置密码成功。场景 3验证码一次复用验证成功之后没有失效验证码验证通过之后后端没有立即作废该验证码。攻击者可以重复使用同一个验证码多次提交请求。2.5 活动、抽奖、签到、邀请返利逻辑漏洞这类业务活动是逻辑漏洞高发区平台活动往往短期快速开发安全校验薄弱。签到重复领取前端限制每日签到一次后端没有记录签到状态重放请求无限重复签到刷取积分。抽奖次数绕过每日限定 3 次抽奖前端控制次数后端不限制重复发包无限抽奖。邀请好友奖励绕过活动规则需要真实好友注册校验邀请人、被邀请人关系。抓包修改参数直接调用领取奖励接口跳过好友注册步骤直接领取邀请奖励。抽奖中奖逻辑可预测中奖概率、中奖结果在前端返回攻击者可以修改前端参数强制中奖。2.6 业务流程绕过、状态机缺陷漏洞业务流程是多步骤后端没有记录业务状态允许直接跳过中间步骤。举例申请流程提交申请 → 管理员审核 → 审核通过发放权益。攻击者直接调用 “审核通过” 接口跳过管理员审核直接把自己申请状态改为已通过。订单流程下单 → 支付 → 发货。跳过支付接口直接调用订单发货接口获取商品。实名认证上传身份证 → 人脸核验 → 认证成功。跳过人脸核验接口直接调用认证成功接口完成实名认证。核心原理业务状态只在前端维护后端没有状态机没有校验上一步业务是否完成。2.7 其他小众但高分的业务逻辑漏洞批量注册逻辑漏洞手机号验证码可绕过无限批量注册账号用于刷活动。文件业务网盘 / 文档权限逻辑缺陷修改文档 ID直接查看他人私有文档。接口幂等性缺陷同一笔请求重复提交多次扣款、多次生成订单。积分兑换逻辑积分扣减校验缺陷负数积分兑换、重复兑换。第三章业务逻辑漏洞通用挖掘方法论一套思路测所有业务业务逻辑漏洞挖掘不是随机乱改参数需要一套标准化流程。核心思路先作为正常用户走完完整业务流程梳理业务预期规则然后尝试打破规则打乱步骤、篡改参数、并发请求观察后端是否能正确拦截非法操作。3.1 第一步梳理业务流程画出业务流程图注册 2 个测试账号 A、B非常关键越权测试必须两个账号以普通用户身份完整走一遍业务记录每一步操作、接口、请求参数、业务限制。思考问题这个业务的业务规则是什么平台对用户有哪些限制次数、金额、权限、状态业务步骤顺序是什么A→B→C是否可以跳过 B哪些参数是用户可控的哪些参数应该由服务器保管不应该交给前端数据归属关系这条数据属于 A 账号B 账号是否有权限访问小技巧边操作边抓包保存全部请求包标记每个接口的作用。3.2 第二步参数篡改测试最基础优先测试对每一个请求里的可控参数进行修改测试测试思路清单修改 ID 类参数order_id、user_id、apply_id、doc_id替换为其他账号的 ID测试越权修改数量、金额参数改为 0、负数、超大数字修改状态参数status0 改为 status1未通过改为已通过修改权限参数role、is_admin、is_vip修改业务标识coupon_id、activity_id、product_id删除参数直接删掉某个参数观察接口是否还能正常执行参数替换把 A 的参数替换成 B 的参数。核心判断标准后端是否信任客户端传入的参数有没有在服务端二次校验。3.3 第三步业务流程乱序、跳过步骤测试业务流程是多步骤尝试不按正常顺序调用接口不执行前面步骤直接调用后续接口重复执行同一接口反向执行流程例如已经退款再次调用核销接口。示例正常流程提交申请→审核→发放奖励。直接调用发放奖励接口不提交申请。如果成功存在流程绕过。3.4 第四步重放测试重复请求Burp 抓包正常业务请求直接 Repeater 重放多次。测试是否可以重复领取奖励、重复签到、重复核销优惠券。适用场景签到、领取优惠券、抽奖、提交申请。3.5 第五步并发请求测试竞争条件 TOCTOU使用 Burp Intruder多线程并行发送同一个请求测试并发场景漏洞。适用场景优惠券核销、库存扣减、余额扣减、抽奖、签到。并发测试是很多新手容易忽略的点很多逻辑漏洞只有并发场景才会暴露单次请求无法发现。3.6 第六步边界值测试输入业务规则的边界值测试后端校验逻辑是否严谨。例如优惠券只能领取 1 次尝试领取第 2 次活动仅限新用户尝试老用户调用领取接口时间限制活动修改时间参数在活动开始前 / 结束后调用接口。3.7 业务逻辑漏洞挖掘检查清单直接复制使用每次测试业务模块对照清单逐个验证存在 ID 类参数修改 ID测试水平越权普通账号尝试调用管理员接口修改 role 参数测试垂直越权金额、数量参数尝试 0、负数、超大值优惠券、活动奖励重放请求测试重复领取并发发包测试优惠券核销、库存扣减业务流程是否可以跳过中间步骤直接调用后续接口验证码是否和手机号绑定验证码是否可复用、可爆破前端限制删除前端 JS 限制后端是否仍然校验状态参数 status修改状态测试流程绕过接口是否存在幂等问题重复提交产生重复业务行为手机号、重置 token 是否可遍历预测第四章实操工具与测试技巧BurpSuite 在逻辑漏洞挖掘中的用法业务逻辑漏洞不需要复杂工具核心工具就是 BurpSuite下面讲解对应的模块使用方式。4.1 Proxy 代理抓包浏览器开启代理Burp 捕获全部 HTTP 请求。走完业务流程保存全部请求包识别每个接口的作用、参数。逻辑漏洞挖掘抓包是基础不要只用浏览器前端测试。很多校验逻辑放在后端接口前端看不到。重点关注APP、小程序的 HTTPS 数据包很多小程序业务逻辑漏洞藏在 JSON POST 请求中。4.2 Repeater 重放模块Repeater 用于单次修改参数、重放请求。使用场景修改 order_id测试越权修改 price 金额参数删除参数测试接口是否健壮重放领取奖励请求测试重复领取。操作要点每次修改参数观察响应包返回内容判断业务是否执行成功。4.3 Intruder 并发模块竞争条件漏洞核心工具并发竞争漏洞使用 Intruder 多线程同时发送请求。简单配置思路抓到正常核销优惠券请求包进入 Intruderpayload 设置 Null payload不修改参数原样重复发包线程设置 5~10 并发启动攻击观察返回包看是否多次核销成功。注意并发测试严格控制请求频率禁止对线上业务造成压力SRC 授权测试环境内操作。4.4 扩展小技巧对比两个账号的请求包账号 A、账号 B 执行同一个操作对比请求参数差异寻找用户身份标识。很多时候身份标识放在 Cookie、token而请求参数里的 uid 是前端可控参数。不要只看前端页面返回结果重点看后端接口响应 JSON。很多时候前端页面做了拦截但是后端接口已经执行成功。测试越权优先看返回包内是否返回敏感字段手机号、身份证、地址不要只看页面标题。第五章SRC 业务逻辑漏洞报告怎么写高分报告模板降低驳回概率很多新手挖到漏洞但是报告写得差被厂商审核驳回或者评级压低。业务逻辑漏洞报告重点写清楚业务规则、漏洞成因、详细复现步骤、影响范围、证明证据、修复建议。业务逻辑漏洞报告标准模板漏洞标题简洁清晰位置 漏洞类型 危害。示例XX 商城订单查询接口存在水平越权漏洞可遍历获取用户订单与手机号信息漏洞等级高危漏洞描述XX 商城订单查询接口 /api/order/info后端仅根据 order_id 查询订单数据未校验当前登录用户是否为订单所属用户。攻击者登录普通账号修改请求参数 order_id可遍历查询任意用户订单获取用户姓名、手机号、收货地址等敏感隐私数据。前置条件注册 2 个普通测试账号 A、B。复现步骤使用账号 A 登录创建订单抓包获取订单查询请求包POST /api/order/infoCookie: xxx{“order_id”:“100001”}响应返回账号 A 的订单信息。将请求参数 order_id 修改为账号 B 的订单 ID100002发送请求。后端返回账号 B 完整订单信息包含手机号、收货地址证明越权漏洞存在。影响范围所有用户订单攻击者可批量遍历 order_id获取大量用户隐私。漏洞证明附上请求包截图、响应包截图敏感信息脱敏。修复建议后端查询订单时增加身份校验查询条件同时带上当前登录用户 UID只能查询属于当前用户的订单。增加 ID 遍历频率限制防止批量遍历。敏感信息接口增加权限审计日志记录访问行为。报告撰写要点复现步骤必须一步一步任何人拿到报告都可以复现截图必须脱敏隐藏真实用户手机号只保留漏洞证明部分区分 “业务预期规则” 和 “漏洞行为”告诉审核人员这个业务本应该是什么规则现在被绕过修复建议要具体不要笼统写 “加强校验”给出可落地的后端修复方案不要夸大危害客观描述影响范围夸大危害会被驳回降级。第六章业务逻辑漏洞挖掘新手高频误区 踩坑指南误区 1依赖扫描器认为扫描器扫不到就没有漏洞扫描器只能识别特征化的技术漏洞。业务逻辑漏洞没有固定特征扫描器无法理解业务规则。很多新手每天开扫描器忽略业务手工测试长期无法产出高分漏洞。挖逻辑漏洞核心是人不是工具。误区 2测试越权只改 URL 参数忽略 POST JSON 内的 ID很多接口使用 JSON POST 传递 order_id、user_id很多新手只测试 URL 问号后面的参数漏掉请求体 JSON 内的参数漏掉大量越权漏洞。URL 参数、POST 表单、JSON 请求体全部参数都要测试。误区 3混淆前端校验和后端校验以为前端限制就是安全前端 JS 限制次数、金额前端可以直接绕过。安全校验永远必须放在后端前端所有限制都只是用户体验不能作为安全控制。判断漏洞的标准后端接口是否做校验不是前端页面。误区 4测试支付漏洞直接在生产环境真实下单、真实支付这是致命红线很多新手测试支付逻辑漏洞在正式环境尝试 0 元购产生真实订单直接构成违法犯罪。支付类逻辑漏洞只能在厂商提供的 SRC 测试环境、测试商户、测试支付渠道验证禁止真实资金交易。误区 5挖到越权漏洞直接批量遍历大量真实用户数据验证漏洞只需要使用自己注册的两个测试账号证明漏洞存在即可。批量遍历、导出大量真实用户手机号、个人信息属于非法获取公民个人信息触犯刑法SRC 平台会直接拉黑、追回赏金移交公安。验证漏洞最小化原则最小操作证明漏洞存在不要批量爬取数据。误区 6认为逻辑漏洞只有越权、支付两类很多新手只盯着越权和支付忽略验证码、活动、审核流程、重置密码等场景。活动模块、签到、邀请返利往往开发周期短安全校验薄弱更容易挖到逻辑漏洞竞争更小。误区 7只做单次请求测试忽略并发竞争漏洞很多逻辑漏洞单次请求完全正常只有并发请求才会暴露。例如优惠券重复核销、库存超卖。如果只做单次重放会漏掉这类高分漏洞。误区 8提交漏洞时只写现象不写业务预期规则很多新手报告只写 “修改 order_id 可以看到别人订单”没有说明业务预期用户只能查看自己的订单。审核人员需要理解业务规则缺少业务描述容易被降级。第七章业务逻辑漏洞的通用修复加固方案开发 / 安全测试参考7.1 核心原则永远不要信任客户端输入所有业务核心参数金额、用户 ID、订单 ID、状态、优惠券 ID后端不能直接使用客户端传来的值。后端以数据库存储的真实数据作为唯一可信数据源。商品下单前端只传商品 ID、数量后端查询数据库单价服务器端计算总金额。前端禁止传递 price、total_amount。查询订单后端 SQL 必须同时带上当前登录用户 UIDselect * from order where order_idxxx and uid当前登录用户uid。7.2 引入后端业务状态机管控业务流程业务多步骤流程后端维护业务状态记录当前业务处于哪一步。状态之间的转换必须做合法性校验不允许跳过步骤、乱序执行。用户只能执行当前状态允许的操作。7.3 接口增加幂等控制防止重复提交敏感操作核销优惠券、扣款、提交订单增加幂等 token一次操作一个唯一 token使用之后立即失效防止重复提交、重放攻击。7.4 并发场景使用数据库事务与锁解决 TOCTOU 竞争条件库存扣减、余额扣减、优惠券核销不能简单 “先查询后修改”。使用数据库事务、行锁保证查询和扣减是原子操作避免并发竞争导致超卖、重复核销。7.5 验证码、短信接口加固验证码和目标手机号强绑定验证码存储时同时记录手机号验证时同时校验验证码 手机号。验证码设置有效期验证成功之后立即作废。增加错误次数限制超过次数锁定。短信接口增加 IP、手机号频率限制增加图形验证码 / 人机验证。7.6 权限最小化原则用户只能访问自己拥有权限的数据。所有数据查询、修改接口强制做权限校验。区分普通用户、管理员权限权限标识不能由前端传入权限从服务端会话、数据库读取。7.7 安全测试阶段加入业务逻辑测试常规渗透测试、功能测试除了传统漏洞扫描增加业务逻辑测试用例覆盖流程绕过、参数篡改、并发、越权场景在上线前提前发现逻辑缺陷。第八章业务逻辑漏洞的法律边界白帽必须牢记重中之重业务逻辑漏洞尤其是越权、支付类漏洞很容易触碰法律红线很多白帽就是因为边界把握不当从白帽变成嫌疑人。下面几条规则每次测试前都要重读一遍。只在 SRC 公开授权范围内测试。必须确认厂商公开 SRC 范围只能测试范围内域名、资产。没有公开 SRC 的网站不允许进行任何抓包、参数篡改测试哪怕只是简单改 ID。最小化验证原则。证明漏洞存在使用自己注册的测试账号禁止批量遍历、批量导出真实用户数据。验证越权只需要两个自己注册的账号证明一次即可不要循环遍历大量 ID 抓取用户信息。禁止造成业务损失。支付、优惠券、积分类漏洞禁止在生产环境真实交易、薅取平台资金、消耗平台优惠券预算。只在测试环境验证。发现漏洞后不扩散、不利用、不售卖漏洞。漏洞提交厂商等待修复修复前不对外泄露漏洞细节。一旦测试过程中发现大量用户敏感数据立即停止测试提交漏洞不要下载、保存、转发用户信息。一句话总结你的目标是证明漏洞存在不是利用漏洞、批量获取数据、薅平台资金。超出最小验证的操作就不再属于白帽测试。第九章业务逻辑漏洞实战学习路线新手如何练习很多新手看完理论不知道去哪里练习业务逻辑漏洞没有真实靶场。9.1 靶场推荐PortSwigger Web Security Academy强烈推荐内置大量业务逻辑漏洞靶场包含越权、竞争条件、支付篡改、优惠券逻辑漏洞完全免费专门训练业务逻辑漏洞思维是学习逻辑漏洞最好的靶场。Vulhub部分 Web 应用包含业务逻辑缺陷可以本地搭建练习。注意靶场练习全部本地环境不要拿公网网站练手。9.2 学习顺序掌握 Burp 基础抓包、Repeater在 PortSwigger 靶场逐个完成业务逻辑漏洞实验理解原理学会梳理业务流程练习画业务步骤学习编写 SRC 漏洞报告在 SRC 授权范围内选择中小厂商优先测试活动、找回密码、订单查询等模块尝试挖掘逻辑漏洞。9.3 学习建议不要一开始就盯着大厂核心支付业务。大厂安全建设完善逻辑漏洞较少。优先测试中小厂商的活动模块、小程序、H5 业务这类业务迭代快安全测试薄弱更容易发现业务逻辑漏洞。第十章总结在 SRC 漏洞挖掘领域传统 SQL 注入、XSS 漏洞越来越少扫描器和 WAF 持续拦截这类经典漏洞。业务逻辑漏洞是扫描器无法发现、开发容易忽略、危害巨大、评分更高的一类漏洞也是白帽新手最容易拿到高分赏金的方向。业务逻辑漏洞的本质不是代码注入而是业务设计缺陷过度信任前端数据、缺少后端状态校验、缺少原子事务、业务限制只放在前端。挖掘逻辑漏洞不靠复杂底层技术不靠二进制不靠内网渗透核心是站在攻击者视角打破业务预设规则。很多新手挖洞陷入误区把大量时间消耗在扫描器扫传统漏洞忽略手工业务测试。扫描器只能发现已知特征漏洞业务逻辑漏洞需要人理解业务流程思考业务规则可以如何被绕过。这也是业务逻辑漏洞的魅力它考验的不是工具使用熟练度而是安全思维。但同时必须牢记红线所有测试必须在厂商 SRC 授权范围最小化验证漏洞禁止批量获取用户数据、禁止真实资金薅羊毛。白帽的核心是帮助厂商修复漏洞而不是滥用漏洞。如果你想提升 SRC 挖洞产出不要死磕扫描器把重心转移到业务逻辑测试。注册测试账号完整走完业务流程按照本文的检查清单逐个测试参数篡改、流程绕过、并发重放。你会发现高分漏洞往往藏在业务流程的细节之中。最后网络安全需要学习那些知识网络安全零基础入门学习路线规划初级1、网络安全理论知识2天①了解行业相关背景前景确定发展方向。②学习网络安全相关法律法规。③网络安全运营的概念。④等保简介、等保规定、流程和规范。非常重要2、渗透测试基础一周①渗透测试的流程、分类、标准②信息收集技术主动/被动信息搜集、Nmap工具、Google Hacking③漏洞扫描、漏洞利用、原理利用方法、工具MSF、绕过IDS和反病毒侦察④主机攻防演练MS17-010、MS08-067、MS10-046、MS12-20等3、操作系统基础一周①Windows系统常见功能和命令②Kali Linux系统常见功能和命令③操作系统安全系统入侵排查/系统加固基础4、计算机网络基础一周①计算机网络基础、协议和架构②网络通信原理、OSI模型、数据转发流程③常见协议解析HTTP、TCP/IP、ARP等④网络攻击技术与网络安全防御技术⑤Web漏洞原理与防御主动/被动攻击、DDOS攻击、CVE漏洞复现5、数据库基础操作2天①数据库基础②SQL语言基础③数据库安全加固6、Web渗透1周①HTML、CSS和JavaScript简介②OWASP Top10③Web漏洞扫描工具④Web渗透工具Nmap、BurpSuite、SQLMap、其他菜刀、漏扫等恭喜你如果学到这里你基本可以从事一份网络安全相关的工作比如渗透测试、Web 渗透、安全服务、安全分析等岗位如果等保模块学的好还可以从事等保工程师。薪资区间6k-15k到此为止大概1个月的时间。你已经成为了一名“脚本小子”。那么你还想往下探索吗想要入坑黑客网络安全的朋友给大家准备了一份282G全网最全的网络安全资料包免费领取7、脚本编程初级/中级/高级在网络安全领域。是否具备编程能力是“脚本小子”和真正黑客的本质区别。在实际的渗透测试过程中面对复杂多变的网络环境当常用工具不能满足实际需求的时候往往需要对现有工具进行扩展或者编写符合我们要求的工具、自动化脚本这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中想要高效地使用自制的脚本工具来实现各种目的更是需要拥有编程能力.零基础入门建议选择脚本语言Python/PHP/Go/Java中的一种对常用库进行编程学习 搭建开发环境和选择IDE,PHP环境推荐Wamp和XAMPP IDE强烈推荐Sublime ·Python编程学习学习内容包含语法、正则、文件、 网络、多线程等常用库推荐《Python核心编程》不要看完 ·用Python编写漏洞的exp,然后写一个简单的网络爬虫 ·PHP基本语法学习并书写一个简单的博客系统 熟悉MVC架构并试着学习一个PHP框架或者Python框架 (可选) ·了解Bootstrap的布局或者CSS。8、超级黑客这部分内容对零基础的同学来说还比较遥远就不展开细说了贴一个大概的路线。网络安全工程师企业级学习路线视频配套资料国内外网安书籍、文档工具当然除了有配套的视频同时也为大家整理了各种文档和书籍资料工具并且已经帮大家分好类了。一些我自己买的、其他平台白嫖不到的视频教程要学习网安其实不难难的是坚持和相信自己我的经验是既然已经选定网安你就要相信它相信它能成为你日后进阶的高效渠道这样自己才会更有信念去学习才能在碰到困难的时候坚持下去。机会属于有准备的人这是一个实力的时代。人和人之间的差距不在于智商而在于如何利用业余时间只要你想学习什么时候开始都不晚不要担心这担心那你只需努力剩下的交给时间这份完整版的学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】