OWASP Top 10是一个标准的开发人员和web应用程序安全意识文档。它代表了对web应用程序最关键的安全风险的广泛共识。

A01 Broken Access Control 

越权访问

会导致未经授权的信息披露、修改或销毁所有数据，或在用户权限之外执行业务功能。常见的访问控制漏洞包括：

1、违反了最小特权原则或默认拒绝原则，只有特定功能、角色或用户才能访问，但任何人都可以访问。

2、通过修改URL（参数篡改或强制浏览）、内部应用程序状态或HTML页面，或使用攻击工具修改API请求，绕过访问控制检查。

3、通过提供其唯一标识符（不安全的直接对象引用），允许查看或编辑其他人的帐户

4、访问API时缺少POST、PUT和DELETE的访问控制。

5、特权的提升。以用户身份登录而不登录，或以用户身份登录时以管理员身份登录。

6、元数据操纵，例如重放或篡改JSON Web令牌（JWT）访问控制令牌，或操纵cookie或隐藏字段以提升权限或滥用JWT失效。

7、CORS错误配置允许从未经授权/不受信任的来源访问API。

8、强制以未经身份验证的用户身份浏览经过身份验证的页面，或以标准用户身份浏览特权页面。

A02 Cryptographic Failures

加密失败或弱加密 或未加密 ，会导致敏感数据的泄露

确定传输中和静止数据的保护需求。例如，密码、信用卡号、健康记录、个人信息和商业秘密需要额外保护，主要是如果这些数据属于隐私法.

1. 是否有明文传输的数据？这与HTTP、SMTP、FTP等协议有关，这些协议也使用像STARTTLS这样的TLS升级。外部互联网流量是危险的。验证所有内部流量，例如负载平衡器、web服务器或后端系统之间的流量。

1. 默认情况下或旧代码中是否使用了任何旧的或弱的加密算法或协议？

1. 是否使用默认加密密钥，是否生成或重复使用弱加密密钥，或者是否缺少适当的密钥管理或轮换？加密密钥是否已签入源代码存储库？

1. 是否未实施加密，例如，是否缺少任何HTTP头（浏览器）安全指令或头？
2. 收到的服务器证书和信任链是否正确验证？
3. 不推荐使用的散列函数（如MD5或SHA1）是否正在使用，或者在需要加密散列函数时是否使用非加密散列函数？
4. 不会验证、过滤或净化用户提供的数据。
5. 动态查询或无上下文感知转义的非参数化调用直接在解释器中使用。
6. 搜索参数中使用恶意数据来提取额外的敏感记录。
7. 恶意数据被直接使用或连接。SQL或命令包含动态查询、命令或存储过程中的结构和恶意数据。

A03 Injection 注入

源代码审查是检测应用程序是否易受注入攻击的最佳方法

防止注入需要将数据与命令和查询分开：

首选的选项是使用安全的API，它可以避免完全使用解释器，提供参数化接口，或迁移到对象关系映射工具（ORM）。

注意：即使参数化了，如果PL/SQL或T-SQL将查询和数据连接起来，或者使用EXECUTE IMMEDIATE或exec（）执行恶意数据，存储过程仍然可以引入SQL注入。

对于任何剩余的动态查询，请使用该解释器的特定转义语法转义特殊字符。

注意：表名、列名等SQL结构不能转义，因此用户提供的结构名是危险的。这是报表编写软件中的常见问题。

在查询中使用LIMIT和其他SQL控件，以防止在SQL注入的情况下大量泄露记录。

示例

String query = "

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

";

id=' or '1'='1

SELECT \* FROM accounts WHERE custID=’ ' or '1'='1’  (即查询了全部)

更危险的攻击可能会修改或删除数据，甚至调用存储过程。

A04 Insecure Design

包括功能性和非功能性安全要求。

计划和协商所有all design, build, testing, and operation的预算，包括安全活动。including security activities.

不合理的设计场景示例：

场景#1：凭证恢复工作流可能包括NIST 800-63b、OWASP ASV和OWASP前10名禁止的“问题和答案”。问题和答案不能作为身份的证据，因为不止一个人知道答案，这就是为什么它们被禁止。这样的代码应该被删除，并用更安全的设计取代。

