SQL注入(一)

发布时间:2026/10/3 8:39:40
SQL注入(一) 摘要本文基于 PortSwigger Web Security Academy 官方授权靶场系统梳理了八类 SQL 注入漏洞实验的完整复现过程涵盖 WHERE 子句隐藏数据检索、登录绕过、UNION 攻击确定列数、定位文本列、跨表取数、单列拼接、数据库类型与版本探测以及非 Oracle 数据库元数据枚举等核心场景。每类实验均给出可复现的 Payload 与核心技巧并在文末汇总各攻击手法的原理要点帮助安全学习者理解 SQL 注入的成因、利用思路与防御方向。实验一WHERE条款中允许检索隐藏数据的SQL注入漏洞1.漏洞点应用程序没有对用户输入的 category 参数做安全检查直接把它拼接到了 SQL 语句中。category Gifts这是过滤条件只显示分类为“Gifts礼物”的商品。released 1这是另一个过滤条件1 代表 True即只显示“已发布”的商品。2.构造攻击OR11--拼接到payload里面去是这里的在url里面是表示空格SELECT * FROM products WHERE category Gifts OR 11-- AND released 13.逐步拆解payload:单引号首先注入的单引号闭合了原本 category 后面的那个单引号。这使得 SQL 解析器认为前面的条件结束了。OR或者接着加入 OR 逻辑操作符。11这是一个永远为真True的条件。--注释符这是最关键的一步。在 SQL 中-- 表示后面的内容全部是注释会被数据库引擎忽略掉。那么现在的payload就变成了后面的内容被注释掉了SELECT * FROM products WHERE category Gifts OR 11原本的查询逻辑是“我要找 Gifts 分类 并且 是已发布的产品”。现在由于 11 永远成立查询逻辑变成了“我要找 Gifts 分类的产品 或者 只要 11永远成立的产品”。因为 OR 11 永远为真所以数据库会返回表中的所有产品记录包括那些 released 0未发布的隐藏产品。这样你就成功绕过了系统的过滤机制看到了隐藏数据。4.然后再bp里面抓包修改就解决了这个实验实验二允许登录绕过SQL注入漏洞1.这个实验是关于登录过程的SQL注入问题我们可以直接再登录框内进行注入首先测试是不是用户名这一栏存在漏洞在登录的时候对用户名进行注入administrator--然后密码随便输入就可以解决这个实验。实验三SQL 注入 UNION 攻击确定查询返回的列数1.在测试UNION注入的漏洞的时候需要UNION 前后查询返回结果的列数必须一致我们可以使用NULL进行测试当返回的结果不再是500而是返回200的时候有多少的NULL就表示存在多少列这里我们再Gifts后面加上一个表示的是闭合Gifts闭合之后我们就可以插入一个全新的 UNION SELECT 查询语句。实验四实验SQL注入UNION攻击寻找包含文本的列1.这个实验是在上一个实验的进阶这里需要判断出文本在第几列但是首先我们还是要判断出这个数据表有多少列就和上面的那个实验的步骤是一样的2.先去判断有多少列得到结果是存在三列然后我们就要去判断文本存在第几列3.然后一个一个测试用abc进行测试返回的结果是200就表示测试成功4.然后我们要用的是这个实验规定的那个字符进行测试才能解决这个实验我们查看到右边页面中有一个用单引号包起来的字符就是我们所需要的字符然后把这个字符放到我们测试的abc的位置上再发送一次请求就可以解决这个实验实验五实验SQL注入UNION攻击从其他表检索数据1.这个实验是要我们从users表中得到用户名和密码的信息并用这个信息登录。步骤和上面的实验是一样的我们先判断有多少行和多少列然后判断信息在第几列2.判断出有两列之后去测试信息在第几列两列都存在信息。3.然后我们直接在users表中得到登录密码和用户名4.在右边的窗口中得到信息直接登录解决这个实验实验六SQL注入UNION攻击在单列获取多个值1.这一个实验和之前的不一样这个是单列的数据表如果像我们之前的那样的查找数据的话就会因为列数不匹配报错所以我们需要把两个都要查找的信息拼接起来一起塞入唯一能够查找的那一列中。但是首先的步骤还是和之前的实验是一样的要判断列数以及信息的位置。2.判断信息的位置在第二列并且只有一列存在信息3.用连接符号连接password和username然后一起放到第二列唯一一个能够查询的地方发送请求之后再右边的返回响应里面能够找到用户名和密码。可以是categoryGiftsUNIONSELECTusername||passwordFROMusers--或者是categoryPetsUNIONSELECTNULL,username||~||passwordFROMusers--4.然后用得到的用户名和密码登录就解决了这个实验实验七SQL注入攻击查询MySQL和Microsoft 上的数据库类型和版本1.这个实验的数据库类型是MySQL数据库和Microsoft数据库类型然后要使用的注释符是#然后我们首先还是要去测试有多少列然后信息在第几列2.在这里我们得到了存在两列然后继续判断数据的位置得到信息两列都存在信息3.因为 version 只有 1 个值。如果你写 UNION SELECT version相当于后面只查了 1 列。前面 2 列后面 1 列列数不匹配数据库报错。我们需要一个“占位符”它不需要查出任何有用的数据只要占着位置不报错就行。在 SQL 中NULL 是最好的占位符。它代表“空”兼容任何数据类型不管是数字还是文本列放 NULL 都不会报错。所以 Payload 就必须是 UNION SELECT 值1, 值2其中一个是 version另一个是 NULL。然后这个就会有两种写法我们可以先把version写前面把NULL写后面先去查看返回的结果如果这个没有解决实验的话那就交换位置最后一定是可以解决问题。实验八SQL 注入攻击列出非 Oracle 数据库中的数据库内容1.首先我们在BP的内置的浏览器中打开我们的实验页面然后可以发现有一些搜索的类别这个时候我们打开BP抓包然后随便点击一个类别在proxy页面再把这个请求发送到repeater页面2.然后我们首先要确定查询返回的列数,首先从第一个判断发现返回的是500然后逐个增加直到返回的是2003.然后我们要判断那些列是文本也是从第一个开始判断假设第一个为abc然后查看response的返回的结果然后我们在对这两列进行测试后发现这两个都是文本4.然后我们要去查询数据库中的所有表名去判断我们的用户信息保存在哪一个表中使用payload:GET /filter?categoryPetsUNIONSELECTtable_name,NULLFROMinformation_schema.tables# HTTP/2information_schema.tables 是存放表名的表table_name 是里面的列名。我们把它放在第 1 列第 2 列用 NULL 占位。结果页面上会列出很多表名。你要在里面找可疑的表通常是一个叫 users 或者类似名字的表。5.然后我们找到了一个users_iarxzv查找这里面的信息构造payload:GET /filter?categoryLifestyleUNIONSELECTcolumn_name,NULLFROMinformation_schema.columnsWHEREtable_nameusers_iarxzv-- HTTP/2然后我们可以在右边的响应框里面找到返回的用户名和密码用这个登录即可解决总结WHERE 条款中允许检索隐藏数据Payload: GiftsOR11--核心技巧: 利用 OR 11 逻辑漏洞让原本的过滤条件如 released1失效暴露出隐藏数据。登录绕过 (Login Bypass)Payload: administrator--核心技巧: 闭合单引号用注释符 -- 把后面的密码验证部分直接注释掉实现无密码登录。UNION 攻击确定查询返回的列数Payload: UNIONSELECTNULL,NULL,NULL--核心技巧: 通过不断递增 NULL 的数量测试出前端页面表格的真实列数这是 UNION 注入的前提。UNION 攻击查找包含文本的列Payload: UNIONSELECTabc,NULL--核心技巧: 找出哪些列可以显示字符串为后续显示账号密码做准备。UNION 攻击从其他表获取数据Payload: UNIONSELECTusername,passwordFROMusers--核心技巧: 确定了列数和显示位后直接从目标表users里把数据提取出来。UNION 攻击在单列中检索多个值Payload: UNIONSELECTusername||passwordFROMusers--核心技巧: 当只有 1 列能显示数据时使用拼接符如 ||、、CONCAT()将多个字段拼成一个字符串。查询数据库类型和版本Payload: UNIONSELECTversion,NULL#核心技巧: 获取系统信息并深刻理解了 #MySQL和 --通用注释符的区别和用法。列出非 Oracle 数据库的内容元数据探测Payload:查表名UNIONSELECTtable_name,NULLFROMinformation_schema.tables#查列名UNIONSELECTcolumn_name,NULLFROMinformation_schema.columnsWHEREtable_nameusers_iarxzv--核心技巧: 通过数据库自带的“说明书”information_schema查出真实的随机表名users_iarxzv和列名。声明本文涉及的所有操作均在 PortSwigger Web Security Academy 提供的官方授权实验靶场中进行。该平台明确授权安全学习者在其环境中进行漏洞复现与攻击模拟。本文所展示的技术、思路及代码严禁用于任何未经授权的系统、网络或应用。请勿将文中方法用于非法获取他人数据、破坏系统或侵犯隐私。读者若将本文内容用于非法用途由此产生的一切法律后果与责任由读者自行承担与本文作者无关。本文旨在帮助安全爱好者理解SQL注入的攻击原理。建议读者在理解漏洞成因后重点学习如何修复与防御而非仅关注攻击手法。安全研究始于责任终于守护。