OWASP Top 10:2021

OWASP Top 10 for 2021 有三个全新的分类，有四个分类有做名称和范围的修正，并有将一些类别做合并

A01 权限控制失效

概述

从第五名晋升至第一名，94% 被测试的应用程序，都有被检测到某种类別权限控制失效的问题。

描述

访问控制强制执行策略，使用户不能在其预期权限之外行事。控制权限失效通常会导致未经授权的信息泄露、修改或破坏所有数据，或执行超出用户权限的业务功能。常见的访问控制漏洞包括：

违反了默认情况下的最小权限或拒绝原则，即只应授予特定功能、角色或用户访问权限，但它现在任何人都可以访问。
通过修改 URL、内部应用程序状态或 HTML 页面，或使用攻击工具修改 API 来绕过存取控制检查。
通过提供其唯一标识符（不安全的直接对象引用）允许查看或编辑他人的帐户。
存取缺少存取控制的 API 以进行 POST、PUT 和 DELETE 操作。
特权提升。在未登录的情况下以用户身份操作，或以用户身份登录时充当管理员。
元数据操作，例如重放或篡改 JSON 网站令牌(JWT)访问控制令牌或cookie，或者操纵隐藏字段以提升权限，或滥用无效的JWT。
跨来源资源共享（CORS）错误配置允许未经授权的 API 存取。
以未经身份验证的用户身份强制浏览已验证的页面或以标准用户身份浏览特权页面。

如何预防

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

除公开的资源外，默认为拒绝存取。
一次性地建置存取控制机制，之后在整个应用程序中重复使用它们，包括最大限度地減少使用跨来源资源共享（CORS）。
模型的存取控制措施应该强制记录所有权，而不是让用户可以创建、读取、更新或刪除任何记录。
域模型应强制执行特殊的应用程序业务限制要求。。
禁用 Web 服务器目录列表，并确保文件元数据（例如，.git)和备份文件不在 web 根目录中。
记录存取控制失效，并在适当的时间警示管理员（例如，重覆性失效）。
限制 API 和控制器存取速率，以最大限度地减少自动攻击工具所带来的危害。
JWT(Json-Web-Token) 令牌于登出后，在服务器端应使其失效。无状态JWT令牌应该是短暂的，这样攻击者的机会就会小很多。对于寿命较长的JWT，强烈建议遵循OAuth标准来撤销访问权限。

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

攻击情境范例

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

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

ResultSet results = pstmt.executeQuery( );

攻击者只需修改浏览器的“acct”參数即可发送他们想要的任何账号。如果没有正确验证，攻击者可以访问任何用户的账户。

https://example.com/app/accountInfo?acct=notmyacct

情境#2：攻击者只需强制浏览目标URL。访问管理页面需要管理员权限。

https://example.com/app/getappInfo

https://example.com/app/admin_getappInfo

如果未经身份验证的用户可以访问任一页面，则这是一个缺陷。如果非管理员可以访问管理员页面，这是一个缺陷。

对应的 CWE 列表

CWE-22 Improper Limitation of a Pathname to a Restricted Directory('Path Traversal')

CWE-23 Relative Path Traversal

CWE-35 Path Traversal: '.../...//'

CWE-59 Improper Link Resolution Before File Access ('Link Following')

CWE-200 Exposure of Sensitive Information to an Unauthorized Actor

CWE-201 Exposure of Sensitive Information Through Sent Data

CWE-219 Storage of File with Sensitive Data Under Web Root

CWE-264 Permissions, Privileges, and Access Controls (should no longer be used)

CWE-275 Permission Issues

CWE-276 Incorrect Default Permissions

CWE-284 Improper Access Control

CWE-285 Improper Authorization

CWE-352 Cross-Site Request Forgery (CSRF)

CWE-359 Exposure of Private Personal Information to an Unauthorized Actor

CWE-377 Insecure Temporary File

CWE-402 Transmission of Private Resources into a New Sphere ('Resource Leak')

CWE-425 Direct Request ('Forced Browsing')

CWE-441 Unintended Proxy or Intermediary ('Confused Deputy')

CWE-497 Exposure of Sensitive System Information to an Unauthorized Control Sphere

CWE-538 Insertion of Sensitive Information into Externally-Accessible File or Directory

CWE-540 Inclusion of Sensitive Information in Source Code

CWE-548 Exposure of Information Through Directory Listing

CWE-552 Files or Directories Accessible to External Parties

CWE-566 Authorization Bypass Through User-Controlled SQL Primary Key

CWE-601 URL Redirection to Untrusted Site ('Open Redirect')

CWE-639 Authorization Bypass Through User-Controlled Key

CWE-651 Exposure of WSDL File Containing Sensitive Information

CWE-668 Exposure of Resource to Wrong Sphere

CWE-706 Use of Incorrectly-Resolved Name or Reference

CWE-862 Missing Authorization

CWE-863 Incorrect Authorization