场景#2：一家连锁影院允许团体预订折扣，在要求押金之前最多有15名观众。攻击者可以对这种流量进行威胁建模，并测试他们是否可以在几个请求中同时预订600个座位和所有电影院，从而造成巨大的收入损失。

A05 Security Misconfiguration

安全配置错误

如果应用程序存在以下情况，则该应用程序可能易受攻击：

在应用程序堆栈的任何部分缺少适当的安全强化，或者云服务上的权限配置不当。

启用或安装了不必要的功能（例如，不必要的端口、服务、页面、帐户或权限）。

默认帐户及其密码仍处于启用状态且未更改。

错误处理会向用户显示堆栈跟踪或其他信息量过大的错误消息。

对于升级的系统，最新的安全功能被禁用或未安全配置。

应用服务器、应用程序框架（例如Struts、Spring、ASP.NET）、库、数据库等中的安全设置未设置为安全值。

服务器不发送安全标头或指令，或者它们未设置为安全值。

软件已过期或易受攻击（参见A06:2021-易受攻击和过时的组件）。

如果没有协调一致、可重复的应用程序安全配置过程，系统将面临更高的风险。

 

应实施安全安装流程，包括：

 

可重复的强化过程使部署另一个适当锁定的环境变得快速而容易。开发、QA和生产环境都应该配置相同，在每个环境中使用不同的凭据。这个过程应该是自动化的，以尽量减少建立新的安全环境所需的工作量。

一个最小的平台，没有任何不必要的功能、组件、文档和示例。删除或不安装未使用的功能和框架。

作为补丁管理过程的一部分，审查和更新适用于所有安全说明、更新和补丁的配置的任务（参见A06:2021-易受攻击和过时的组件）。查看云存储权限（例如S3存储桶权限）。

分段应用程序体系结构通过分段、容器化或云安全组（ACL）在组件或租户之间提供有效且安全的分离。

向客户端发送安全指令，例如安全头。

攻击场景示例

场景#1：应用服务器附带的示例应用程序未从生产服务器中删除。这些示例应用程序具有已知的安全漏洞，攻击者可利用这些漏洞来危害服务器。假设其中一个应用程序是管理控制台，默认帐户没有更改。在这种情况下，攻击者使用默认密码登录并接管。

场景2：服务器上未禁用目录列表。攻击者发现他们可以简单地列出目录。攻击者发现并下载编译的Java类，并对其进行反编译和反向工程以查看代码。然后，攻击者发现应用程序中存在严重的访问控制漏洞。

场景#3：应用服务器的配置允许向用户返回详细的错误消息，例如堆栈跟踪。这可能会暴露敏感信息或潜在缺陷，例如已知易受攻击的组件版本。

场景#4：云服务提供商（CSP）拥有其他CSP用户对互联网开放的默认共享权限。这允许访问存储在云存储中的敏感数据。

A06 Vulnerable and Outdated Components

易受攻击和过时的组件

产生过程：

如果您不知道所使用的所有组件的版本（客户端和服务器端）。这包括您直接使用的组件以及嵌套的依赖项。

如果软件易受攻击、不受支持或过时。这包括操作系统、web/application server、数据库管理系统（DBMS）、应用程序、API和所有组件、运行时环境和库。

如果您没有定期扫描漏洞并订阅与您使用的组件相关的安全公告。

如果您没有以基于风险的及时方式修复或升级基础平台、框架和依赖项。这种情况通常发生在以下环境中：补丁是一项每月或每季度的任务，受更改控制，使组织面临数天或数月不必要的固定漏洞暴露。

如何预防

应制定补丁管理流程，如下：

删除未使用的依赖项、不必要的功能、组件、文件和文档。

使用versions、OWASP Dependency Check、retire等工具，持续清点客户端和服务器端组件（如框架、库）的版本及其依赖关系。js等持续监控组件中的漏洞来源，如常见漏洞和暴露（CVE）和国家漏洞数据库（NVD）。使用软件组合分析工具自动化流程。订阅与您使用的组件相关的安全漏洞的电子邮件警报。

