OWASP Top 10 漏洞：最关键的 Web 安全风险

FreeGuideOnline 最新 2026-06-13

什么是 OWASP Top 10？

OWASP（开放 Web 应用程序安全项目）是一个非营利组织，致力于提高软件安全性。
其著名的 OWASP Top 10 是一份文档，每 3～4 年更新一次，列出当前最关键的十类 Web 应用安全风险。
它不是法律或标准，而是行业公认的意识和教育工具，帮助开发者、安全工程师和组织理解最常见的攻击面及防护思路。

本教程针对 OWASP Top 10 (2021版)，为初学者逐条拆解每一种风险，提供易于理解的解释、攻击示例和核心防范措施。

A01: 失效的访问控制

访问控制实施“谁可以对什么资源做什么操作”的策略。
失效意味着用户能执行其权限之外的操作，例如：访问他人的数据、修改不该修改的内容或以未授权身份操作。

典型问题

  • 仅隐藏界面按钮，未检查后端权限（前端欺骗）。
  • 通过修改 URL 中的 ID 访问其他用户资源（不安全的直接对象引用，IDOR）。
  • 未正确执行最小权限原则，普通用户拥有管理员权限。
  • 跨域资源共享（CORS）配置错误，导致恶意站点可读取敏感数据。

攻击示例

用户 A 登录银行应用，URL 为 /account/1025。
用户 A 将 URL 手动改为 /account/1026，未做检验的情况下即可看到用户 B 的账户余额。

如何防护

  • 默认拒绝所有访问，仅在明确授权时放行。
  • 对每次请求在后端统一校验权限，不依赖前端控制。
  • 使用随机且不可预测的标识符替代简单连续 ID（但仍要配合权限检查）。
  • 记录并监控访问失败事件。

A02: 加密失败

以前名为“敏感数据暴露”，现在更明确：加密失败表示在需要保护数据机密性和完整性的地方未能正确使用密码学手段。

哪些数据需要保护？

  • 传输中的敏感数据（HTTP 而非 HTTPS）
  • 存储的密码（明文或弱哈希如 MD5）
  • 信用卡号、健康信息、个人身份信息（PII）

常见错误

  • 使用自签证书或过期证书。
  • 数据库中以明文存储密码。
  • 使用已被破解的协议（如 SSLv2、TLS 1.0）或算法（RC4、SHA-1）。
  • 密钥管理不当：硬编码在代码中、上传到公开仓库。

防护措施

  • 对所有流量强制使用 HTTPS（HSTS 头）。
  • 密码使用自适应哈希算法（bcrypt、scrypt、Argon2）加盐存储。
  • 按数据分类采用适当的加密算法和密钥长度（如 AES-256，RSA-2048+）。
  • 不在源代码、配置文件或版本控制中存放密钥；使用密钥管理服务或安全保管库。

A03: 注入

注入攻击发生在外界不可信数据被作为命令或查询的一部分发送到解释器时。
攻击者可通过输入构造恶意载荷，欺骗解释器执行非预期指令。

最常见形式

  • SQL 注入：操控数据库查询来窃取、篡改或删除数据。
  • 命令注入：在 OS 命令中拼接用户输入。
  • LDAP 注入、XML 注入、NoSQL 注入。

攻击示例（SQL 注入）

登录表单查询：

SELECT * FROM users WHERE username = '$user' AND password = '$pass'

若用户输入 admin' --，查询变为：

SELECT * FROM users WHERE username = 'admin' --' AND password = ''

-- 注释掉后续条件，导致无需密码即可登录。

防范策略

  • 始终使用参数化查询（预编译语句），不可拼接输入。
  • 使用对象关系映射（ORM）框架，但要注意其安全用法。
  • 对输入做白名单校验。
  • 对解释器采用最小权限原则，数据库账户不给予 DROP、INSERT 等高权限。
  • 定期使用静态代码分析和渗透测试检测注入点。

A04: 不安全设计

这是一个较新的类别，强调“设计阶段”安全缺失。
不安全设计涵盖：应用架构层面未对安全威胁建模、未考虑安全约束，导致无法通过完美实现来修复。

与实现缺陷的区别

  • 实现缺陷：密码硬编码（可实现安全修复）。
  • 设计缺陷：允许无限制的登录猜解，但日志和限速机制根本没被设计进去。

设计阶段常见问题

  • 未进行威胁建模（STRIDE、攻击树）。
  • 业务逻辑漏洞，如攻击者可越过支付流程直接下载商品。
  • 依序可预测的凭证恢复流程。
  • 先开发后安全，被置于次要位置。

如何构建安全设计

  • 建立安全开发周期（SDLC），需求阶段就定义安全需求。
  • 利用威胁建模提前发现设计缺陷。
  • 避免过度暴露：默认设置统一使用安全配置，不依赖用户去手动加固。
  • 对敏感业务流程实施反滥用限制（如注册频次限制）。

A05: 安全配置错误

应用程序、框架、Web 服务器、数据库、平台等如果未妥善强化，会产生安全隐患。
安全配置错误可以发生在堆栈的任何层级。

常见表现

  • 云存储桶开放公共访问（如 AWS S3 未授权）。
  • 启用了不需要的功能（如目录列表、调试端点、管理控制台）。
  • 默认账户和密码未修改（admin/admin）。
  • 错误消息泄露过多信息（堆栈跟踪、数据库版本）。
  • 未设置安全头（CSP、X-Content-Type-Options 等）。

强化步骤

  • 建立可重复的加固流程，使用配置管理自动化。
  • 移除或不安装不必要的功能、组件、文档和示例。
  • 发送安全指令给客户端：如 HTTP 安全头（Content-Security-Policy, X-Frame-Options）。
  • 使用自动化扫描工具检查配置漂移。
  • 在分离环境中部署应用，配合最小权限。

