获取webshell

凌晨两点，我盯着屏幕上那个泛着绿光的输入框，手指悬在键盘上犹豫了三秒。然后敲下了 '; DROP TABLE users; --。页面没有报错，登录框安静地跳转到了后台。就这么进去了。没有暴力破解，没有0day，只是一个连参数过滤都没做的搜索接口。

获取webshell这事儿，多数时候跟黑客技术没太大关系，跟运气和细心关系更大。去年我帮朋友排查一个被篡改的站点，发现攻击者留下的后门文件藏在 /images/ 目录里，文件名是 avatar_2023_thumb.jpg.php。服务器是Windows，IIS默认把分号当参数分隔符，所以这个文件被解析成PHP执行了。就这么个破绽，让攻击者拿到了整台服务器的控制权。

上传点永远是第一突破口。我见过最蠢的案例是某后台只在前端用JS校验了文件后缀，后端啥都没管。把 .jpg 改成 .php.jpg 直接绕过去，然后访问那个文件，webshell就到手了。也有稍微聪明点的，检查了Content-Type，可那玩意儿用Burp改一下请求头就完事。真正难缠的是那种把图片内容也校验一遍的，得用图片马——把PHP代码塞进图片的EXIF信息里，再用文件包含漏洞去触发。

别以为现在都是云主机就安全了。某次渗透测试，目标是个部署在阿里云上的Docker容器。我扫了一圈没找到什么漏洞，正准备放弃，突然注意到响应头里有 X-Powered-By: Express。去翻了翻版本号，好家伙，Express 4.16.0，正好有个已知的路径遍历漏洞。构造个特殊URL，直接读到了容器里的 /etc/passwd。再配合一个弱口令的Redis服务，写了个cron任务反弹shell，容器瞬间沦陷。

最讽刺的是那些自认为安全的开发者。他们用参数化查询防SQL注入，用白名单校验上传文件，觉得万无一失。可往往忽略了个小细节——比如日志文件里的用户输入没过滤，或者备份文件直接放在了web根目录。我见过有管理员把 backup.zip 放在 /wwwroot/ 下，里面是完整的源码加数据库导出。拿到那个压缩包，比什么漏洞都管用。

写webshell本身不难，难的是找到一个能写文件的点。文件上传、SQL注入写文件、命令执行、模板注入，路子多了去了。但真正让我觉得有意思的是思路的转变——别老想着从正面突破，看看那些边边角角。比如某个站点的导出功能，直接把查询结果写入服务器上的CSV文件，文件名参数没过滤。传个 ../../shell.php 进去，内容里带上PHP代码，导出后访问那个路径，shell就到手了。

工具用多了会变懒。菜刀、蚁剑、冰蝎，一键连接，方便是方便，可也让你失去了对细节的感知。我更喜欢手工去写那些简单的payload，哪怕就是一个 system($_GET['cmd']); 的文件，也能让我清楚地知道当前环境是什么状态。有些shell需要免杀，有些需要过WAF，这些都得靠经验积累。

最后说句实在话。获取webshell只是第一步，后面还有提权、横向移动，但拿到shell那一刻的成就感是无可替代的——就像撬开一把锁，看见门后整个房间的瞬间。只是别干坏事，这行当里，进监狱的比成名的多得多。