第零章零基础入门如果你完全没有安全基础从这里开始读。如果你已有基础可直接跳到第一章。0.1 先搞懂什么是业务逻辑你每天用手机点外卖、网购、转账时背后有一套规则在运行点外卖的流程 1. 选商品 → 2. 加购物车 → 3. 选优惠券 → 4. 支付 → 5. 商家接单 → 6. 发货 ​ 这套流程就是业务逻辑 每个步骤都有规则 - 步骤3一张优惠券只能用一次 - 步骤4支付金额必须等于订单金额 - 步骤5只有支付完成后才能接单业务逻辑漏洞就是这些规则被绕过或利用了。0.2 用生活类比理解逻辑漏洞正常情况你选了一个 100 元的商品用了一张满 100 减 20的券支付 80 元。逻辑漏洞你把价格改成了 0.01 元 → 0.01 元买手机修改价格你把数量改成了 -1 → 系统反而给你退钱负数利用你同时用了 5 张券 → 叠加优惠导致 0 元优惠叠加你没支付就跳到了已完成步骤 → 白嫖跳步你同时发了 10 个订单 → 10 个都用了一张券并发竞态0.3 逻辑漏洞和技术漏洞的区别技术漏洞逻辑漏洞比喻门锁坏了能撬开门没关不用撬就能进检测扫描器能发现需要人工分析Payload有特征script无特征请求合法WAF能拦截不能拦截核心区别逻辑漏洞的请求看起来完全正常没有任何恶意字符。WAF 无法区分正常下单和利用漏洞下单。0.4 你需要的前置知识知识点说明在哪学HTTP 请求GET/POST、参数第 1 篇 0.5 节JSONAPI 数据格式本章 0.5 节前端 vs 后端谁说了算本章 0.6 节数据库数据怎么存第 2 篇0.5 JSON 一分钟速懂现代网站用 JSON 格式传输数据{ item: 手机, price: 2999, quantity: 1, coupon: 满3000减300 }item是参数名手机是参数值2999是数字没有引号用户可以修改这些值用 BurpSuite 拦截0.6 前端 vs 后端一分钟速懂前端浏览器 - 你看到的页面 - JavaScript 代码 - 可以被用户修改按 F12 就能改 ​ 后端服务器 - 处理业务逻辑 - 存储数据 - 不能被用户直接修改 ​ 逻辑漏洞的核心 前端校验了价格 → 后端没再校验 → 攻击者绕过前端直接改价格例子// 前端计算总价 let total price * quantity; fetch(/api/pay, { body: JSON.stringify({total: total}) }); ​ // 攻击者用 BurpSuite 拦截请求把 total 改成 0.01 // 如果后端不重新计算 → 0.01 元买手机0.7 第一次理解逻辑漏洞攻击场景你在网购商品 2999 元。 ​ 正常流程 1. 选商品 → 前端显示 2999 元 2. 点击购买 → 前端把 {price: 2999, quantity: 1} 发给后端 3. 后端收到 → 扣款 2999 元 ​ 逻辑漏洞攻击 1. 选商品 → 前端显示 2999 元 2. 点击购买 → 前端准备发 {price: 2999, quantity: 1} 3. 攻击者用 BurpSuite 拦截 → 改成 {price: 0.01, quantity: 1} 4. 后端收到 → 如果后端信任前端传来的价格 → 扣款 0.01 元 ​ 修复 后端收到 item_id 后自己从数据库查价格 price database.getProductPrice(item_id) // 不信任前端 total price * quantity0.8 零基础练习# 安装 BurpSuite免费版 # 配置浏览器代理 127.0.0.1:8080 # 访问 http://localhost:8080DVWA ​ # 练习1观察正常请求 # 在 DVWA 中修改密码用 BurpSuite 观察请求 ​ # 练习2理解参数 # 观察请求中的参数 # 思考哪些参数是前端可控的 ​ # 练习3修改参数 # 在 BurpSuite Repeater 中修改一个参数 # 观察服务器的响应变化⚠️ 只在本地靶场中练习不要在真实网站上测试。第一章基础铺垫1.1 什么是业务逻辑漏洞业务逻辑漏洞不是代码层面的技术缺陷如注入、XSS而是业务流程设计不合理导致的漏洞。应用功能按设计正常工作但业务逻辑存在可被利用的缺陷。1.2 与技术型漏洞的全面对比技术型漏洞逻辑漏洞产生原因代码缺陷拼接、未编码流程设计不合理检测方式扫描器可发现需要人工分析Payload 特征有script、 OR 11无请求完全合法WAF 防御可拦截难以拦截修复方式编码/参数化重新设计流程自动化测试可自动化需要人工理解业务发现难度中等高需要业务知识1.3 为什么逻辑漏洞难以检测传统漏洞扫描器的工作原理 发送 payload → 检查响应是否包含特征 → 判断是否存在漏洞 ​ 逻辑漏洞 请求完全合法没有恶意字符 响应也完全正常返回正常数据 扫描器无法判断这个操作是否应该被允许 → 需要人工理解业务流程1.4 为什么会产生原因说明示例信任客户端前端校验后端没做价格由前端传给后端状态机不严密状态转换可跳步直接请求已完成步骤缺少并发控制检查和操作非原子性并发领取优惠券边界条件未考虑负数、零、超大数数量为负导致退款只前端校验隐藏入口但 API 可直接调前端隐藏管理员按钮开发视角局限关注能否实现而非能否滥用忘记验证金额不能为负1.5 逻辑漏洞的历史时间事件2010年逻辑漏洞开始受到关注2013年各种支付漏洞被大量披露2017年OWASP 将其归入 Broken Access Control2021年OWASP 新增 A04:Insecure Design2023年API 安全中 BOLA 成为第一大 API 漏洞1.6 常见类型类型典型场景危害支付逻辑修改价格/数量、负数、优惠叠加直接经济损失验证码逻辑可重用、可爆破、返回客户端认证绕过短信轰炸无频率限制骚扰用户密码找回身份绑定不严、状态机漏洞账号接管并发竞态并发领取、并发下单薅羊毛投票/抽奖客户端控制结果公平性破坏限时活动并发绕过限购超量购买越权水平/垂直越权见第7篇数据泄露1.7 危害危害说明真实案例直接经济损失0元购、负数金额各种电商支付漏洞账号接管越权重置密码密码找回逻辑漏洞薅羊毛大量领取优惠券并发领取信息泄露越权查看他人数据IDOR短信轰炸大量短信发送短信轰炸器破坏公平刷票、刷量投票漏洞1.8 必要的前置知识业务流程理解理解电商、金融、社交等场景的业务流程状态机概念理解状态转换的合法性并发编程理解竞态条件HTTP 协议理解请求/响应、参数传递API 测试理解 RESTful API 的调用方式第二章原理剖析2.1 信任边界问题逻辑漏洞的本质是信任了不该信任的来源客户端 → [信任边界] → 服务端 ​ 以下数据都不能信任客户端传来的值 - 价格 → 必须服务端从数据库查 - 数量 → 必须服务端校验范围 - 金额 → 必须服务端计算 - 权限 → 必须服务端 Session 中获取 - 状态 → 必须服务端状态机管理2.2 状态机问题业务流程通常有多个状态每个状态转换需要校验前置状态订单状态created → paid → shipped → completed ↑ 只能向前流转 canceled ← (任意状态可取消)如果状态转换不严密攻击者可以跳步直接从created跳到completed跳过支付回退从shipped回到created重新支付重复多次执行同一状态转换2.3 并发问题竞态条件检查 → 操作非原子性 ​ 线程A: 检查余额(1000) → 通过 → 扣款100 线程B: 检查余额(1000) → 通过 → 扣款100 ← 此时余额还是1000A还没扣完 → 两个线程都通过检查各扣100但只扣了一次覆盖写入TOCTOUTime of Check to Time of Use检查时间和使用时间之间存在窗口攻击者利用这个窗口。2.4 边界条件问题边界问题后果负数数量为负退款/余额增加零数量为零免费获取超大数整数溢出32位溢出变负数超精度0.0000001几乎免费空值空字符串绕过检查数组参数传数组绕过单值检查Unicode全角字符绕过长度检查第三章案例演示3.1 支付逻辑漏洞案例 1修改价格// ❌ 前端计算总价传给后端 fetch(/api/pay, { body: JSON.stringify({item:phone, price:0.01, quantity:1}) });攻击者拦截请求把price改成0.01→ 1分钱买手机。修复# ✅ 后端根据商品 ID 从数据库查价格 product Product.query.get(data[item_id]) price product.price # 从数据库取不信任客户端 quantity data[quantity] ​ # ✅ 校验数量合法 if quantity 0 or quantity 99: return 非法数量, 400 ​ total price * quantity charge_user(current_user, total)案例 2数量为负{item:phone,price:2999,quantity:-1,coupon:满3000减300}2999 × (-1) -2999减 300 → 总价 -3299。攻击者不仅没付钱账户反而增加了 3299 元。案例 3整数溢出amount price * quantity # 如果 price2147483647, quantity2 # 32位整数溢出 → amount 变成负数修复使用大整数类型BigDecimal/Decimal不使用float或 32 位int。案例 4优惠叠加满减券满100减20 折扣券打5折同时使用100 × 0.5 - 20 30甚至可能导致负数。修复明确优惠券互斥规则服务端严格执行。3.2 并发竞态条件案例 5并发领取优惠券count get_claimed_count(user.id) if count 1: # 检查 grant_coupon(user.id) # 操作并发 10 个请求同时通过检查 → 领到多张券。修复数据库唯一约束 事务行锁-- 唯一约束一个用户一个活动只能一张 UNIQUE KEY uk_user_activity (user_id, activity_id)from django.db import transaction ​ transaction.atomic def claim(request): # SELECT ... FOR UPDATE 锁住记录 user User.objects.select_for_update().get(idrequest.user.id) if user.coupon_count 1: return 已领取 Coupon.objects.create(useruser) user.coupon_count 1 user.save()案例 6并发余额扣减# ❌ 先查后改存在竞态 balance get_balance(user) # 查余额 1000 if balance 100: # 检查足够 deduct(user, 100) # 扣款并发时两个线程都查到余额 1000都通过检查各扣 100 → 总共扣 200但可能只扣了 100。修复用原子操作或数据库行锁-- 原子扣减带条件 UPDATE accounts SET balance balance - 100 WHERE user_id ? AND balance 100; -- 检查 affected_rows 13.3 验证码逻辑案例 7短信轰炸$phone $_POST[phone]; sendSMS($phone, $code); // ❌ 无频率限制攻击者用脚本无限调用 → 短信轰炸 消耗企业费用。修复$phone $_POST[phone]; $key sms_limit:{$phone}; ​ // 1. 频率限制60秒内只能发一次 if ($redis-exists($key)) { die(发送过于频繁请稍后再试); } $redis-setex($key, 60, 1); ​ // 2. 每日上限 $daily_key sms_daily:{$phone}: . date(Ymd); if ($redis-incr($daily_key) 10) { die(今日发送次数已达上限); } $redis-expire($daily_key, 86400); ​ // 3. 图形验证码防自动化 if (!verifyCaptcha($_POST[captcha])) { die(验证码错误); } ​ // 4. IP 限制 $ip_key sms_ip: . getIP(); if ($redis-incr($ip_key) 50) { die(请求过于频繁); } $redis-expire($ip_key, 3600); ​ sendSMS($phone, $code);案例 8验证码返回客户端// ❌ 服务端响应中包含验证码 {msg:验证码已发送,debug_code:837421}或验证码藏在 HTTP 响应头中。攻击者直接从响应中获取验证码。修复生产环境绝不返回验证码。案例 9验证码可重用验证成功后不失效 → 重复使用同一个验证码注册多个账号。修复验证成功/失败后立即删除验证码。案例 10验证码可爆破4 位数字验证码无尝试次数限制 → 最多 10000 次可爆破。修复6 位验证码 限制尝试次数5 次失败锁定 30 分钟 验证码有效期 5 分钟。3.4 密码找回逻辑案例 11验证码与手机号未绑定1. 输入自己手机号 → 收到验证码 1234 2. 提交时改手机号为受害者验证码填 1234 3. 后端校验验证码正确 → 但修改了受害者密码根因验证码校验与修改哪个账号未绑定。修复验证码与目标账号一一绑定。案例 12修改返回包绕过1. 输入自己手机号 → 验证成功 2. 后端返回 {success: false, step: 2} 3. 攻击者改成 {success: true, step: 3} 4. 后端信任返回结果 → 进入下一步修复状态由服务端 Session 管理不信任客户端传来的状态参数。案例 13跳步绕过步骤1验证身份校验了权限 步骤2设置新密码没校验 → 攻击者直接请求步骤2修复每一步都检查前置步骤是否完成服务端状态机。3.5 投票/抽奖案例 14客户端控制结果function draw() { let r Math.random(); // ❌ 前端判断概率 if (r 0.999) return iPhone; return 谢谢参与; }攻击者直接调后端领奖接口或修改Math.random。修复抽奖概率由服务端决定结果由服务端生成并记录防重放。3.6 限时活动案例 15并发绕过限购活动限制每人限购 1 次并发提交 10 个订单 → 10 个请求同时通过未购买检查。第四章实战进阶4.1 本地靶场搭建# DVWA 包含部分逻辑漏洞 docker run -d -p 8080:80 vulnerables/web-dvwa ​ # PortSwigger Web Security Academy # https://portswigger.net/web-security/logic-flaws # 有完整的逻辑漏洞实验室 ​ # 自建测试环境 # 创建一个有逻辑漏洞的电商系统4.2 逻辑漏洞挖掘方法论步骤 1理解业务流程图画出完整业务流程在每个环节思考- 这一步校验了什么没校验什么 - 哪些参数客户端可控能否篡改 - 步骤之间状态是否一致 - 有没有并发条件 - 边界条件是否处理负数、零、超大数 - 状态转换是否严密能否跳步步骤 2测试点清单- [ ] 支付价格、数量、币种、优惠叠加 - [ ] 数量/金额负数、零、超大数、整数溢出 - [ ] 验证码返回客户端、可重用、可爆破 - [ ] 优惠券并发领取、重复使用、跨活动使用 - [ ] 密码找回身份绑定、状态机 - [ ] 权限水平/垂直越权 - [ ] 限购并发绕过 - [ ] 投票/抽奖客户端控制结果、防重放步骤 3篡改技巧速查价格 → 0、负数、小数、超精度0.0000001、超大数 数量 → 负数、0、极大溢出 ID → 遍历自增、改 UUID 参数 → 增删字段、改类型数字→数组 流程 → 跳步骤、重复步骤、回退步骤 并发 → 同一请求并发发送4.3 并发测试工具import threading, requests ​ def send_request(): requests.post(url, datadata, cookiescookie) ​ # 并发发送 20 个请求 threads [threading.Thread(targetsend_request) for _ in range(20)] for t in threads: t.start() for t in threads: t.join() ​ # 检查是否重复领取/扣款 # 对比预期结果和实际结果BurpSuite Turbo Intruder更精确的并发测试# BurpSuite → Extensions → Turbo Intruder def queueRequests(target, wordlists): engine RequestEngine( endpointtarget.endpoint, concurrentConnections20, engineEngine.THROTTLE ) for i in range(20): engine.queue(target.req)4.4 综合实战场景 —— 电商全链路攻击选商品 → 用券 → 支付 → 发货每环都可能存在漏洞 ​ 1.【选商品】 修改商品 ID → 越权看到他人购物车 2.【用券】 并发领取 → 多张券跨活动使用 → 逻辑错误 3.【支付】 改价格/数量 → 0元购并发 → 多发 4.【状态】 直接请求已完成接口 → 跳过支付 5.【发货】 越权改收货地址 → 截获他人订单4.5 密码找回全链路攻击1. 输入手机号 → 验证码泄露在响应中 2. 验证码与手机号未绑定 → 越权重置他人密码 3. 跳过身份验证步骤 → 直接设置新密码 4. 修改返回包 → 绕过状态检查 5. 验证码可重用 → 反复利用4.6 逻辑漏洞检测工具# BurpSuite ScannerPro版—— 可检测部分逻辑漏洞 # Autorize —— 越权检测 # Turbo Intruder —— 精确并发测试 # 手动测试 —— 逻辑漏洞主要靠人工分析4.7 逻辑漏洞测试方法论步骤1绘制业务流程图 - 画出完整的业务流程 - 标记每个步骤的输入和校验 ​ 步骤2识别信任边界 - 哪些数据从客户端来 - 这些数据是否在服务端重新校验 ​ 步骤3测试篡改 - 篡改每个客户端可控的参数 - 测试负数、零、超大数 ​ 步骤4测试并发 - 对限量操作进行并发测试 ​ 步骤5测试状态机 - 尝试跳步、回退、重复第五章防御与避险5.1 永不信任客户端# ✅ 服务端计算价格 product Product.query.get(item_id) total product.price * quantity ​ # ❌ 信任客户端 total request.json[price] * request.json[quantity]原则价格、数量、金额、权限、状态——凡是涉及安全与金钱的一律服务端重新计算/校验。5.2 严密的状态机VALID_TRANSITIONS { created: [paid, canceled], paid: [shipped, canceled], shipped: [completed], completed: [], } ​ def transition(order, new_status): if new_status not in VALID_TRANSITIONS.get(order.status, []): raise ValueError(f不能从 {order.status} 转到 {new_status}) order.status new_status order.save()每个状态转换校验前置状态防止跳步、回退。5.3 幂等性设计// 幂等键每个请求携带唯一 requestId if (orderDao.existsByRequestId(requestId)) { return existingOrder; // 已处理过幂等返回 } // 首次处理 createOrder(requestId, ...);重复请求不产生副作用。5.4 并发控制-- 数据库唯一约束 UNIQUE KEY uk_user_activity (user_id, activity_id) ​ -- 乐观锁version 字段 UPDATE orders SET statuspaid, versionversion1 WHERE id? AND version?; -- 检查 affected_rows 1# 分布式锁Redis lock_key fclaim:{user_id}:{activity_id} if not redis.set(lock_key, 1, nxTrue, ex10): return 请勿重复操作 try: claim_coupon(user_id) finally: redis.delete(lock_key)5.5 全面校验数量 0、金额 0、金额上限整数溢出防护用BigDecimal/Decimal不用float异常行为告警短时间内大量请求5.6 安全设计评审上线前做威胁建模把业务流程图当攻击面分析1. 画出业务流程图 2. 标记每个信任边界 3. 对每个跨边界的数据点问如果攻击者篡改这个值 4. 检查所有状态转换是否严密 5. 考虑并发场景 6. 考虑边界条件5.7 防御总结防御层措施效果永不信任客户端服务端重新计算★★★★★状态机严密的状态转换★★★★★幂等性唯一请求 ID★★★★并发控制唯一约束行锁分布式锁★★★★★边界校验负数/零/溢出★★★★安全评审威胁建模★★★★5.8 安全编码 Checklist价格/数量/金额是否服务端计算是否校验了负数、零、超大数状态机是否严密防跳步是否有幂等性设计并发操作是否有锁验证码是否安全不返回客户端、限频、一次性密码找回每步是否校验身份是否做过威胁建模第六章法律合规与避险6.1 合法行为✅ 在本地靶场练习✅ 对自己拥有的系统测试✅ 书面授权范围内的渗透测试✅ 向厂商 SRC 报告逻辑漏洞6.2 违法行为❌ 利用支付漏洞免费购物❌ 并发领取大量优惠券套利❌ 短信轰炸他人手机❌ 越权重置他人密码❌ 利用逻辑漏洞盗刷6.3 涉及法律法律条款说明刑罚刑法第285条非法获取计算机信息系统数据罪三年以下至七年以下刑法第286条破坏计算机信息系统罪五年以下至五年以上刑法第264条盗窃罪利用支付漏洞盗刷视金额定刑治安管理处罚法相关条款短信轰炸拘留/罚款个人信息保护法相关条款非法获取个人信息—6.4 自我保护建议逻辑漏洞测试只在本地靶场中进行发现真实网站逻辑漏洞 → 报告 SRC不自行利用即使是只测试了一下也可能构成违法不要为了验证漏洞而实际下单/转账不传播针对特定网站的逻辑漏洞利用方法大神进阶高级逻辑漏洞技巧与真实案例A.1 真实案例分析案例 1某电商平台 0 元购背景某大型电商平台购物车功能存在支付逻辑漏洞。漏洞链1. 选商品手机 2999 元 2. 用优惠券满 3000 减 300但只买了 2999不满足条件 3. 加一个 1 元的商品凑满 3000→ 优惠后 2700 4. 删除 1 元商品 → 价格变成 2999 - 300 2699 但优惠券仍然生效后端没有重新校验优惠条件 5. 改数量为负数 → 进一步降低价格 6. 最终0.01 元买手机根因修改购物车后后端没有重新校验优惠券的使用条件。修复每次购物车变化时重新计算所有优惠。案例 2某银行并发转账漏洞漏洞链1. 账户余额 1000 元 2. 同时发起 10 个转账请求每个 1000 元 3. 10 个请求同时检查余额都是 1000→ 都通过 4. 10 个请求都执行转账 → 转出了 10000 元 5. 实际只有 1000 元 → 银行损失 9000 元根因检查余额和扣款不是原子操作。修复数据库事务 行锁 原子扣款。案例 3某 App 密码找回漏洞链完整漏洞链1. 输入自己手机号 → 收到验证码 2. 响应 JSON 中包含了验证码开发调试遗留 {msg:已发送,code:1234} ← 验证码泄露 3. 用验证码通过第一步验证 4. 进入设置新密码步骤 5. 修改请求中的手机号为受害者手机号 6. 后端只校验是否验证过不校验验证码与手机号是否匹配 7. 重置了受害者密码 → 接管账号A.2 高级并发竞态技巧TOCTOUTime of Check to Time of Use# 漏洞代码 balance get_balance(user) # 检查时间T1 if balance 100: # 检查 time.sleep(0.1) # 模拟处理延迟 deduct(user, 100) # 使用时间T2 # T1 到 T2 之间的窗口可被利用精确并发利用# Turbo Intruder 精确并发 def queueRequests(target, wordlists): engine RequestEngine( endpointtarget.endpoint, concurrentConnections30, engineEngine.THROTTLE, targetConnections1 ) # 先发一个请求初始化状态 engine.queue(target.req) # 在窗口期内精确并发 for i in range(30): engine.queue(target.req, labelfburst-{i})A.3 状态机绕过技巧正常流程选商品 → 确认 → 支付 → 完成 ​ 绕过方式 1. 直接跳到完成步骤 → 直接请求 /checkout?stepcomplete ​ 2. 回退到确认步骤重新提交 → 在支付完成后回退重新提交不同商品 ​ 3. 重复执行支付步骤 → 重复支付获取积分/返现 ​ 4. 并发执行多个步骤 → 同时提交确认和完成A.4 逻辑漏洞挖掘方法论大神级步骤1全面理解业务 ├─ 绘制完整业务流程图 ├─ 列出所有 API 端点 ├─ 识别所有用户可控参数 └─ 理解每个参数的业务含义 ​ 步骤2信任边界分析 ├─ 哪些参数从前端来 ├─ 后端是否重新校验/计算 ├─ 哪些状态由客户端控制 └─ 哪些操作没有校验前置状态 ​ 步骤3边界条件测试 ├─ 负数、零、超大数 ├─ 超精度0.0000001 ├─ 空值、null、空字符串 ├─ 数组参数传数组 └─ Unicode 全角字符 ​ 步骤4并发测试 ├─ 限量操作并发 ├─ 扣款操作并发 └─ 状态转换并发 ​ 步骤5状态机测试 ├─ 跳步 ├─ 回退 ├─ 重复 └─ 乱序 ​ 步骤6组合测试 ├─ 越权 逻辑漏洞 ├─ SSRF 逻辑漏洞 └─ XSS CSRF 逻辑漏洞A.5 大神级逻辑漏洞 Checklist支付安全 - [ ] 价格是否服务端计算 - [ ] 数量是否校验 0 - [ ] 金额是否校验 0 - [ ] 是否防止整数溢出 - [ ] 优惠券是否防叠加 - [ ] 优惠条件修改后是否重新校验 ​ 状态安全 - [ ] 状态机是否严密 - [ ] 每步是否校验前置状态 - [ ] 是否防止跳步/回退/重复 ​ 并发安全 - [ ] 限量操作是否有锁 - [ ] 扣款是否原子操作 - [ ] 是否有幂等设计 ​ 验证码安全 - [ ] 是否不返回客户端 - [ ] 是否一次性使用 - [ ] 是否限频/限次 - [ ] 是否与目标账号绑定 ​ 密码找回 - [ ] 每步是否校验身份 - [ ] 验证码与账号是否绑定 - [ ] 状态是否由服务端管理系列总结至此Web 安全十大漏洞系列完成篇漏洞本质核心防御01XSS数据被当代码执行按上下文输出编码02SQL 注入代码与数据未分离参数化查询03CSRF浏览器自动携带 CookieCSRF Token SameSite04文件上传校验链薄弱白名单内容校验禁执行05SSRF服务端作为跳板白名单校验真实 IP06命令注入数据拼入命令行用库替代参数数组07越权权限校验缺失服务端强制鉴权08反序列化反序列化触发代码不反序列化不可信数据09XXE解析器加载外部实体禁用 DTD/外部实体10逻辑漏洞流程设计缺陷永不信任客户端状态机纵深防御理念输入校验 → 输出编码 → 权限控制 → 监控告警 → 应急响应理解每个漏洞的本质注入类SQL、命令、XSS 数据被当作代码信任类CSRF、越权、逻辑漏洞 信任了不该信任的来源解析类文件上传、XXE、反序列化 解析器允许了危险操作安全开发最佳实践输入校验白名单、类型检查输出编码按上下文参数化查询所有数据库操作权限控制默认拒绝、服务端强制安全配置关闭调试、最小权限依赖管理及时更新第三方库日志监控记录敏感操作安全测试代码审计 渗透测试安全不是产品是过程。保持学习持续审计共建更安全的 Web。⚠️最终声明本系列所有内容仅供安全学习与防御研究。请在授权环境下测试遵守法律法规。技术本身是中性的使用方式决定了合法与违法。做负责任的安全从业者。