OWASP Top 10 for 2021 学习笔记（上）

最近一直在做的这个逻辑漏洞检测的项目，检测的漏洞类型多数都属于OWASP TOP 10，以后计划做安全开发，有必要学习一下最新的OWASP Top10 漏洞原理与防御技术。

2021年最新版本的相较于2017年版本的变化

最新的OWASP Top 10相较于上一个版本有三个全新的分类，分别是：

• A04：不安全的设计
• A08：软件和数据完整性失效
• A10：SSRF服务器端请求伪造

除此之外还有四个分类做了名称范围修正，并将有些类合并为一个类，如下图所示：

A01 权限控制失效

简述

从2017年的第五名晋升至2021年的第一名，94%的被测试的应用中都有被检测到某种类别权限控制失效的问题。著名的CWE包括：

• CWE-200：向未经授权的行为者泄露敏感信息：产品将敏感信息公开给未明确授权访问该信息的执行组件
• CWE-201：在发送的数据中插入敏感信息：代码将数据传输到另一个执行组件，但部分数据包含该执行组件不应访问的敏感信息
• CWE-352： 跨站点请求伪造：Web 应用程序不会或无法充分验证提交请求的用户是否有意提供格式良好、有效且一致的请求

描述

存取控制强化策略，使用户不能采取在预期权限之外的行动。控制失效通常会导致未经授权的数据泄漏、修改或损坏所有数据，或执行超出用户权限的业务功能。常见的权限控制弱点包括：

• 通过修改 URL、內部应用状态或 HTML 页面，或仅使用自定义 API 攻击工具来绕过存取控制检查。
• 允许主键被更改为其他用户的记录，允许查看或者编辑其他人员的账户。
• 特权提升。未登录用户拥有和登录用户权限，或者以用户身份登录拥有管理员权限。
• 元数据操作，例如重放或者篡改JSON 网站令牌(JWT)来存取控制令牌，或被操纵以提升特权或滥用 JWT 失效的 cookie 或隐藏域内容。
• CORS（跨域资源共享）错误配置允许未经授权的 API 存取。补充CORS是如何工作的：同源策略告诉浏览器阻止跨源请求。当你想从不同的源获取公共资源时，资源提供服务器需要告诉浏览器“请求来自的这个源可以访问我的资源”。浏览器记住这一点并允许跨源资源共享。CORS原理及解决办法
• 以未经身份验证的用户身份强制浏览已验证的页面或以标准用户身份存取特权页面。存取缺少存取控制的 API 以进行 POST、PUT 和 DELETE 操作。

预防方法

存取控制仅在受信任的服务端代码或Serve-less API有效，攻击者无法修改这里的存取控制检查或元数据，比如：

• 除公开资源外，默认为拒绝存取
• 一次性地建置存取控制机制，之后在整个应用中重复使用这些机制，包括最大限度地减少使用CORS。
• 存取控制措施应该强化记录所有权，而不是让用户可以创建、读取、更新或删除任何记录。
• 独特的应用程序业务限制需求应该由域模型（Domain model）强制执行。补充领域模型：领域模型是一个抽象系统，它描述了知识领域、影响力或活动的选定方面。该模型可以用来解决与该领域相关的问题。领域模型是与需要在软件中建模的领域相关的有意义的现实概念的表示。这些概念包括业务涉及的数据以及业务使用的与该数据相关的规则。（来自维基百科）
• 停用 Web 服务器目录列表，并确保档案元数据（例如，.git)和备份档案不在 web 根目录中。
• 记录访问控制失效，并在适当的情况下提醒管理员。
• 对 API 和控制器存取进行流量限制，以最小化自动攻击工具所带来的的损害。
• JWT令牌登出后，在服务器端应该使其失效。

开发人员和QA人员应该包括功能访问控制单元和集成测试。

攻击情景实例

情境 #1： 应用程序在存取账户资料的 SQL 查询中使用未经验证的资料：

pstmt.setString(1, request.getParameter("user"));

ResultSet results = pstmt.executeQuery( );