A06: 易受攻击和过时的组件

现代应用依赖大量第三方和开源组件。
如果使用了包含已知漏洞的版本且未及时更新，应用将直接暴露给攻击者。

受影响的组件

  • 前端和后端库、框架（如 Struts2、jQuery 有漏洞版本）。
  • 容器镜像、操作系统包。
  • 数据库管理系统、反向代理。

风险场景

组件Apache Struts 2（CVE-2017-5638）的 RCE 漏洞曾被用于 Equifax 数据泄露，该组织在补丁发布后未及时修复。

如何管理

  • 持续监控软件清单，使用 SCA（软件组合分析）工具识别已知漏洞。
  • 仅从官方安全的源获取组件，避免使用不受维护的 fork。
  • 及时应用安全补丁并自动化依赖更新（注意测试兼容性）。
  • 制定组件生命周期策略，及时移除不需要的依赖。

A07: 身份识别和身份验证失败

此前称为“身份认证失效”，现在明确包括身份标识、认证及会话管理相关的漏洞。

缺陷示例

  • 允许弱密码（如“123456”）。
  • 暴力破解或撞库无防护（无验证码、账户锁定）。
  • 会话令牌在 URL 中暴露。
  • 注销后或长时间不活动后会话未失效。
  • 多因素认证缺失，尤其是管理后台。

攻击手法

攻击者对登录接口自动化脚本使用常见密码字典。若无任何限制，数小时内可能猜解成功。

防护建议

  • 强制执行强密码策略（最小长度、复杂度，结合已知泄露密码库校验）。
  • 实施多因素认证（MFA）。
  • 限制登录尝试频率，采用账户临时锁定或递增延迟。
  • 使用安全的内置会话管理，如 HttpOnly、Secure 属性的 Cookie，不在 URL 传递会话 ID。
  • 登录后重新生成会话 ID，并在空闲超时后销毁会话。

A08: 软件和数据完整性故障

该类别关注的是在不验证完整性的情况下丢给软件的更新、关键数据和库。
典型的例子包括：不安全的 CI/CD 管道、未签名的固件升级、反序列化不受信数据。

关键场景

  • 不安全的反序列化：攻击者提交恶意序列化对象，远程执行代码。
  • 软件更新无签名：通过中间人攻击篡改更新包安装后门。
  • 包含恶意依赖：攻击者通过依赖混淆将有害包推送到组织内部。

真实案例（SolarWinds）

攻击者入侵构建系统，在合法更新中注入后门。客户信任没验证更新的完整性就直接部署。

如何防范

  • 对软件更新和库使用数字签名或校验和，并验证其来源。
  • 检查依赖的完整性（如使用子资源完整性 SRI 哈希）。
  • 实施序列化数据的安全输入验证，尽量使用纯文本数据格式（JSON）且避免太过灵活的序列化机制。
  • 确保 CI/CD 管道本身安全，有适当的隔离和审批。

A09: 安全日志记录和监控失败

没有充分的日志和监控，攻击者可以在系统中持续活动而不被发现，造成更严重的影响。

不足的表现

  • 登录、高价值事务等事件未被记录。
  • 日志内容模糊、不包含时序或来源详情。
  • 日志存储不安全（可被篡改、删除）。
  • 无实时告警，或有告警但不响应。
  • 未检测到明显的入侵行为，例如大量失败登录。

应记录的信息

  • 认证成功与失败、访问控制决策。
  • 关键业务操作（如转账、删除）。
  • 输入验证失败，如注入攻击尝试。
  • 系统异常和错误。

建立有效的监控

  • 确保日志包含足够的上下文：用户 ID、来源 IP、事件时间、操作目标。
  • 对日志进行中心化收集并防篡改（如只允许追加写入）。
  • 设定已知攻击模式的告警，并建立事件响应流程。
  • 定期进行渗透测试和红队演练检验监控效果。

A10: 服务器端请求伪造（SSRF）

SSRF 指攻击者诱导服务器端应用程序向非预期的目标发起请求。
由于服务器通常位于内网或具有更高的信任级别，攻击者可以探测内部系统、获取元数据或攻击第三方。

攻击如何发生

用户提供一个 URL，应用服务器会获取该 URL 内容并返回（如网页截图功能、文件导入）。
如果未对目标地址做限制，攻击者可传入：

  • http://169.254.169.254/latest/meta-data/ （AWS 元数据，含密钥）
  • http://localhost:8080/admin （内部管理接口）

防护措施

  • 使用白名单允许访问的域名或 IP 范围，并验证输入符合格式。
  • 禁止访问内部地址（127.0.0.0/8, 10.0.0.0/8, 169.254.169.254 等）。
  • 禁用不需要的 URL 方案（如 file://、gopher://、ftp://），仅允许 http/https。
  • 对响应进行过滤，避免将原始回传数据直接返回给前端。
  • 使用网络层出站规则限制服务器访问范围。

将 OWASP Top 10 应用到实际开发中

OWASP Top 10 是起点，而非终点。将安全融入开发流程需采取以下步骤：

  1. 威胁建模：在设计阶段识别每个功能的风险。
  2. 安全编码：遵循安全编码标准，如 OWASP 速查表系列。
  3. 自动测试：在 CI 管道中集成 SAST、DAST 和 SCA 工具。
  4. 持续监控：投入可观测性和攻击检测。

了解这十类风险，团队就能更有针对性地分配安全资源，大幅降低被攻击面。
安全不是一次性任务，而是贯穿应用全生命周期的持续过程。