一个php文件，后台名字叫`.shell.php`，后台扔在网站根目录里，后台通过浏览器访问就能执行系统命令——这就是后台后台webshell最朴素的样子。它不依赖什么漏洞利用链，后台不需要复杂的后台内存马技术，只需要一个上传点没做好校验，后台或者某个后台管理员密码是后台`admin123`。

我见过太多这样的后台案例。去年帮一个朋友看他的后台电商站，后台登录页面连验证码都没有，后台密码试了三次就进去了。后台后台有个"商品图片批量上传"功能，后台前端限制了只能选jpg，后台但抓包改一下Content-Type，后台直接传了个php文件上去。整个过程不到五分钟。他问我怎么发现的，我说你后台那个上传接口的URL里带着`upload.php?type=image`，这种命名方式基本就是在喊"来搞我"。

后台webshell和普通webshell的区别在于入口。普通webshell靠SQL注入、文件包含、反序列化这些漏洞点写入，后台webshell则是从管理面板进去的。这意味着攻击者已经拿到了管理员权限，或者至少是某个能上传文件的后台账户。很多开发者觉得"后台都进来了，还在乎webshell吗"——这种想法很危险。后台权限和服务器权限是两码事。后台只能操作数据库里的内容，webshell能读`/etc/passwd`，能连内网数据库，能装挖矿程序。从后台到服务器，webshell就是那座桥。

常见的上传绕过手法就那么几种。改`Content-Type`是最老的，现在很多框架已经修了。文件名后缀黑名单也常见，比如禁了`php`但没禁`phtml`、`php5`、`pht`。还有的用`.htaccess`做解析，传一个`.htaccess`文件写上`AddType application/x-httpd-php .jpg`，再传个jpg马，直接就能跑。Nginx环境下更简单，配置里如果写了`location ~ .php$`，那`1.jpg/1.php`这种路径就能绕过。这些细节在渗透测试报告里经常被一笔带过，但实际利用时每一个都可能是突破口。

后台webshell的隐蔽性比想象中强。一个正常的后台，管理员可能几个月都不看一次文件列表。攻击者把shell命名为`index.php.bak`或者`config.old.php`，放在`uploads/2023/`这种按日期分的目录里，谁能注意到？更狠的是把代码插进已有的正常文件里，比如在`footer.php`末尾加一段`eval($_POST['x'])`。这种叫"不死马"或者"隐写马"，文件本身功能正常，不仔细看代码根本发现不了。

检测后台webshell，光靠D盾、河马这些工具扫特征码不够。我习惯先看上传目录里有没有可执行文件。正常图片目录里出现php、jsp、asp，基本可以确定有问题。再看文件时间，如果几个文件的修改时间集中在凌晨三四点，而网站管理员说他那会儿在睡觉，那就有意思了。还有一个笨办法但很有效：把网站所有php文件拉下来，搜`eval`、`assert`、`system`、`base64_decode`这些函数，看哪些出现在不该出现的地方。后台文件里出现这些，九成有问题。

防御这事，说复杂也复杂，说简单也简单。上传目录禁止执行脚本权限，这是最基本的。后台登录加二次验证，别让密码撞库就进去。文件上传做白名单，只允许jpg、png、gif，并且重命名文件，别用用户传上来的原始文件名。还有一点经常被忽略：后台的session别设太长，管理员登出后session要立即失效。我见过一个站，session有效期设了30天，攻击者拿到cookie后一个月内随便进出后台。

说到底，后台webshell能成立，往往不是技术多高明，而是基础没做好。一个上传点、一个弱密码、一个没关的调试接口，组合起来就是一条完整的攻击路径。技术圈有句话叫"未知攻，焉知防"，但我觉得反过来也成立——知道防的人，往往更清楚攻的软肋在哪。