攻击者只需修改浏览器的“user”参数即可发送他们想要的任何账号。如果没有正确验证，攻击者可以存取任何用户的账户资料。

情境 #2：攻击者强迫浏览某些目标网址，存取管理页面需要管理员权限。

https://example.com/app/getappInfo

https://example.com/app/admin_getappInfo

如果未经身份验证的用户可以访问任一仅能身份验证过用户才能访问页面，那就是一个缺陷。 如果一个非管理员可以访问管理页面，这也是一个缺陷。

A02 加密机制失效

简述

从2017年的第三名变为第二名，之前版本称为“敏感资料泄露”，更像是一种广泛的症状而不是根本原因，本版本聚焦于密码学相关的失效（或者缺乏加密），并因此常常导致敏感资料的泄露。著名的CWE包括：

• CWE-259：使用硬编码密码：软件包含一个硬编码的密码，它将其用于自己的入站身份验证或与外部组件的出站通信。
• CWE-327：使用损坏或有风险的加密算法：使用损坏或有风险的加密算法是危险的，可能导致敏感信息的暴露。
• CWE-331： 熵不足：软件使用的算法或方案产生的熵不足，留下比其他算法或更可能发生的模式或值簇。（某些值产生的随机性太差容易被猜测）

描述

确定资料的传输防护需求，举例来说，密码、银行卡号、健康记录、个人资产以及商业秘密等被隐私保护法保护的信息，对于这些资料需要考虑以下问题：

• 是否以明文形式传输任何数据？需要关注的协议包括HTTP、SMTP、FTP等未加密协议。外部互联网流量是危险的。 验证所有内部流量，例如负载平衡器、Web 服务器或后端系统之间的流量。
• 是否有任何过时的或脆弱的加密演算法被预设使用或存在于较旧的程序代码?
• 是否正在使用默认的加密密钥、是否生成了弱加密密钥并重复使用，是否有适当的密钥管理或轮换?加密密钥是否被写入源代码中？
• 是否强制执行加密？
• 收到的服务器证书和信任链是否正确验证？

预防方法

• 对应用程序处理存储传输的数据进行分类，根据隐私法、法令法规或商业需求辨认哪些为敏感资料，并按照分类结果执行对应的控制措施。
• 非必要不存储敏感性资料，不存储的数据是不会被窃取的。
• 确保静态敏感性资料加密（比如数据库里存储的敏感数据
• 确认使用最新版且标准的强算法、协定及密钥；适当的使用密钥管理（比如采用KMS（Key Management Service）？
• 使用安全协议加密传输中的所有数据，例如具有前向保密 (FS) 密码的 TLS、服务器的密码和安全参数优先。 使用 HTTP 严格传输安全 (HSTS) 等指令强制加密。（HSTS 是 HTTP 严格传输安全（HTTP Strict Transport Security） 的缩写。 这是一种网站用来声明他们只能使用安全连接（HTTPS）访问的方法。 如果一个网站声明了 HSTS 策略，浏览器必须拒绝所有的 HTTP 连接并阻止用户接受不安全的 SSL 证书。 目前大多数主流浏览器都支持 HSTS）
• 包含敏感数据的响应应当禁止缓存。
• 使用具有散列/延迟因素(work factor/delay factor)，如 Argon2, scrypt, bcrypt 或 PBKDF2 的强自适应加盐散列函数来存储密码。
• 独立验证配置和设置的有效性。

攻击情景实例

情境 #1: 有一个应用程序使用自动化资料库加密来加密资料库中的信用卡卡号，但是资料被检索时是被自动解密的，进而允许通过 SQL 注入缺陷来检索信用卡卡号明文。

情境 #2: 有一个平台没有对所有页面强制使用 TLS ，攻击者监控网络流量(如在不安全的无线网络), 将连线从 HTTPS 降级成 HTTP，并拦截请求窃取使用者的会话(session) cookies，之后攻击者重送窃取到的会话(session) cookies 并劫持用户(认证过的)的会话，进而检索或修改使用者的隐私资料。 除了上述以外，攻击者也能修改传输的数据，如汇款收款人。

