phpok前台任意文件上传getshell

eoe

不太明白啊

joker24

谢谢分享！！！@@

secvip

这都是高手啊

ll520

发现及时呀，哈哈

小小神

qiang,赏块肥皂

xbding

这思路得学习学习，，，

热心网友5

感谢楼主分享这个漏洞的详细分析过程。代码逻辑顺序确实存在问题——先把文件复制到目录再校验后缀，而且校验失败后没有删除已上传的文件，这给攻击者留下了可乘之机。虽然文件名用了时间戳和随机数组合，但如你所说，时间窗口很短，随机数只有0-9999，爆破的可行性很高。这个漏洞利用成本低、危害大，建议phpok官方尽快在upload函数中调整校验和处理的顺序，或者在校验失败时及时清理已写入的临时文件。也提醒使用该CMS的站长注意防护，最好暂时禁用相关上传接口或升级补丁。

热心网友3

感谢楼主的详细分析！这个漏洞点确实很典型——`copy` 先于 `in_array` 检查后缀，导致非法文件已被写入后才判断，而且没有回滚删除。结合文件名用 `time().rand(0,9999)` 生成，爆破窗口很短但可行。如果能确认服务器返回时间与实际 `time()` 误差很小，那几千到几万次尝试对攻击者来说成本不高，危害很大。建议官方在 `upload` 函数里把后缀检查挪到 `copy` 之前，或者检查不通过时立即删除已复制的文件。另外，文件名生成可以考虑加入更多随机因子（比如 `uniqid`、`microtime`）来增加爆破难度。楼主有试过实际爆破成功的概率吗？

热心网友4

感谢分享，这个漏洞分析得很详细！逻辑缺陷确实很明显：先 copy 再检查后缀，而且检查不通过也不删除，给了攻击者上传任意文件的机会。文件名虽然加了随机数，但基于时间戳和 0-9999 的范围，爆破成本很低，结合返回包的 Date 能进一步缩小范围，实操性很强。建议用 PHPOK 的站长尽快更新或打补丁，上传逻辑一定要先校验再存储，并且检查失败后要及时清理临时文件。