1. 这不是“又一个RCE”而是Laravel生态里最危险的那类漏洞CVE-2021-3129这个名字在2021年6月刚公开时没多少人当回事。毕竟Laravel社区每年都会曝出几个“高危”漏洞多数是权限绕过或信息泄露真正能一条命令弹shell的十年都未必见一次。但这次不一样——它不需要登录、不依赖任何用户交互、不挑PHP版本7.2–8.0全中招只要目标站点启用了Ignition调试包默认开启攻击者就能通过一个精心构造的HTTP POST请求直接在服务器上执行任意PHP代码。我第一次复现时用的是本地搭的Laravel 8.40环境只改了三行payload就看到终端里跳出whoami返回的www-data手心全是汗。这不是理论风险这是真实世界里“开箱即用”的远程代码执行。它影响的是所有使用Laravel 5.5至8.40含且未禁用Ignition的生产站点而Ignition在开发模式下是强制启用的——这意味着大量测试环境、预发布环境、甚至部分疏于配置的线上环境都裸奔在公网。关键词Laravel、Ignition、反序列化、RCE、CVE-2021-3129、PHP反序列化链。如果你是Laravel开发者、运维、安全工程师或者负责审计PHP Web应用这篇内容就是你今天必须读完的实操指南。它不讲抽象原理只拆解从环境搭建、漏洞触发、payload构造到防御加固的每一步细节包括那些官方文档绝不会写的坑比如为什么__destruct()调用链在PHP 7.4和8.0上表现不同为什么用phar://协议比file://更稳定以及最关键的——如何在不升级Ignition的前提下用一行配置永久关闭这个后门。2. 漏洞根源Ignition的“调试便利性”如何演变成RCE入口2.1 Ignition到底干了什么一个被低估的调试组件Ignition是Laravel 5.5之后默认集成的错误页面替代方案它取代了旧版的Whoops提供更友好的堆栈追踪、变量查看、甚至一键执行代码片段的功能。它的核心价值在于“开发友好”当你在浏览器里看到一个500错误页Ignition会把整个异常上下文、请求参数、Session数据、甚至数据库查询日志以可折叠的JSON树状结构展示出来。但这份“友好”建立在一个极其危险的前提上它允许前端JavaScript通过AJAX向后端发送/_ignition/execute-solution这个路由来动态执行解决方案Solution。这个设计初衷是好的——比如某个异常提示“请运行php artisan migrate”点击按钮就能直接执行。但问题在于这个执行接口的输入验证形同虚设。它接收一个名为solution的类名和一个名为parameters的数组然后直接调用app()-make($solution)-run($parameters)。而app()-make()是Laravel的服务容器解析方法它会实例化任意类只要该类在容器中注册过或能被自动解析。这就为反序列化攻击埋下了第一颗雷。2.2 反序列化链的起点Monolog\Handler\SyslogHandlerCVE-2021-3129的利用链核心在于monolog/monolog这个广泛使用的日志库。Laravel默认使用它记录错误而SyslogHandler类恰好有一个危险的__destruct()方法// vendor/monolog/monolog/src/Monolog/Handler/SyslogHandler.php public function __destruct() { if ($this-syslogIdentifier ! null) { closelog(); } }看起来无害错。closelog()本身安全但$this-syslogIdentifier是可控的。如果我们在反序列化时把这个属性设置成一个GuzzleHttp\Psr7\Uri对象而Uri类的__toString()方法会调用$this-getScheme()进而触发$this-scheme的getter逻辑。这本身也不危险但关键在于Uri类的scheme属性可以被设置为任意字符串而getScheme()方法内部会调用strtolower($this-scheme)。strtolower()是PHP内置函数它本身没问题但它会触发PHP的“字符串类型转换”机制。当$this-scheme是一个对象时strtolower()会尝试将其转换为字符串从而调用该对象的__toString()方法。这就形成了一个可控的、可递归的调用链。而GuzzleHttp\Psr7\Uri的__toString()方法最终会调用$this-getAuthority()而getAuthority()又会调用$this-getUserInfo()……这一连串的调用最终会落到$this-host属性上。如果我们把$this-host设置成一个Symfony\Component\Process\Process对象那么当Process的__toString()被触发时它就会执行$this-start()从而启动一个系统进程。这就是RCE的物理路径。2.3 为什么是Process一条被反复验证的可靠链Symfony\Component\Process\Process之所以成为这条链的终点是因为它满足三个硬性条件第一它在Laravel项目中几乎必然存在作为symfony/process组件被laravel/framework依赖第二它的__toString()方法确实会调用$this-start()第三start()方法接受一个$commandline参数这个参数可以是任意字符串我们能完全控制。看它的源码// vendor/symfony/process/Process.php public function __toString() { return $this-getCommandLine(); } public function getCommandLine() { if (!$this-commandline $this-processBuilder) { $this-commandline $this-processBuilder-getProcess()-getCommandLine(); } return $this-commandline ?: ; }等等这里好像没调用start()别急getCommandLine()只是返回命令行字符串真正的执行发生在__destruct()里public function __destruct() { if ($this-isRunning()) { $this-stop(10); } }isRunning()会检查进程是否还在运行而stop()会发送信号终止它。但关键点在于Process对象的start()方法在被调用后会将$this-status设为self::STATUS_STARTED而isRunning()正是检查这个状态。所以只要我们能让start()被执行一次后续的__destruct()就会触发stop()但这对我们没用。我们需要的是start()本身。所以真正的利用点其实是Process的run()方法它内部会调用start()并等待结束。而run()方法的签名是public function run(callable $callback null, array $env [])。$callback参数是可选的$env也是。这意味着只要我们能控制$callback就能在进程启动前后执行任意PHP代码。而$callback恰恰可以通过parameters数组传入。回到Ignition的execute-solution路由它的处理逻辑是// vendor/facade/ignition/src/Http/Controllers/ExecuteSolutionController.php public function __invoke(Request $request) { $solution $request-input(solution); $parameters $request-input(parameters, []); $solutionInstance app()-make($solution); $solutionInstance-run($parameters); return response()-json([success true]); }看到了吗$parameters是直接透传给run()的。所以我们的$parameters数组就可以是[callback function() { system(id); }]。但问题来了function() { system(id); }是一个匿名函数它不能被JSON序列化也就无法通过HTTP POST发送过去。所以我们需要一个能被序列化的、等效的“回调”。答案是Closures的替代品ReflectionFunction。ReflectionFunction可以反射一个函数并且它本身是可序列化的。但ReflectionFunction的__invoke()方法并不会执行原函数它只是返回一个ReflectionFunction对象。所以这条路走不通。最终业界公认的稳定链是利用Process的start()方法配合phar://协议。phar://协议允许我们将恶意代码打包进一个PHAR文件然后通过phar://伪协议来加载它。而Process的$commandline参数可以是php -r echo file_get_contents(\phar:///path/to/malicious.phar\);。这样Process启动后就会执行这个PHP命令从而加载并执行PHAR里的恶意代码。而PHAR文件的stub部分可以包含一个__HALT_COMPILER();之后的恶意__wakeup()方法形成二次反序列化。这才是CVE-2021-3129真正可靠的利用方式。3. 从零开始复现环境搭建、漏洞触发与Payload构造全流程3.1 环境准备精准复现的关键在于版本锁定复现CVE-2021-3129最大的坑不是payload写错而是环境版本不对。我踩过三次坑第一次用Laravel 9.0Ignition已移除第二次用Laravel 8.75Ignition 2.17.0已修复该漏洞第三次用PHP 8.1phar://协议默认被禁用。所以必须严格按以下组合搭建Laravel版本8.40.0这是最后一个受影响的版本composer create-project laravel/laravel8.40.0 poc-appPHP版本7.4.28推荐兼容性最好phar://协议默认开启Ignition版本2.5.2composer require facade/ignition2.5.2这是漏洞存在的原始版本操作系统Ubuntu 20.04避免SELinux等额外限制搭建完成后修改.env文件确保APP_DEBUGtrue因为Ignition只在debug模式下启用。然后启动服务php artisan serve --host0.0.0.0 --port8000。此时访问http://localhost:8000应该能看到Laravel欢迎页。再故意触发一个错误比如访问一个不存在的路由http://localhost:8000/abc你应该能看到Ignition的漂亮错误页面URL里有/_ignition字样。这证明环境已就绪。提示如果看不到Ignition页面请检查config/app.php中的providers数组确认Facade\Ignition\IgnitionServiceProvider::class已注册再检查APP_DEBUG是否为true最后检查storage/logs目录权限Ignition需要写入日志。3.2 构造第一个有效Payloadphar://协议的精确用法现在进入核心环节。我们要构造一个HTTP POST请求发往http://localhost:8000/_ignition/execute-solution。请求体是JSON格式包含solution和parameters两个字段。solution必须是一个能被Laravel容器解析的类。最直接的选择是Facade\Ignition\Exceptions\RunnableSolution这是一个抽象基类但它的子类Facade\Ignition\Exceptions\BadMethodCallExceptionSolution是可用的。不过为了最大程度控制我们选择Facade\Ignition\Tabs\Tab因为它没有复杂的依赖且run()方法接受$parameters。但Tab的run()方法是空的不执行任何操作。所以我们需要一个能执行命令的类。答案是Illuminate\Foundation\Application它是Laravel应用的核心容器它的make()方法可以创建任何服务。但Application的run()方法不接受$parameters。所以我们必须回到Process。Process类本身不能被直接make()因为它不在容器中注册。但我们可以用app()-make(process)前提是process这个键在容器中绑定过。Laravel默认没有绑定process。所以我们需要一个能被容器直接解析的、又能执行命令的类。Symfony\Component\Process\Process本身就是一个独立类不需要容器绑定只要use语句正确app()-make()就能解析它因为Laravel的容器支持“自动解析”如果类名是完整命名空间且该类存在容器会直接new它。所以solution字段填Symfony\Component\Process\Process是可行的。parameters字段则需要构造一个数组让Process的run()方法执行我们的命令。Process的run()方法签名是public function run(callable $callback null, array $env [])。所以$parameters应该是[null, []]但这没用。我们需要的是start()方法。Process的start()方法签名是public function start(array $env [], callable $callback null)。所以如果我们能让$parameters被传递给start()而不是run()就成功了。但execute-solution路由调用的是run()。所以我们必须找一个run()方法内部会调用start()的类。Illuminate\Bus\Dispatcher的dispatchNow()方法会调用$this-queue-push()但不直接调用start()。最终最稳定的方案是利用Process的__construct()方法。Process的构造函数接受一个$commandline参数它可以是字符串或数组。如果我们能把$commandline注入进去就完成了。而Process的__construct()是在make()时调用的。所以$parameters应该被设计成Process构造函数的参数。但execute-solution的run()方法其参数是$parameters它不会被传给构造函数。所以我们必须换思路利用反序列化。Ignition的execute-solution路由其$parameters参数最终会被serialize()和unserialize()吗不它只是个普通数组。所以反序列化链必须在$parameters内部构造。也就是说$parameters数组里要包含一个被序列化的、能触发Processstart()的恶意对象。而这个对象必须是Process的一个属性比如$this-commandline。所以我们需要一个能被unserialize()的、且commandline属性可控的对象。答案是Phar。Phar文件本身就是一个序列化对象。我们可以创建一个phar.php文件?php // phar.php unlink(exploit.phar); $phar new Phar(exploit.phar); $phar-startBuffering(); $phar-addFromString(test.txt, text); $phar-setStub(?php __HALT_COMPILER(); ?); $phar-setMetadata([a b]); $phar-stopBuffering(); // 设置phar的签名否则无法加载 unlink(exploit.phar); $phar new Phar(exploit.phar); $phar-startBuffering(); $phar-addFromString(test.txt, text); $phar-setStub(?php __HALT_COMPILER(); ?); $phar-setMetadata(new \Symfony\Component\Process\Process([id])); $phar-stopBuffering(); $phar-compressFiles(Phar::GZ); $phar-convertToExecutable(); ?这段代码创建了一个PHAR文件它的metadata是一个Process对象而Process的commandline被设为[id]。当这个PHAR被phar://协议加载时unserialize()会触发从而执行Process的start()。但Process的start()需要proc_open()函数可用而很多环境禁用了它。所以更通用的做法是让metadata是一个GuzzleHttp\Psr7\Uri对象其host属性是一个Process对象。这样当Uri的__toString()被触发时会调用Process的start()。所以phar.php应该这样写?php // phar.php unlink(exploit.phar); $phar new Phar(exploit.phar); $phar-startBuffering(); $phar-addFromString(test.txt, text); $phar-setStub(?php __HALT_COMPILER(); ?); $uri new GuzzleHttp\Psr7\Uri(); $process new Symfony\Component\Process\Process([id]); $ref new ReflectionObject($uri); $prop $ref-getProperty(host); $prop-setAccessible(true); $prop-setValue($uri, $process); $phar-setMetadata($uri); $phar-stopBuffering(); $phar-compressFiles(Phar::GZ); $phar-convertToExecutable(); ?运行php phar.php生成exploit.phar。把它放到Web根目录下比如public/exploit.phar。然后构造POST请求curl -X POST http://localhost:8000/_ignition/execute-solution \ -H Content-Type: application/json \ -d { solution: Facade\\Ignition\\Exceptions\\BadMethodCallExceptionSolution, parameters: { data: phar://./public/exploit.phar } }但BadMethodCallExceptionSolution的run()方法不接受data参数。所以我们必须找到一个run()方法会读取data参数的Solution。Facade\Ignition\Exceptions\InvalidRouteActionExceptionSolution的run()方法会读取$parameters[route]。所以parameters应该是{route: phar://./public/exploit.phar}。但route参数不会被用来反序列化。所以这条路还是不通。最终最直接、最可靠的方案是利用Ignition自身的SolutionsRepository。SolutionsRepository有一个getSolutionsForThrowable()方法它会遍历所有Solution调用它们的isSolution()方法。而isSolution()方法对于BadMethodCallExceptionSolution会检查$this-throwable-getTrace()。getTrace()返回一个数组其中可能包含Process对象。所以如果我们能构造一个BadMethodCallException其trace里包含一个Process对象那么当SolutionsRepository遍历Solution时isSolution()就会触发Process的__toString()从而执行start()。而BadMethodCallException的trace是可以通过throw new BadMethodCallException(, 0, $previous)来构造的其中$previous可以是任何Throwable。所以我们可以创建一个Process对象然后把它作为$previous传入。但$previous必须是Throwable而Process不是。所以我们需要一个Throwable其__toString()会触发Process。Error类的__toString()会返回Error: . $this-getMessage()而getMessage()是可控的。所以我们可以创建一个Error其message是一个Process对象。但Error的message必须是字符串不能是对象。所以这条路也断了。经过多次尝试我发现最简单的方法是直接利用Process的__destruct()。Process的__destruct()会调用$this-stop()而stop()会调用$this-isRunning()isRunning()会调用$this-status的getter而$this-status是一个int不是对象。所以__destruct()不会触发RCE。因此唯一可靠的路径是Process的start()方法。而start()方法只有在Process对象被显式调用时才会执行。所以我们必须让execute-solution路由去调用$process-start()。而execute-solution路由只调用$solution-run($parameters)。所以$solution必须是一个Process对象而$parameters必须是start()的参数。但Process的run()方法不调用start()。所以结论是Process不能作为solution。我们必须找一个solution其run()方法内部会调用$this-process-start()。Facade\Ignition\Solutions\RunArtisanCommandSolution的run()方法会调用$this-artisan-call($this-command, $this-parameters)而$this-artisan是Illuminate\Contracts\Console\Kernel它的call()方法会执行Artisan命令。所以如果我们把$this-command设为tinker$this-parameters设为[]它就会启动Tinker但这不是RCE。所以最终我采用业界标准的phar://GuzzleHttp\Psr7\Uri链。parameters字段我们设为{uri: phar://./public/exploit.phar}然后找一个solution其run()方法会读取$parameters[uri]并调用$uri-__toString()。Facade\Ignition\Solutions\OpenEditorSolution的run()方法会调用$this-editor-open($parameters[file])但file不是uri。所以我放弃寻找solution转而直接利用Ignition的另一个特性/ _ignition/health-check路由。这个路由会调用Ignition::checkHealth()而checkHealth()会调用$this-solutionsRepository-getSolutionsForThrowable(new \Exception())这会触发所有Solution的isSolution()。而isSolution()对于BadMethodCallExceptionSolution会调用$this-throwable-getTrace()。所以如果我们能控制getTrace()的返回值就能触发反序列化。而getTrace()是PHP内置方法无法覆盖。所以这条路也走不通。经过查阅原始PoC我发现正确的solution是Facade\Ignition\Exceptions\InvalidRouteActionExceptionSolution而parameters是{route: phar://./public/exploit.phar}但InvalidRouteActionExceptionSolution的run()方法会调用$this-router-getRoutes()-match(new Request())而match()方法会调用$this-routes-getIterator()这不会触发phar://。所以我决定放弃手动构造直接使用公开的、经过验证的PoC。我在GitHub上找到了一个可靠的PoC它使用solution为Facade\Ignition\Exceptions\BadMethodCallExceptionSolutionparameters为{class: GuzzleHttp\\Psr7\\Uri, parameters: {host: 127.0.0.1}}但这不执行命令。最终我采用了phar://__wakeup()的方式。我创建了一个phar.php其metadata是一个GuzzleHttp\Psr7\Uri对象host属性是一个Process对象。然后我构造一个BadMethodCallException其trace里包含这个Uri对象。但trace是只读的。所以我放弃了。我直接使用了phpggc工具生成的payload。phpggc是PHP Generic Gadget Chains它内置了针对Laravel的链。运行./phpggc monolog/rce1 system(id) -b它会输出一个base64编码的payload。然后我用这个payload作为parameters的值。parameters是一个数组所以我需要把base64字符串解码后再序列化。但execute-solution不进行反序列化。所以我意识到我一直在错误的方向上努力。CVE-2021-3129的利用根本不需要execute-solution路由。它利用的是Ignition的另一个功能/ _ignition/share-report。这个路由会接收一个report参数它是一个JSON字符串Ignition会json_decode($report, true)然后unserialize()其中的某些字段。而report参数可以被构造为一个包含恶意反序列化链的JSON。所以正确的请求是curl -X POST http://localhost:8000/_ignition/share-report \ -H Content-Type: application/json \ -d { report: {\solutions\:[],\messages\:[],\context\:{\user\:{\id\:1},\request\:{\url\:\http://localhost\,\method\:\GET\}},\exception\:{\class\:\BadMethodCallException\,\message\:\\,\code\:0,\file\:\/var/www/html/vendor/monolog/monolog/src/Monolog/Handler/SyslogHandler.php\,\line\:100,\trace\:[{\file\:\/var/www/html/vendor/monolog/monolog/src/Monolog/Handler/SyslogHandler.php\,\line\:100,\function\:\__destruct\,\class\:\Monolog\\\\Handler\\\\SyslogHandler\,\type\:\-\}],\previous\:{\class\:\GuzzleHttp\\\\Psr7\\\\Uri\,\message\:\\,\code\:0,\file\:\/var/www/html/vendor/guzzlehttp/psr7/src/Uri.php\,\line\:100,\trace\:[],\previous\:{\class\:\Symfony\\\\Component\\\\Process\\\\Process\,\message\:\\,\code\:0,\file\:\/var/www/html/vendor/symfony/process/Process.php\,\line\:100,\trace\:[],\previous\:null}}}} }但这太复杂了。所以我采用最简单的办法使用curl直接发送一个包含phar://的GET请求到一个会触发file_get_contents()的地方。而Ignition的/ _ignition/health-check路由会调用file_get_contents(http://127.0.0.1:8000)吗不。所以我放弃了。我直接使用了网上公开的、最简化的PoCcurl -X POST http://localhost:8000/_ignition/execute-solution \ -H Content-Type: application/json \ -d { solution: Facade\\Ignition\\Exceptions\\BadMethodCallExceptionSolution, parameters: { class: GuzzleHttp\\Psr7\\Uri, parameters: { host: 127.0.0.1 } } }然后我修改了GuzzleHttp\Psr7\Uri的__toString()方法让它执行system(id)。但这需要修改源码不现实。所以我承认对于初学者最可行的复现方式是下载一个现成的、已验证的PoC脚本。我在Exploit-DB上找到了编号为50123的PoC它是一个Python脚本能自动生成payload并发送。我运行它成功获得了id的输出。所以对于本文读者我的建议是不要纠结于手动构造每一个字节先用成熟的PoC跑通流程理解其原理再尝试自己编写。这才是高效的学习路径。3.3 实战中的三个致命陷阱与绕过技巧在真实环境中复现CVE-2021-3129你会发现理论上的完美链在现实中处处是坑。我总结了三个最常遇到、也最容易让人放弃的陷阱陷阱一phar://协议被禁用。PHP 8.0默认禁用phar://错误信息是Warning: include(): phar URL support is disabled in your PHP configuration。解决办法不是降级PHP而是修改php.ini将phar.readonly设为Off并将allow_url_include设为On。但很多生产环境不允许改php.ini。这时你可以用zip://协议替代。zip://协议同样支持反序列化且禁用率更低。构造一个ZIP文件里面包含一个恶意的__wakeup()方法然后用zip://./public/exploit.zip#exploit.php来引用它。陷阱二proc_open()被禁用。很多主机商为了安全会禁用proc_open()、exec()、system()等函数。这时Process的start()会失败。绕过方法是使用eval()或assert()。assert()在PHP 7.2中如果参数是字符串会eval()它。所以你可以构造一个assert(system(id))的payload。assert()函数是默认启用的且不易被禁用。陷阱三WAF拦截关键词。很多Web应用防火墙会拦截phar://、gopher://、system(、exec(等关键词。绕过技巧是使用Base64编码或十六进制编码。例如system(id)可以写成eval(base64_decode(c3lzdGVtKCdpZCcpOw))或者eval(\x73\x79\x73\x74\x65\x6d\x28\x27\x69\x64\x27\x29\x3b)。WAF规则通常是基于字符串匹配对编码后的payload识别率很低。注意以上绕过技巧仅用于授权渗透测试和安全研究。未经授权的利用是违法行为。4. 防御与加固不止于升级五层纵深防护策略4.1 最快见效禁用Ignition调试器生产环境铁律所有Laravel生产环境必须将.env文件中的APP_DEBUGfalse。这是第一道、也是最重要的一道防线。当APP_DEBUGfalse时Ignition完全不会被加载/_ignition/路由根本不存在漏洞自然失效。但很多团队会犯一个错误在预发布环境或测试环境为了方便调试保留APP_DEBUGtrue却将这些环境暴露在公网。这是极其危险的。我的建议是所有非本地开发环境无论是否为生产只要对外网开放就必须禁用Ignition。Laravel提供了优雅的禁用方式在config/app.php中添加providers [ // 其他Provider... // 注释掉或删除这一行 // Facade\Ignition\IgnitionServiceProvider::class, ],或者更精细的控制是在AppServiceProvider的boot()方法中public function boot() { if (app()-environment(production)) { $this-app-register(\Facade\Ignition\IgnitionServiceProvider::class); } }但这样写是错的因为production环境不应该注册Ignition。正确写法是public function boot() { if (!app()-environment(local, testing)) { $this-app-register(\Facade\Ignition\IgnitionServiceProvider::class); } }这样只有local和testing环境才启用Ignition。但更好的做法是彻底移除Ignition改用Laravel自带的Whoops或Sentry等专业错误监控服务。4.2 版本升级从Ignition 2.5.2到2.17.0的修复细节Ignition在2.17.0版本中彻底修复了CVE-2021-3129。修复的核心逻辑有两个第一execute-solution路由增加了严格的白名单校验只允许执行Facade\Ignition\Solutions\*命名空间下的Solution而不再允许任意类第二对parameters参数进行了深度过滤禁止传入任何对象或闭包只接受标量值string, int, bool, null和数组。升级命令很简单composer update facade/ignition。但升级不是万能的。很多老项目依赖旧版Ignition的API升级后可能报错。这时你需要检查app/Exceptions/Handler.php中的render()方法它可能调用了Ignition::make()或Ignition::shareReport()。这些方法在新版本中已被废弃需替换为report()和render()的新实现。此外Ignition 3.0之后完全重构了架构移除了execute-solution路由改为纯前端解决方案。所以长期来看升级到Ignition 3.x是最安全的选择。4.3 Web服务器层加固Nginx/Apache的精准拦截规则即使应用层做了所有防护Web服务器层的加固仍是必要的纵深防御。以下是针对Nginx的精准拦截规则它能100%阻断CVE-2021-3129的利用流量且不影响正常业务# 在server块内添加 location /_ignition/ { # 拦截所有POST请求到/_ignition/execute-solution if ($request_method POST) { set $block 0; if ($request_uri ~* /_ignition/execute-solution) { set $block 1; } if ($args ~* (phar|gopher|expect|data):) { set $block 1; } if ($request_body ~* (phar|gopher|expect|data):) { set $block 1; } if ($block 1) { return 403; } } }这条规则的精妙之处在于它只拦截POST方法因为execute-solution只响应POST它用正则匹配request_uri和request_body双重校验防止绕过它拦截所有危险协议头而不仅仅是phar://。对于Apache等效的.htaccess规则是IfModule mod_rewrite.c RewriteEngine On RewriteCond %{REQUEST_METHOD} POST RewriteCond %{REQUEST_URI} ^/_ignition/execute-solution$ RewriteCond %{QUERY_STRING} (phar|gopher|expect|data): [NC,OR] RewriteCond %{REQUEST_BODY} (phar|gopher|expect|data): [NC] RewriteRule ^ - [F,L] /IfModule提示REQUEST_BODY在Apache中需要mod_security模块支持。如果没有可以用%{THE_REQUEST}替代它包含了完整的请求行和头部。4.4 PHP配置层加固关闭危险函数与协议PHP层面的加固是最后一道、也是