情境 #3: 密码资料库使用未加盐或简单的散列函数来储存每个人的密码，一个档案上传的缺陷可以让攻击者存取密码资料库，所有未被加盐的哈希可以被预先计算好的彩虹表解密。即使加盐，由简单或快速的哈希仍能被 GPU 破解。

A03 注入式攻击

简述

注入式攻击下滑到了第三名，94%的被测应用程序都有检测到某种类型的注入式攻击问题。著名的CWE包括：

• CWE-79：网页生成期间输入的不当中和（“跨站点脚本”）)：应用不会抵消或错误的抵消用户可控的输入，然后将其放入输出中，该输出用作提供给其他用户的网页。
• CWE-89：SQL 命令中使用的特殊元素的不当中和（“SQL 注入”）：如果不在用户可控制的输入中充分删除或引用 SQL 语法，生成的 SQL 查询可能会导致这些输入被解释为 SQL 而不是普通用户数据。这可用于更改查询逻辑以绕过安全检查，或插入修改后端数据库的其他语句，可能包括执行系统命令。
• CWE-73：文件名或路径的外部控制：软件允许用户输入来控制或影响文件系统操作中使用的路径或文件名。

描述

应用程序在以下情况下容易遭受攻击：

• 应用程序未验证、过滤或者清理使用者提供的资料。
• 在解释器中未使用上下文感知转义的动态查询或者无参数调用
• 在对象关系映射（ORM）的搜索参数中使用恶意的数据来提取额外的敏感数据。
• 恶意数据被直接使用或者连接，SQL语句或者命令包含动态查询、命令或存储过程中的结构和恶意数据。

一些常见的注入式攻击是 SQL、NoSQL、OS 指令、对象关系映射 (ORM)、LDAP 以及表达式语言 (EL) 或对象导航图语言 (OGNL) 注入。这个概念在所有的解释器都是相同的。假若应用程式存在注入式攻击的弱点，源码检测是最好的方式。强烈建议对所有输入的参数、标头、URL、cookies、JSON、SOAP（简单对象访问协议） 以及 XML 的数据进行自动化测试。组织可以将静态源码测试 (SAST) 以及动态应用程序检测 (DAST) 工具，包含到持续整合与持续部署 (CI/CD)管道中，以达成在上线部署前能识别注入攻击的缺陷。

预防方法

• 将命令与查询数据分离，防止注入式攻击。
• 使用安全的API，避免使用解释器，以提供参数化界面或整合到对象关系映射工具中
• 使用白名单在服务器端验证输入的数据。
• 对于任何剩余的动态查询，在转译中使用特殊符号进行查询，给查询语法带来不同的含义。注意：表名等无法被转义，因此使用者提供数据结构名称是危险操作
• 在查询中使用 LIMIT 以及其它的 SQL 控制器，可以防止当遭受 SQL 注入式攻击时被大量泄露纪录。

攻击情景实例

情境 #1: 应用程序在脆弱的 SQL 调用中使用了不被信任的数据：

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

情境 #2: 类似地，应用程序对框架的盲目信任，可能导致仍然在漏洞的查询，(例如：Hibernate 查询语言 (HQL))：

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

在这两个情境中，攻击者在他们的浏览器修改了 “id” 参数值，送出 ‘ or ‘1’=’1，例如：

http://example.com/app/accountView?id=' or ‘1’=’1

这两个查询的含义将产生改变，而响应所有帐户数据表中的记录，更危险的攻击将可能修改或删除数据。

A04 不安全的设计

简述

2021年中全新的一个类别，着重于在设计和架构中的风险。呼吁使用更多的威胁建模、安全设计模式与参考架构。著名的CWE包括：