CWE-913 Improper Control of Dynamically-Managed Code Resources

CWE-922 Insecure Storage of Sensitive Information

CWE-1275 Sensitive Cookie with Improper SameSite Attribute

A02 加密机制失效

概述

上升一个名次来到第二名，之前版本称为“敏感性资料泄漏”，更像是一种广泛的症状而非根因，本版本聚焦于密码学相关的失效(或缺乏加密)，并因此常常导致敏感资料的泄漏。

描述

首先确定静态资料及资料传输的防护需求，举例来说，密码、信用卡卡号、健康档案、个人信息、需要额外保护的商业机密、主要被隐私法所保护的资料，如欧盟 GDPR 或 PCIDSS 等等金融业相关的资料保护法或标准。对于这些资料需考量:

是否以明文形式传输任何数据? 像是 HTTP, SMTP, FTP 等等协定，使用于对外网际网络的流量是危险的。必须验证所有的内部流量，如在负载平衡器、网站服务器、或后端系统之间。
是否有任何老旧或脆弱的加密演算法被预设使用或存在于较旧的程序代码?
是否正在使用默认的加密密钥、是否生成了弱加密密钥并重复使用，是否有适当的密钥管理或轮换?加密密钥是否被写入源代码中？
是否未强制执行加密? 举例: HTTP headers(浏览器)是否有缺少安全相关的指令或头信息?
收到的服务器证书和信任链是否经过正确验证？
初始化向量是否被忽略、重用或生成的加密操作模式是否足够安全？是否使用了ECB等不安全的操作模式？当经过身份验证的加密更合适时，是否使用加密？
在没有使用基于密码的密钥派生函数(PBKDF)的情况下，密码是否被用作加密密钥？

如何预防

至少执行以下措施，并参考相关资料:

对应用程序处理、存储、传输的资料进行分类，根据隐私法、法令法规、或商业需求辨认哪些为敏感性资料。
依照分类执行对应的控制措施。
非必要不储存敏感性资料，尽快舍弃或使用符合 PCIDSS tokenization甚至truncation。没有被保存的数据是不会被窃取的。
确保将所有静态的敏感性资料加密。
确认使用最新版、标准且强大的算法、协议及密钥；使用适当的密钥管理。
使用安全的协议加密传输中的资料，如具有前向保密（FS）的TLS、服务器的密码优先级和安全参数。使用如 HTTP 强制安全传输技术(HSTS)的指令强制加密。
针对包含敏感资料的响应禁用缓存。
根据数据分类应用所需的安全控制。
不要使用 FTP 和 SMTP 等传统协议进行传输敏感数据。
使用具有计算因子/延迟因子(work factor/delay factor)的强自适应性加盐哈希函数来储存密码，如 Argon2, scrypt, bcrypt 或 PBKDF2 。
始终使用经过身份验证的加密，而不仅仅是加密。
密钥应随机加密生成，并作为字节数组存储在内存中。如果使用密码，则必须通过适当的基于密码的密钥推导函数将其转换为密钥。
确保在适当的情况下使用加密随机性，并且没有以可预测的方式或低熵的方式播种。大多数现代API不需要开发人员为CSPRNG（密码学安全伪随机数生成器）添加种子来获得安全保障。
避免使用已弃用的加密函数和填充方案，如MD5, SHA1, PKCS #1v1.5
独立验证设定的有效性。

攻击情境范例

情境 #1: 应用程序使用自动数据库加密对数据库中的信用卡号进行加密。然而，当检索到这些数据时，它们会自动解密，从而允许SQL注入漏洞以明文形式检索信用卡号。

情境 #2: 有一个网站没有使用或没有强制使用TLS或支持弱的密钥加密，攻击者监控网络流量(如在不安全的无线网络), 将连线从 HTTPS 降级成 HTTP，并拦截请求窃取使用者的会话 cookies，之后攻击者重送窃取到的会话cookies 并劫持用户(经过身份验证的)的会话，进而访问或修改用户的私人数据。除了上述以外，攻击者也能修改所有传输的数据，如汇款收款人。

情境 #3: 密码资料库使用未被加盐或简单的哈希函数来储存每个人的密码，文件上传漏洞可以让攻击者存取密码数据库，所有未被加盐的哈希可以被预先计算好的彩虹表（一个用于加密哈希函数逆运算的预先计算好的表，为破解密码的哈希值而准备）解密。即使加盐，由简单或快速哈希函数生成的哈希仍可能被 GPU 破解。

对应的 CWE 列表

CWE-261 Weak Encoding for Password

CWE-296 Improper Following of a Certificate's Chain of Trust

CWE-310 Cryptographic Issues

CWE-319 Cleartext Transmission of Sensitive Information

CWE-321 Use of Hard-coded Cryptographic Key

CWE-322 Key Exchange without Entity Authentication

CWE-323 Reusing a Nonce, Key Pair in Encryption

CWE-324 Use of a Key Past its Expiration Date