只能通过安全链接从官方渠道获取组件。更喜欢签名包，以减少包含修改过的恶意组件的可能性（参见A08:2021-软件和数据完整性故障）。

监视未维护或未为旧版本创建安全修补程序的库和组件。如果修补是不可能的，考虑部署虚拟补丁来监视、检测或保护发现的问题。

A07 Identification and Authentication Failures

识别和身份验证失败（可能存在于登陆、弱密码场景）

如果应用程序有以下表现，可能存在漏洞：

允许自动攻击，如凭证填充，攻击者拥有有效用户名和密码列表。

允许暴力或其他自动攻击。

允许默认密码、弱密码或众所周知的密码，如“Password1”或“admin/admin”。

使用弱或无效的凭证恢复和忘记密码的过程，例如“基于知识的答案”，这无法保证安全。

使用纯文本、加密或弱散列密码数据存储（请参阅A02:2021-Cryptographic Failures）。

缺少或无效的多因素身份验证。

在URL中公开会话标识符。

成功登录后重新使用会话标识符。

无法正确地使会话ID无效。用户会话或身份验证令牌（主要是单点登录（SSO）令牌）在注销或不活动期间不会正确失效。

如何预防

在可能的情况下，实施多因素身份验证以防止自动凭证填充、暴力和被盗凭证重用攻击。

执行弱密码检查

限制或越来越多地延迟失败的登录尝试，但小心不要造成拒绝服务的情况

记录所有故障，并在检测到凭据填充、暴力或其他攻击时通知管理员。

使用服务器端、安全、内置的会话管理器，在登录后生成具有高熵的新随机会话ID

会话标识符不应出现在URL中，应安全存储，并在注销、空闲和绝对超时后失效。

 

攻击场景示例

场景#1：凭证填充，即使用已知密码列表，是一种常见的攻击。假设应用程序未实现自动威胁或凭据填充保护。在这种情况下，应用程序可以用作密码，以确定凭据是否有效。

场景#2：大多数身份验证攻击都是由于密码被继续用作唯一因素而发生的。经过考虑，最佳实践、密码轮换和复杂性要求鼓励用户使用和重用弱密码。建议各组织根据NIST 800-63停止这些做法，并使用多因素认证。

场景#3：应用程序会话超时设置不正确。用户使用公共计算机访问应用程序。用户没有选择“注销”，而是简单地关闭浏览器选项卡并走开。一个小时后，攻击者使用相同的浏览器，用户仍然经过身份验证。

A08 Software and Data Integrity Failures

软件和数据完整性故障

例如，应用程序依赖于来自不受信任的源、存储库和内容交付网络（CDN）的插件、库或模块。不安全的CI/CD管道可能会导致未经授权的访问、恶意代码或系统泄露。最后，许多应用程序现在包括自动更新功能，在没有充分的完整性验证的情况下下载更新，并应用到以前受信任的应用程序。攻击者可能会上传自己的更新，以便在所有安装上分发和运行。另一个例子是，将对象或数据编码或序列化到一个攻击者可以看到并修改的结构中，该结构容易受到不安全反序列化的攻击。

如何预防

使用数字签名或类似机制验证软件或数据是否来自预期来源且未被更改。

确保库和依赖项（如npm或Maven）使用受信任的存储库。如果你有更高的风险，请考虑托管一个内部已知的好的存储库。

确保使用软件供应链安全工具（如OWASP依赖项检查或OWASP CycloneDX）来验证组件不包含已知漏洞

确保对代码和配置更改进行审查，以最大限度地减少恶意代码或配置被引入软件管道的可能性。

确保您的CI/CD管道具有适当的隔离、配置和访问控制，以确保贯穿构建和部署过程的代码的完整性。

攻击场景示例

场景#1未经签署的更新：许多家庭路由器、机顶盒、设备固件和其他设备不通过签署的固件验证更新。未签名固件是攻击者越来越多的攻击目标，预计只会变得更糟。这是一个主要问题，因为很多时候，除了在未来版本中进行修复并等待以前的版本过时之外，没有其他机制可以进行修复。