• CWE-209：生成包含敏感信息的错误消息：软件会生成一条错误消息，其中包含有关其环境、用户或关联数据的敏感信息。
• CWE-256：密码的纯文本存储：当密码以纯文本形式存储在应用程序的属性、配置文件或内存中时，会出现密码管理问题。通过在配置文件中存储纯文本密码，可以读取该文件的任何人都可以访问受密码保护的资源。在某些情况下，如果在使用密码后未立即清除密码，则即使在内存中存储纯文本密码也被视为安全风险。
• CWE-501： 信任边界违规：可以将信任边界视为通过程序绘制的线。在这条线的一侧，数据是不可信的。在线路的另一端，假定数据是可信的。验证逻辑的目的是允许数据安全地跨越信任边界 - 从不受信任的移动到受信任的。当程序模糊了受信任内容和不受信任的内容之间的界限时，就会发生信任边界冲突。通过将可信和不受信任的数据合并到同一数据结构中，程序员更容易错误地信任未经验证的数据。
• CWE-522：凭据保护不足：产品传输或存储身份验证凭据，但它使用不安全的方法，该方法容易受到未经授权的拦截和/或检索。

描述

不安全的设计是一个广泛的类别呈现许多不同的弱点，代表为“缺乏或无效的控制设计”。不安全的设计并不是所有其他10大类风险类别的根源，不安全的设计和不安全的实现是有区别的。我们去区分设计缺陷和实现缺陷是有原因的，他们有不同的根本原因和补救措施。安全设计可能仍然会存在实现上的缺陷，导致可能被利用的漏洞，但是一个不安全的设计不可能通过一个完美的实现来修复，因为根据定义，所需要的安全控制从来没有创建用于防御特定的攻击。导致不安全的设计的因素之一是缺乏对正在开发的软甲或者系统中固有的业务风险分析，因此无法确定需要什么级别的安全设计。

需求和资源管理

收集应用程序的业务要求并与业务部门协商，包括有关所有数据资产的机密性、完整性、可用性和真实性，以及预期业务逻辑的保护要求。考虑应用程序的公开程度以及是否需要隔离（除了访问控制之外）。编写技术要求，包括功能性和非功能性的安全要求。

安全设计

安全设计是一种文化和方法，它不断评估威胁，并确保代码经过稳健的设计和测试，防止已知的攻击方法。威胁建模纳入细化的会议，查找数据流和访问控制或者其他安全组件中的更改。安全设计既不是附加组件，也不是可以添加到软件中的工具。

安全的开发的生命周期

安全软件需要安全的开发生命周期、某种形式的安全设计模式、铺砌的道路方法、安全的组件库、工具和威胁建模。

预防方法

• 与应用安全专业人员一起建立和使用安全的开发生命周期，以帮助评估和设计与安全和隐私相关的控制措施
• 建立和使用安全设计模式库或者已经铺设道路的即用型组件
• 将威胁模型用于关键身份认证、访问控制、业务逻辑和密钥流
• 将安全语言和控件集成到用户情景中
• 在应用程序的每一层集成合理性检查
• 编写单元和集成测试以验证所有关键流是否都能抵御威胁模型，为应用程序的每一层编写用例和误用案例
• 根据暴露和保护需求，在系统层和网络层上设置隔离层
• 通过设计在所有层中强有力的隔离租户
• 按用户或服务限制资源消耗

攻击情景实例

场景 #1：凭据恢复工作流可能包括 NIST 800-63b、OWASP ASVS 和 OWASP 前 10 名所禁止的“问题和答案”。问题和答案不能被信任为身份的证据，由于不止一个人可以知道答案，因此它们被禁止。应该删除此类代码，并将其替换为更安全的设计。

场景 #2： 电影院在要求押金前允许团体预订折扣并且最多有 15 名观众。攻击者可以威胁模型此流程并测试他们在一次请求中是否可以预订 600 个座位和的所有电影院，导致电影院巨大的收入损失。

场景 #3：零售连锁店的电子商务网站没有针对黄牛购买高端显卡转售拍卖网站所运行的机器人的保护，这将造成正常的购买者无法买到显卡。仔细的反机器人设计和域逻辑规则（例如在可用后几秒钟内进行的购买）可能会识别不真实的购买并拒绝此类交易。