2022年9月，漏洞OWASP发布了最新一版Top 10榜单。漏洞距离上一版2017年，漏洞整整隔了五年。漏洞这五年里Web应用的漏洞技术栈变了不少，攻击者的漏洞手法也在调整，榜单本身的漏洞变化就能说明很多问题。

最直观的漏洞变化是：失效的访问控制（Broken Access Control）从第五位直接蹿升到第一。这不是漏洞小调整。2017年排第一的漏洞注入类漏洞，这次掉到了第三。漏洞访问控制登顶，漏洞说明一个很现实的漏洞问题——大部分应用能防住SQL注入，却防不住用户A看到用户B的漏洞数据。

我见过一个典型案例：某电商平台的漏洞订单查询接口，URL里直接传订单ID。把ID从1001改成1002，就能看到别人的订单，包括收货地址和手机号。开发者觉得“用户不会去改URL”，但攻击者恰恰就靠这个吃饭。这类问题在OWASP的统计里占比高达94%的应用都曾出现过某种形式的访问控制缺陷，这个数字挺吓人的。

加密失败：从“没加密”变成“加错了”

第二位是加密失败（Cryptographic Failures），前身叫“敏感信息泄露”。改名不是玩文字游戏。以前的问题是明文存密码，现在更多是加密方案本身有问题。比如用MD5存密码——加盐了，但盐是硬编码的；或者用ECB模式加密用户数据，相同明文块产生相同密文，攻击者能从中推断出模式。

有个细节值得关注：很多团队用了HTTPS就觉得“加密到位了”，但数据库里的敏感字段还是裸的。一旦数据库被拖库，用户密码、身份证号全部暴露。OWASP这次特意强调“传输中”和“静态”两种状态都要保护，就是在敲打这种半吊子做法。

注入和设计缺陷：老问题的新面孔

注入排第三，不是因为它不重要了，而是因为其他问题变得更突出。SQL注入依然存在，但更多变种出现在NoSQL、LDAP甚至XPath查询里。参数化查询能解决大部分问题，可总有开发者图省事拼字符串。

第四位的不安全设计（Insecure Design）是2022年新增的类别。这个挺有意思——它不是说代码写错了，而是架构阶段就没考虑安全。比如一个找回密码功能，设计成通过回答“你最喜欢的颜色”来重置，这从设计上就注定不安全。再好的代码实现也救不了一个糟糕的设计决策。

配置错误和组件过时：运维层面的坑

安全配置错误排第五。云时代这个问题更严重了——S3存储桶公开可写、Kubernetes dashboard无认证暴露在公网、默认账户没改密码。这些不是代码漏洞，但造成的后果一样严重。我见过一个创业公司，测试环境的数据库直接对公网开放，没有任何认证，里面存着全量用户数据。

第六位是易受攻击和过时的组件。前端npm包、后端jar包、容器基础镜像，任何一个依赖出问题都会牵连整个应用。Log4Shell就是最好的例子——一个日志库的漏洞，影响面覆盖半个互联网。SBOM（软件物料清单）这两年火起来，就是因为大家终于意识到自己根本不知道用了多少第三方代码。

后四位：认证、完整性、日志和SSRF

身份认证失效排第七。撞库、弱密码、会话固定，这些手法依然有效。很多系统允许用户设置“123456”这种密码，登录接口也没有速率限制，攻击者用字典跑一晚上就能拿到一批账户。

软件和数据完整性失效排第八。这个类别关注的是“代码和数据的来源是否可信”。比如从不可信的CDN加载JS脚本、反序列化未验证的数据、CI/CD管道被投毒。SolarWinds事件就是典型的供应链完整性攻击。

安全日志和监控失效排第九。很多团队根本不看日志，或者日志里没有关键事件。攻击者进来待了三个月都没人发现，这种案例在现实中并不少见。

第十位是SSRF（服务端请求伪造）。攻击者让服务器去请求内网资源，绕过防火墙。云环境里SSRF特别危险，因为可以通过元数据接口拿到临时凭证。Capital One那次大规模数据泄露就是SSRF导致的。

整份榜单看下来，一个感受很明显：纯粹的技术漏洞（比如缓冲区溢出）在Web领域越来越少见，更多问题出在逻辑、配置和架构层面。工具能扫出来的东西变少了，需要人动脑子去分析的东西变多了。这对安全从业者来说，要求其实更高了。

(责任编辑：热点)