一台服务器上跑着个PHP文件，攻击名字叫`cache.php`，攻击大小只有2KB，攻击混在几百个正常文件里。攻击运维人员扫了一眼目录列表，攻击没发现异常。攻击但这个文件里藏着一行代码：`eval($_POST['cmd']);`。攻击攻击者往这个URL发一个POST请求，攻击参数cmd里写什么，攻击服务器就执行什么。攻击这就是攻击Webshell。

说白了，攻击Webshell就是攻击一段部署在服务器上的恶意脚本，给攻击者提供了一个远程操控的攻击入口。它可以是攻击PHP、ASP、JSP，甚至Python或Node.js写的。形式多种多样，一句话的、加密混淆的、伪装成图片的，五花八门。

这东西的本质是一个后门。攻击者通过漏洞——比如文件上传漏洞、SQL注入写入文件、远程代码执行漏洞——把Webshell丢到目标服务器上。一旦落地，后续操作就简单了：浏览器打开，或者用菜刀、蚁剑、冰蝎这类工具连上去，文件管理、命令执行、数据库操作、内网渗透，想干什么干什么。

它是怎么进来的

最常见的一条路是文件上传。很多网站有上传功能，头像、附件、文档。如果后端校验不严，攻击者把一个`shell.php`改名叫`shell.jpg`上传，再配合服务器解析漏洞或者.htaccess配置问题，这个文件就能被当作PHP执行。我见过一个案例，某电商网站的头像上传只检查了Content-Type，攻击者抓包改成image/jpeg，文件内容原封不动是PHP代码，直接上传成功。服务器上多了一个可执行的Webshell，从上传到连接，前后不到三分钟。

另一条路是漏洞利用。Struts2、ThinkPHP、Spring这些框架出过不少远程代码执行漏洞，攻击者构造一个特制请求，就能让服务器往指定目录写文件。还有SQL注入，如果数据库权限够大，可以通过`INTO OUTFILE`往Web目录写一个Webshell文件。这种手法老但有效，至今仍有站点中招。

为什么难以发现

Webshell的隐蔽性做得很到位。一句话木马本身就几行代码，混在正常文件里肉眼很难辨认。稍微进阶一点的会做编码混淆，比如Base64、Gzip、异或运算，文件内容看起来就是一串乱码。更高级的像冰蝎、哥斯拉这类工具，通信过程全程加密，流量层面看不出明显特征，传统WAF很难拦截。

还有个问题是，Webshell不一定叫`.php`。它可以伪装成`.jpg`、`.ico`、`.txt`，配合服务器配置缺陷照样执行。有些攻击者甚至把Webshell代码写进正常文件的注释里，或者利用PHP的`auto_prepend_file`配置，让正常文件加载时自动引入后门。你翻遍目录也未必找得出来。

怎么防

文件上传的校验必须做严。白名单比黑名单靠谱，只允许特定扩展名，同时检查文件内容头，别只看Content-Type。上传目录禁止执行脚本权限，这是基本操作，但很多站点没做。Web目录的权限也要收紧，PHP进程不该有写文件的权限，至少不该有往Web目录写的权限。

WAF能挡一部分已知的Webshell流量，但别指望它万能。定期做代码审计和文件完整性校验更实在。比如用`find`命令按时间排序查最近修改的文件，或者用`md5sum`比对文件哈希。服务器上突然多出一个几KB的PHP文件，修改时间还是凌晨三点，这本身就够可疑了。

日志也得看。Webshell连接通常有规律性的POST请求，参数名固定，请求体偏大或者包含异常字符。access.log里翻一翻，那些频繁访问同一个陌生文件的IP，值得重点关注。

Webshell不是什​​么高深的技术，但它足够实用，所以一直活跃在攻击链的末端。理解它的运作方式，比背一堆防御规则更有用。