场景#2 SolarWinds恶意更新：已知民族国家攻击更新机制，最近一次值得注意的攻击是SolarWinds Orion攻击。开发该软件的公司拥有安全的构建和更新完整性流程。尽管如此，它们还是能够被颠覆，在几个月的时间里，该公司向18000多个组织发布了一个针对性很强的恶意更新，其中大约100个组织受到了影响。这是历史上对这一性质最深远、最重大的破坏之一。

A09 Security Logging and Monitoring Failures

安全日志记录和监控故障（增加生产报警监控）

这个类别是帮助检测，升级，并响应主动违规。如果没有日志记录和监控，就无法检测到违规行为。任何时候都会出现记录、检测、监控和主动响应不足的情况：

不记录可审核事件，例如登录、失败登录和高价值事务。

警告和错误不会生成、不充分或不清楚的日志消息。

应用程序和API的日志不受可疑活动的监控。

日志只存储在本地。

适当的警报阈值和响应升级流程不到位或无效。

动态应用程序安全测试（DAST）工具（如OWASP ZAP）的渗透测试和扫描不会触发警报。

应用程序无法实时或接近实时地检测、升级或警告活动攻击。

如何预防

开发人员应根据应用程序的风险实施以下部分或全部控制：

确保所有登录、访问控制和服务器端输入验证失败都可以在足够的用户上下文中记录，以识别可疑或恶意帐户，并保留足够的时间，以允许延迟法医分析。

确保以日志管理解决方案可以轻松使用的格式生成日志。

确保日志数据编码正确，以防止注入或攻击日志或监控系统。

确保高价值事务具有完整性控制的审计跟踪，以防止篡改或删除，例如仅附加数据库表或类似内容。

DevSecOps团队应建立有效的监控和警报，以便发现可疑活动并迅速做出反应。

攻击场景示例

场景#1：由于缺乏监控和日志记录，儿童健康计划提供商的网站运营商无法检测到违规行为。一个外部方通知健康计划提供者，攻击者已访问并修改了350多万儿童的数千份敏感健康记录。事后审查发现，网站开发者没有解决重大漏洞。由于没有对系统进行记录或监控，数据泄露可能从2013年开始进行，时间超过七年。

A10 Server-Side Request Forgery (SSRF)

服务器端请求伪造（SSRF）

攻击者可以使用SSRF攻击受web应用程序防火墙、防火墙或网络ACL保护的系统，攻击场景如下：

场景#1：端口扫描内部服务器–如果网络体系结构未分段，攻击者可以根据连接结果或连接或拒绝SSRF有效负载连接所用的时间来绘制内部网络，并确定内部服务器上的端口是否打开或关闭。

场景#2：敏感数据泄露——攻击者可以访问本地文件，如或内部服务，以获取敏感信息，如file:///etc/passwd和http://localhost:28017/.

场景#3：访问云服务的元数据存储——大多数云提供商都有元数据存储，例如http://169.254.169.254/.攻击者可以读取元数据以获取敏感信息。

场景#4：破坏内部服务——攻击者可以滥用内部服务进行进一步的攻击，如远程代码执行（RCE）或拒绝服务（DoS）。

序号	Type	备注
A01	Broken Access Control	越权访问（包括不安全的直接对象引用、菜单权限等）
A02	Cryptographic Failures	加密失败或弱加密 或未加密 ，会导致敏感数据的泄露
A03	Injection	注入（SQL注入）
A04	Insecure Design	设计要包含非功能性安全要求，设计-开发-测试-运营，均要考虑安全问题	共识
A05	Security Misconfiguration	需要安全配置	共识
A06	Vulnerable and Outdated Components	易受攻击和过时的组件，要进行补丁管理	共识
A07	Identification and Authentication Failures	识别和身份验证失败（可能存在于登陆、弱密码场景）
A08	Software and Data Integrity Failures	软件和数据完整性故障	共识
A09	Security Logging and Monitoring Failures	安全日志记录和监控故障（增加生产报警监控）	共识
A10	Server-Side Request Forgery (SSRF)	服务器端请求伪造（SSRF）

参照：https://owasp.org/www-project-top-ten/#