OWASP TOP 10 简述
技术

OWASP TOP 10 简述

简要介绍 OWASP TOP 10

OWASP TOP 10 简述

什么是 OWASP

开放 Web 应用基金会致力于创造一个更安全的网络应用环境。它免费提供文章、工具、技术和论坛，让每个开发人员都能创建安全的代码。其最著名的项目之一是 OWASP Top 10。

什么是 OWASP TOP 10

OWASP Top 10 是根据开放 Web 应用程序安全项目公开共享的 10 个最关键的 Web 应用程序安全漏洞列表。根据 OWASP，漏洞是应用程序中的一个弱点，它允许恶意方对应用程序的利益相关者（所有者、用户等）造成伤害。

OWASP Top 10 列表由全球 Web 应用程序安全专家开发并定期更新。它旨在教育公司了解他们需要缓解以保护其 Web 应用程序的漏洞和关键安全风险。

OWASP TOP 10 名单

2021 年的榜单是继 2007 年以来，“注入”漏洞类型第一次未列榜首。原因在于 web 应用程序变得愈加复杂，而且它们经常是 API 的合集，当结合配置选项时，可引发配置不当、终端不受保护或交互无法预知的情况。

历年 top 10

OWASP TOP 10 介绍

A01:2021 - Broken Access Control（失效的访问控制）

从第五位上升到 Web 应用程序安全风险最严重的类别；提供的数据表明，超过 94% 的 app 都经历过某种形式的越权访问控制测试。对应到失效的访问控制有 34 个 CWE，比任何其它类型在应用中出现的次数都多。

  • 风险描述:

    攻击者可通过修改URL，HTML页面绕过访问控制检查；或目录遍历，目录爬升和回溯进行未授权访问；越权访问（垂直越权、平行越权）敏感资源，冒充用户、管理员或拥有特权的用户，或者创建、访问、更新或删除任何记录。

    对业务的影响取决于应用程序和数据的保护需求。

  • 注：CWE 是什么？

    （Common Weakness Enumeration）是 MITRE 公司（一个非盈利机构）继 CVE（Common Vulnerabilities and Exposures）之后的又一个安全漏洞词典。通过这一词典，Mitre 希望提供识别、减轻、阻止软件缺陷的通用标准。

    CWE 将软件漏洞分为多个类别和子类别，并为每个漏洞提供一个唯一的标识符。CWE 漏洞等级通常由危害程度和攻击难度两个维度进行定义，其中危害程度可以是高、中、低等级。

    例如，CWE-787 越界写入是一种常见的 CWE 漏洞。它是指写入缓冲区的的数据超过了合法的界限，当应用程序在预期输入缓冲区的边界之外写入数据时，就会出现这种安全漏洞。

  • 加固建议

    1. 除了公共资源外，默认禁止访问；
    2. 确保以尽可能少的方式提供给用户、程序或进程访问权限；
    3. 禁止列出 WEB 服务器目录，确保元数据和备份文件不在根目录；
    4. 限制访问 API 的频率，使自动化扫描攻击工具的损害最小化；
    5. token 应该在登出后立刻失效；
    6. 加强引用参数的封装、加密；
    7. 记录所有的访问控制事件。

A02:2021 - Cryptographic Failures（加密失败）

上移一位至第 2 位，以前称为敏感数据暴露（A3: 2017-Sensitive Data Exposure），这是广泛的症状而非根本原因。更新后的名称侧重于与密码学相关的缺陷。此类别通常会导致敏感数据暴露或系统受损。

  • 风险描述:

    由于使用弱加密、未加密、过时的哈希函数（例如 MD5 或 SHA1）、默认加密密钥或重复使用弱加密密钥、缺少二次身份校验，而导致系统泄露敏感信息，造成损失。

  • 加固建议:

    1. 使用随机加密；
    2. 避免使用不安全的加密算法；
    3. 始终使用二次身份验证，而不是只进行加密；
    4. 使用安全协议传输数据；

A03:2021 - Injection（注入）

下滑到第三位。94% 的应用程序针对某种形式的注入进行了测试，最大发生率为 19%，平均发生率为 3.37%，映射到 CWE 有 33 个，在应用程序中出现次数排列第二。跨站点脚本攻击（xss）现在属于此类别的一部分。

  • 风险描述:

    恶意攻击者可通过 SQL 注入漏洞构造 SQL 注入语句，对服务器端返回特定的错误信息来获取有利用价值的信息，甚至可篡改数据库中的内容并进行提权。

  • 加固建议:

    1. 对产生漏洞模块的传入参数进行有效性检测，对传入的参数进行限定；

    2. 当用户输入限定字符时，立刻转向自定义的错误页，不能使用服务器默认的错误输出方式；

    3. 对标签进行危险字符过滤或转义，禁止（’、"、+、%、&、<>、（）、;、and、select 等）特殊字符的传入；

    4. 加密数据库内存储信息；

    5. 与数据库链接并访问数据时，使用参数化查询方式进行链接访问。