CWE-325 Missing Required Cryptographic Step

CWE-326 Inadequate Encryption Strength

CWE-327 Use of a Broken or Risky Cryptographic Algorithm

CWE-328 Reversible One-Way Hash

CWE-329 Not Using a Random IV with CBC Mode

CWE-330 Use of Insufficiently Random Values

CWE-331 Insufficient Entropy

CWE-335 Incorrect Usage of Seeds in Pseudo-Random Number Generator(PRNG)

CWE-336 Same Seed in Pseudo-Random Number Generator (PRNG)

CWE-337 Predictable Seed in Pseudo-Random Number Generator (PRNG)

CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator(PRNG)

CWE-340 Generation of Predictable Numbers or Identifiers

CWE-347 Improper Verification of Cryptographic Signature

CWE-523 Unprotected Transport of Credentials

CWE-720 OWASP Top Ten 2007 Category A9 - Insecure Communications

CWE-757 Selection of Less-Secure Algorithm During Negotiation('Algorithm Downgrade')

CWE-759 Use of a One-Way Hash without a Salt

CWE-760 Use of a One-Way Hash with a Predictable Salt

CWE-780 Use of RSA Algorithm without OAEP

CWE-818 Insufficient Transport Layer Protection

CWE-916 Use of Password Hash With Insufficient Computational Effort

A03 注入式攻击

概述

注入式攻击下滑到了第三名。 94% 被测试的应用程序都有验测到某种类型的注入式攻击问题。

描述

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

应用程序未验证、过滤或去除用户提供的数据。
没有经过上下文转义的动态查询或非参数化调用被直接在解释器中使用。
在对象关系映射（ORM）搜索参数中，使用恶意数据来获得额外的敏感记录。
在动态查询、命令或储存的程序，SQL、指令或储存的程序中，直接使用或连结了恶意资料。

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

如何预防

需要将命令与查询资料分开，以防止注入式攻击。
首要的选项是使用安全的应用程序界面 (API)，完全避免使用直译器，以提供参数化的界面或整合到物件关系对映 (ORMs) 工具中。
注意：即使已经参数化了，在储存的程序中仍然可以引入 SQL 注入攻击，如果透过 PL/SQL 或 T-SQL 连接查询与资料，并使用 EXECUTE IMMEDIATE 或 exec() 执行恶意资料。
使用正面或白名单在服务器端验证输入的资料。这并不是一个完整的防御机制，因许多应用程序需要使用特殊的字符，例如：应用程序的文本区域或应用程序界面 (API)应用于行动装置上的应用程序。
对于任何剩余的动态查询，在转译中使用特殊符号进行查询将对查询语法带来不同的涵义。
注意：在 SQL 结构中，例如：资料表名称、栏位名称是无法被转译的，因此使用者提供资料结构的名称是危险的，这是一个在编写软体时常见的问题。
在查询中使用 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=' UNION SELECT SLEEP(10);--

这两个查询的含义将产生改变，而回应所有帐户资料表中的纪录，更危险的攻击将可能修改或删除资料，以及影点资料的储存过程。

对应的 CWE 列表

CWE-20 Improper Input Validation

CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')

CWE-75 Failure to Sanitize Special Elements into a Different Plane(Special Element Injection)

CWE-77 Improper Neutralization of Special Elements used in a Command('Command Injection')

CWE-78 Improper Neutralization of Special Elements used in an OS Command('OS Command Injection')

CWE-79 Improper Neutralization of Input During Web Page Generation('Cross-site Scripting')

CWE-80 Improper Neutralization of Script-Related HTML Tags in a Web Page(Basic XSS)

CWE-83 Improper Neutralization of Script in Attributes in a Web Page

CWE-87 Improper Neutralization of Alternate XSS Syntax

CWE-88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')

CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

CWE-90 Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')

CWE-91 XML Injection (aka Blind XPath Injection)

CWE-93 Improper Neutralization of CRLF Sequences ('CRLF Injection')

CWE-94 Improper Control of Generation of Code ('Code Injection')

CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

CWE-96 Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')

CWE-97 Improper Neutralization of Server-Side Includes (SSI) Within a Web Page

CWE-98 Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')

CWE-99 Improper Control of Resource Identifiers ('Resource Injection')

CWE-100 Deprecated: Was catch-all for input validation issues

CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')

CWE-116 Improper Encoding or Escaping of Output

CWE-138 Improper Neutralization of Special Elements

CWE-184 Incomplete List of Disallowed Inputs

CWE-470 Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')

CWE-471 Modification of Assumed-Immutable Data (MAID)

CWE-564 SQL Injection: Hibernate

CWE-610 Externally Controlled Reference to a Resource in Another Sphere

CWE-643 Improper Neutralization of Data within XPath Expressions ('XPath Injection')

CWE-644 Improper Neutralization of HTTP Headers for Scripting Syntax

CWE-652 Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')

CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')

A04 不安全设计

概述

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

描述

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