typecho反序列化漏洞

2018年夏天，序列Typecho 1.1版本被曝出一个反序列化漏洞，化漏编号CVE-2018-18753。序列攻击者构造一个特定的化漏Cookie值，就能在服务器上执行任意代码。序列当时不少个人博客中招，化漏包括我认识的序列一个独立开发者，他的化漏站点被挂上了博彩页面，三天后才发现。序列

问题出在Typecho处理用户Cookie的化漏方式上。具体来说，序列var/Typecho/Cookie.php里的化漏parse方法会先对Cookie做base64解码，然后直接丢给unserialize()。序列PHP的化漏反序列化本身不危险，危险的序列是如果反序列化的数据里带有可控的对象属性，就能触发魔术方法。Typecho里恰好有个Typecho_Request类，它的__get和__call方法能间接调用filter等函数，最终走到call_user_func。整条链子不需要多深的技巧，公开的PoC几行代码就能写完。

我翻过当时的补丁。官方在1.1之后的版本里加了一个签名校验，Cookie内容必须带__typecho_uid和__typecho_authCode，并且序列化数据前拼接了Typecho_Cookie::PREFIX。这个做法不算优雅，但有效——攻击者不知道站点密钥就无法伪造合法Cookie。不过很多老站点没及时升级，直到今天，shodan上还能搜到一些暴露的Typecho安装，版本号停留在1.0或1.1。

漏洞利用的入口通常是install.php或者前台任意触发Cookie解析的页面。有人会问：反序列化不是需要unserialize的输入吗？对，但Typecho的Cookie解析是自动的，每次请求都会走一遍。这意味着不需要登录，不需要交互，一个GET请求带上恶意Cookie就够了。CVSS评分给了9.8，不算夸张。

修复建议其实就一条：升级到1.2或更高版本。如果因为某些原因不能升级，可以手动修改Cookie.php，在unserialize之前加白名单校验，或者干脆用json_decode替代。但后者会破坏兼容性，老会话全部失效。另一个临时方案是在Nginx层拦截包含O:或a:的Cookie值，不过容易误伤正常数据。

我自己的博客跑在Typecho 1.2.1上，后台登录日志里偶尔能看到扫描器留下的痕迹——它们还在尝试构造__typecho_uid=1这类payload。看着那些请求，会觉得这个漏洞像一道旧伤疤，不致命，但提醒你：任何把用户输入直接扔进unserialize的代码，都是在悬崖边跳舞。Typecho的作者后来重写了Cookie机制，算是吸取了教训。可类似的漏洞在其他CMS里依然反复出现，Drupal、Joomla、WordPress插件……反序列化这条攻击路径，从来就没真正冷过。