A04:2021 - Insecure Design（不安全的设计）

是 2021 年的一个新类别，重点关注与设计缺陷相关的风险。如果我们真的想作为一个行业发展，我们需要更多的威胁建模、安全设计模式和原则以及参考架构。不安全设计不能实现完美修复，因为根据定义，无法创建对应的安全控制来防御特定的攻击。

  • 风险描述:

    由于开发过程中的设计缺陷，可能导致注入、文件上传等漏洞被利用；

  • 加固建议:

    1. 建立并使用安全设计库或安全组件；

    2. 分离系统层和网络层；

    3. 将威胁建模用于关键身份验证、访问控制、业务逻辑和关键数据流；

A05:2021 - Security Misconfiguration（安全配置错误）

从上一版的第 6 位上升；90% 的应用程序都针对某种形式的错误配置进行了测试，平均发生率为 4.5%，超过 208,000 次 CWE 映射到此风险类别。随着更多转向高度可配置的软件，看到这一类别上升也就不足为奇了。XXE（A4 :2017-XML 外部实体）的前一个类别现在属于此风险类别。

  • 风险描述:

    1. 在应用栈中任意一处没有安全加固，云服务器授权没有正确配置；

    2. 非必要的特性被启用或安装；

    3. 使用默认账户和密码；

    4. 异常报错抛出堆栈，或其他包含信息过多的错误消息被泄露给了用户；

    5. 可升级的系统中最新的安全特性没有被启用或正确配置；

    6. 应用服务器、应用框架、数据库中的安全设置没有被设为安全值；

    7. 服务器没有发送安全头或指令，或是没有被正确设置；

  • 预防方法

    1. 使用可重复的加固程序，但使用不同的凭据；

    2. 最小化原则。系统不包含任何非必须的特性，组件，文档，删除或不安装未使用的功能和框架；

    3. 通过分段、容器化或云安全组 (ACL) 在组件或用户之间提供有效且安全的分离；

    4. 向客户端发送安全指令；

    5. 使用自动化进程以验证所有环境中配置的有效性；

A06:2021 - Vulnerable and Outdated（脆弱和过时的组件）

之前的标题是使用已知漏洞的组件（A09: 2017-Using Components with Known Vulnerabilities），在 top10 社区调查中排名第二，并有足够的数据通过数据分析进入 top10。该类别从 2017 年的第 9 位上升，是一个难以测试和评估风险的已知问题。这是唯一没有任何常见漏洞和 CVE 可以对应到已归结 CWE 的主题。因此以默认的利用和影响权重 5.0 计入其评分。

  • 风险描述:

    1. 管理员不知道使用的所有组件的版本，无法及时了解到组件的安全状况；

    2. 使用易受攻击的，不再支持，或是过时的组件。包括 OS, web 服务器，DBMS，APIs 和所有组件，运行环境、库。

    3. 没有周期性扫描漏洞，没有关注所使用组件的安全公告；

    4. 没有及时修复或升级平台，框架，依赖；

    5. 软件开发者没有测试升级，更新，补丁的兼容性。

  • 预防方法

    1. 删除不再使用的依赖，不必须的功能，组件，文件，文档；

    2. 持续记录当前用的组件和依赖的版本。持续关注CVE, NVD上的关于对应组件的漏洞，订阅关于所使用组件的邮件通知。

    3. 仅通过安全链接，从官方来源获取组件。

    4. 关注不再维护的库和组件，如果无法打补丁，考虑部署虚拟补丁。

A07:2021 - Identification and Authentication Failures（身份验证与认证失败）

以前是错误认证（A2: 2017-Broken Authentication），从第 2 位下滑至第 7 位，现在包括与识别失败更多相关的 CWE。有标准化框架可用性增加的帮助，这个类别仍然是 top10 的一个组成部分。

  • 风险描述:

    1. 允许自动化的攻击，如凭据填充（credential stuffing,撞库）攻击；
    2. 允许爆破等攻击；
    3. 允许默认口令，弱密码；
    4. 使用弱或无效的凭据，恢复和忘记密码找回；
    5. 使用明文，加密或弱 hash 的密码；
    6. 使用损坏的或无效的多因子认证；
    7. 在 URL 中暴露会话 ID；
    8. 在成功登录后没有轮换会话 ID；
    9. 没有及时把会话 ID，验证令牌等信息无效化。

