jsp网站漏洞

我在一次渗透测试里遇到一个老旧的站漏JSP站点，登录框后面是站漏一个用String sql = "SELECT * FROM users WHERE name='" + username + "'"拼出来的查询。我输入' OR '1'='1，站漏回车，站漏后台直接敞开。站漏这不是站漏电影桥段，是站漏真实存在的代码。JSP的站漏漏洞往往不是框架的锅，是站漏写代码的人把信任交给了用户输入。

SQL注入只是站漏开胃菜。JSP页面里最常见的站漏坑是任意文件上传。某个后台的站漏图片上传功能，只检查了Content-Type头，站漏我用Burp改一下，站漏传了个.jsp后缀的站漏webshell上去，服务器直接执行了。你猜怎么着？上传目录居然还有执行权限。这种组合拳，打的就是配置和过滤的双重疏忽。

还有XSS，JSP里用out.println(request.getParameter("msg"))回显用户输入，连个转义都没有。我在搜索框放了个<script>alert(1)</script>，弹窗出现的那一刻，意味着任何访客的Cookie都能被偷走。更狠的是存储型XSS——把恶意脚本存进数据库，管理员一打开后台列表就中招，会话直接劫持。

再说说目录遍历。有的JSP站点用request.getRequestURI()拼文件路径，没有做规范化处理。我试了../WEB-INF/web.xml，居然把配置文件读出来了。里面躺着数据库账号密码，明文。这不算高级漏洞，但杀伤力极大。很多开发者觉得“没人会这么干”，可扫描器不会这么想。

JSP的另一个隐患是表达式语言注入（EL注入）。如果代码里把用户参数直接塞进${ param.action}，攻击者可以构造${ applicationScope}之类的内容，读取上下文变量，甚至调用静态方法。我见过一个案例，攻击者通过EL注入拿到了服务器的环境变量，里面藏着云厂商的密钥。

别忽略反序列化漏洞。老项目爱用Java原生序列化，一旦某个接口接受了ObjectInputStream，攻击者扔一个ysoserial的payload过来，远程命令执行就是一句话的事。我记得有个金融系统，就是因为一个不显眼的readObject()，被拖了库。补丁打了，但代码里还留着几十处类似写法。

这些漏洞的根源，一半是历史遗留，一半是开发习惯。JSP本身不背锅，但它的灵活性和Java生态的庞大，让粗心更容易酿成大祸。写代码时多问一句：“这个参数能信吗？”比事后打补丁强一百倍。

最后说个观察：很多JSP漏洞报告里，修复方式只是加个过滤函数，却没改根本的架构问题。比如参数化查询、白名单校验、最小权限配置——这些才是治本的。可现实中，大家更愿意在漏洞出现的那个点缝缝补补。于是，同一个站点，换个参数名，漏洞又回来了。技术债，就是这么滚雪球滚起来的。