A08:2021 – Software and Data Integrity Failures（软体及资料完整性）

  • 弱点简介

    这是 2021 年的新类型，着重在软体更新，关键资料及持续性整合/部署（CI/CD）流程未经完整性验证之假设。同时在 CVE/CVSS 资料加权后之最高影响之一。值得注意的 CWE 包含 CWE-502：不受信任资料之反序列化，CWE-829：包含来自不受信任控制领域之功能及 CWE-494：下载未经完整性验证之程式码。

  • 弱点描述

    程式码或基础架构未能保护软体及资料之完整性受到破坏。举例来说，物件或资料经编码或序列化到一个对攻击者可读写之结构中将导致不安全的反序列化。另一种形式则是应用程式依赖来自于不受信任来源，典藏库及内容递送网路之外挂，函式库或模组。不安全的持续性整合/部署(CI/CD)流程则会造成潜在的未经授权存取，恶意程式码或系统破坏。最后，现在许多应用程式拥有自动更新功能，但自动更新功能在缺乏充足完整性验证功能时就下载并安装更新到处于安全状态下的应用程式。攻击者能上传自制更新档案，更新档案将传播到所有已安装之应用程式并在这些应用程式上执行。

  • 风险描述

    1. 确保不受信任之客户端不会收到未签署或加密之序列化资料并利用完整性检查或数位签章来侦测窜改或重放攻击。

    2. 利用数位签章或类似机制确保软体或资料来自预期之提供者

    3. 确保函式库及从属套件，例如 npm 或 Maven，是从受信任的典藏库取得。

    4. 使用软体供应链安全工具（例如 OWASP Dependency Check 或 OWASP CycloneDX）确保元件没有已知弱点。

    5. 适当地设定持续性整合/部署（CI/CD）流程的组态及存取控制以确保程式码在组建及部署流程中的完整性。

  • 攻击情境范例

  1. 情境 1 不安全的反序列化：一个反应式应用程式呼叫 Spring Boot 微服务。程式设计师们试图确保他们的代码是不可变的。他们的解决方案是在双向所有请求讯息中包含序列化的用户状态。攻击者注意到 “R00” Java 物件签章并使用 Java Serial Killer 工具（用来执行 Java 反序列化攻击）在应用程式服务器远端执行程式码。

  2. 情境 2 未签署之更新：许多家用路由器、机上盒、装置韧体等未以通过签署之韧体验证更新档案。未签署韧体是越来越多攻击者的目标且情况只会变得更糟。这是一个主要问题，因为只能以新版本修复此机制并期待旧版本自然淘汰，没有其他方法。

  3. 情境 3 SolarWinds 恶意更新：众所周知，某些国家会攻击更新机制，最近一次值得注意的是对 SolarWinds Orion 的攻击。该软体开发商拥有安全组建和更新完整性流程。尽管如此，这些流程仍被破坏并在几个月时间中向 18,000 多个组织送出高度针对性的恶意更新，其中大约 100 个组织受到了影响。这是历史上此类性质最深远、最重大的资安事件之一。

A09:2021 – Security Logging and Monitoring Failures（安全记录及监控失效）

之前是日志记录和监控不足（A10:2017 - Insufficient Logging & Monitoring），是从 TOP 10 社区调查(#3)中添加，从之前的 #1 上升。此类别已扩展成为一个包括更多故障类型的主题，难以测试，并且在 CVE/CVSS 数据中没有得到很好的体现。但是，此类故障会直接影响可见（visibility）、事件警报（incident alerting）和取证（forensics）的准确性。

  • 风险描述:
  1. 审计日志记录不足，无法有效定位到操作者；
  2. 警告和错误日志记录不全面、不清晰；
  3. 应用和API关于可疑事件的日志没有被监管；
  4. 日志无备份，仅本地保存；
  5. 日志留存时间较短；
  6. 攻击事件未实时监测或未触发告警。

  • 预防方法

    1. 确保登录、访问控制，服务器验证失败和成功等事件均会被日志记录，同时记录足够多的操作以确定可疑账号与可疑行为；
    2. 保存足够长时间的日志（至少留存6个月）便于分析；
    3. 确保日志的格式，便于阅读与管理；
    4. 对日志进行备份存储；
    5. 建立有效的监管和报警机制，使得可疑活动能被及时检测和处置。

A10:2021 - Server-Side Request（服务器端请求伪造）

直接从Top 10 社区调查 (#1)添加。数据显示，在覆盖率高于平均水平的测试里，该类别发生率相对较低，但利用和潜在影响都高于平均水平。这也正表示了行业专业人士在告诉我们，就算目前数据中没有显示出来，服务器请求伪造还是很重要的事实。

  • 风险描述:

服务端提供了从其他服务器应用获取数据的功能，且没有对目标地址做过滤与限制。

  • 加固建议:

    1. 验证所有客户端提供的数据；
    2. 使用白名单强制执行 URL 架构、端口和目标；
    3. 不向客户端发送原始响应；
    4. 禁用 HTTP 重定向；
    5. URL 一致性，避免 DNS 重新绑定和“检查时间、使用时间”(TOCTOU) 竞争条件等攻击。
Comment