A1：注入
将不受信任的数据作为命令或查询的一部分发送到解析器时，会产生诸如 SQL注入、OS注入和 LDAP注入的注入缺陷。攻击者的恶意数据可以诱使解析器在没有适当授权的情况下执行非预期命令或访问数据。
可利用性：几乎任何数据源都能成为注入载体，包括用户、参数、外部和内部Web服务。当攻击者向解析器发送恶意数据时，注入漏洞产生。
普遍性：注入漏洞十分普遍，尤其是遗留在代码中。通常能在 SQL查询语句、LDAP查询语句、Xpath查询语句、NoSQL查询、OS命令、XML解析器、SMTP头、表达式语句、ORM查询语句中找到。
可检测性：注入漏洞很容易通过审查代码发现。扫描器和模糊测试工具可以帮助攻击者找到这些漏洞。
影响：注入能导致数据丢失或数据破坏、缺乏可审计性或是拒绝服务。注入漏洞有时甚至能导致完全主机接管。
当存在以下情况时易受攻击：
- 用户支持的数据没有经过应用程序的验证、过滤或净化
- 恶意数据直接被解析器用于动态的查询或非参数化的调用，而无需上下文感知的转义
- 在 ORM搜索参数中使用了恶意数据，这样搜索就会预估出包含敏感或所有记录的数据
- 恶意数据时直接使用或连接，注入 SQL语句或命令在动态查询、命令或存储过程中包含结果和恶意数据
防范：
- 防范注入漏洞需要将数据与命令语句、查询语句分割开来
- 使用安全的 API，完全避免使用解析器，或提供参数化界面的接口，或迁移到 ORM或实体框架
- 使用正面的具有恰当的规范化的输入验证方法。但这不是一个完整的防御，因为许多应用程序在输入中需要特殊字符，例如文本区域或移动应用程序的API
- 对于任何动态查询，可以使用解释器的特定转义语法转义特殊字符
- 在查询中使用 LIMIT 和其他 SQL 控件，以防止 SQL注入时大量的公开记录
攻击案例
A2：失效的身份认证和会话管理（BASM）
通过错误的使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌，或者利用其他开发中的缺陷来冒充其他用户的身份。
当前，Web 应用程序一般通过 Cookie 的传送来完成使用者身份的认证，认证通过后，会话期间变回持续使用该身份。但是如果首次传送 Cookie 后便不再对 Cookie 中的内容进行检查，攻击者便可修改 Cookie 中的重要信息，用来提升权限对网站资料进行存取，或是毛用他人账号获取私密资料。
可利用性：攻击者可以获得数亿用户名和密码组合，包括证书填充、默认的管理账户列表、自动的暴力和字典攻击工具，以及高级的GPU破解工具。
普遍性：大多数身份和访问管理系统的设计和实现普遍存在身份认证失效问题。
可检测性：攻击者可以使用手动方式检测失效的身份验证。通常会关注密码转储或者在类似钓鱼或社会工程攻击后，发现失效的身份认证。
影响：破坏系统，敏感信息遭到泄露。
当存在以下情况时易受攻击：
- 允许凭证填充，这样使得攻击者获得有效用户名和密码列表
- 允许暴力破解或其他自动攻击
- 允许默认的、弱的或众所周知的密码，如 admin/admin
- 使用弱的或失效的验证凭证
- 使用明文、加密或散列密码
- 缺少多因素身份认证
防范：
- 不要使用部署默认的凭证，特别是管理员用户
- 使用非过时的哈希技术来存储密码，如 Argon2 或 PBKDF2
- 执行弱密码检查
- 确认注册、凭据恢复和API路径，通过对所有输出结果使用相同的消息，用以抵御账户枚举攻击
- 在尽可能的地方，实现多因素身份认证
- 当凭证填充、暴力破解或其他攻击被检测到，警告管理员
攻击案例：
A3：敏感数据泄露
许多 Web 应用程序和 API 都无法正确保护敏感数据，攻击者可以窃取或修改这些未加密的数据，用以进行信用卡诈骗、身份盗窃或其他犯罪。因此我们需要对敏感数据加密，这些数据包括：传输过程中的数据、被存储的数据以及浏览器交互数据。
可利用性：尽管匿名攻击者通常不直接攻击加密系统，但是他们往往通过诸如窃取密钥、发起中间人攻击或从服务器窃取明文数据等方式对传输中的或者客户浏览器中的数据进行破解。攻击者通常实施手动攻击。
普遍性：最近几年里影响最严重的攻击，最常见的漏洞是不对敏感信息进行加密。在数据加密过程中，常见的问题是不安全的密钥生成和管理以及使用弱加密算法，特别是使用弱的哈希算法来保护密码。
可检测性：在服务器中，检测传输过程中的数据弱点很容易，但检测存储数据的弱点非常困难。
当存在以下情况时易受攻击：
- 传输时采用明文传输
- 当数据长期存储时，没有加密
- 使用了旧的或脆弱的加密算法
- 使用默认的加密密钥，重复使用脆弱的加密密钥，或者缺少恰当的密钥管理或密钥回转
- 没有强制加密敏感数据
防范：
- 对系统处理、存储或传输的数据分类，并根据分类进行访问控制
- 熟悉与敏感数据保护相关的法律和条例，根据每项法规要求保护敏感数据
- 对于没必要存放的、重要的敏感数据，应当尽快清除，或通过 PCI DSS 标记拦截
- 确保存储的所有敏感数据被加密
- 确保传输过程中的数据被加密
- 确保使用了最新的、强大的标准算法或密码、参数、协议和密钥，并且密钥管理到位
- 禁止缓存对包含敏感数据的相应
- 单独验证每个安全配置项的有效性
攻击案例：
A4：XML 外部实体（XXE）
许多较早的或配置不佳的 XML 处理器评估了 XML 文档中的外部实体引用。外部实体可以通过 URI 文件处理器、未修复的 SMB 文件共享、内部端口扫描、远程代码执行等方式来试试拒绝服务攻击。
可利用性：攻击者能够利用 XML 缺陷成功访问 Web 页面或 Web 服务，特别是基于 Web 服务的 SOAP。
普遍性：许多旧的 XML 处理器能够对外部实体、XML 进程中被引用和评估的 URI 进行规范。
可检测性：SAST 工具可以通过检测依赖项和安全配置来发现 XXE 缺陷。
影响：XXE 缺陷可用于提取数据、执行远程服务器请求、扫描内部系统、执行拒绝服务攻击和其他攻击。
当存在以下情况时易受攻击：
- 应用程序直接接受 XML 文件或者接受 XML 文件上传，特别是来自不信任源的文件，或者将不受信任的数据插入 XML 文件，并提交给 XML 处理器解析。
- 应用程序使用 1.2 版本之前的 SOAP，并将 XML 实体传递到 SOAP 框架
防范：
- 在应用程序的所有 XML 解析器中禁用 XML 外部实体和 DTD 进程
- 实施积极的输入验证、过滤和清理，以防止在 XML 文档、标题或节点中出现恶意数据
- 验证 XML 或 XSL 文件上传功能是否使用 XSD 验证或其他类似验证方法来上传 XML 文件
- 及时修复或更新应用程序或底层操作系统所使用的XML处理器和库。使用依赖检查程序对必要库和组件的风险管理至关要，而且需要检查所有应用程序和下游集成中的库和组件
- 将 SOAP 升级到最新版本
- 使用虚拟修复程序、API 安全网关或 WAFs 来检测、监控和防止 XXE 攻击
攻击案例：
A5：失效的访问控制
未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据，例如：访问其他用户的账户、查看敏感文件、修改其他用户的数据、更改访问权限等。
可利用性：SAST 和 DAST 工具可以检测到访问控制的缺失，但不能验证其功能是否正常。访问控制可通过手动方式检测，或在某些特定框架下通过自动化检测访问控制缺失。
普遍性：由于缺乏自动化的检测和应用程序开发人员缺乏有效的功能测试，因而访问控制缺陷很常见。
可检测性：访问控制检测通常不适用于自动化的静态或动态测试。一班通过手动方式检测。
影响：匿名攻击者充当用户或管理员，、有特权功能的用户来创建、访问、更新或删除每条记录。
当存在以下情况时易受攻击：
- 通过修改 URL、内部应用程序状态或 HTML 页面绕过访问控制检查。
- 允许将主键更改为其他用户的记录，例如：查看或编辑他人的账户
- CORS 配置错误导致允许未授权的 API 访问
- API 没有对 POST、PUT 和 DELETE 强制执行访问控制权限
防范：
- 使用一次性的访问控制机制
- 建立访问控制模型，不接受用户创建、读取、更新或删除任何记录
- 域访问控制对每个应用程序都是唯一的
- 禁用 Web 服务器目录列表，并确保文件元数据 (如：git) 不存在与 Web 的根目录中
- 记录失败的访问控制，并在适当时向管理员告警
- 对 API 和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具的危害
攻击案例：
A6：安全配置错误（Security Misconfiguration）
安全配置错误是数据中最常见的缺陷，这部分缺陷包含：手动配置错误、临时配置、不安全的默认配置、开启 S3 bucket、不当的 HTTP 标头配置、包含敏感信息的错误信息、未及时修补或升级系统、框架、依赖项和组件
可利用性：攻击者能够通过访问默认账户、不再使用的页面、未修复的缺陷、未保护的文件和目录等来取得系统的未授权访问或了解。
普遍性：安全配置错误可以发生在一个应用程序堆栈的任何层面，包括平台、Web服务器、应用服务器、数据库、框架和自定义代码。
可检测性：自动扫描器可用于检测未安装补丁、错误的配置、默认账户的使用、不必要的服务等。
影响：这些漏洞使攻击者能经常访问一些未授权的系统数据或功能，有时甚至导致系统完全被攻破。
当存在以下情况时易受攻击：
- 使用或安装了不必要的功能 (如：端口、服务、网页、账户、权限)
- 默认账户的密码没有更改
- 错误处理机制无法防止堆栈跟踪和其他大量的错误信息被泄露
- 在已经升级了的软件上使用老的配置
- 没有对应用服务器和应用框架进行安全配置
- 对于 Web 应用程序，服务端没有将安全指示发送到客户端或这些指示没有足够的安全
防范：
- 移除或不安装任何不需要的功能、组件、文档和示例。移除不适用的依赖和框架
- 在所有环境中能够进行自动化的正确安全配置和设置
攻击案例：
A7：跨站脚本（XSS）
跨站脚本 (XSS) 的英文是 Cross-Site Scripting，其缩写是 CSS，但是 CSS 在网页设计领域已经被广泛指为层叠样式表 (Cascading Style Sheets)，所以将 Cross 改为发音相似的 X作为缩写。
每当应用程序的新网页包含不受信任的、未经过恰当验证或转义的数据，或者使用可以创建 JavaScript 的浏览器 API 更新现有网页时，就会出现 XSS 漏洞。XSS 漏洞让攻击者能够在受害者的浏览器中执行脚本，并劫持用户会话，污损网站或将用户重定向到恶意站点。
分类：根据 XSS 脚本注入方式不同，一般把 XSS 攻击分为反射型XSS、存储型XSS、DOM型XSS。
- 反射型XSS 顾名思义是一种非持久型的 XSS，它的攻击方式具有一次性的特点：攻击者通过邮件等方式将包含注入的恶意链接发给受害者，当受害者点击链接时，注入脚本连接到攻击者准备好的服务器某个恶意文件上，然后服务器将注入的文件“反射”到受害者的浏览器上，从而该浏览器执行了这段恶意文件。
应用中包含未验证的或未编码的用户输入，并作为 HTML 或其他未启用 CSP 头的一部分输出。成功的攻击将在受害者的浏览器上执行任意 HTML 或 JS 代码。 - 存储型XSS 与反射型XSS 的最大区别就是攻击脚本能永久存储在目标服务器数据库或文件中。存储型 XSS攻击多见于论坛和博客等 Web 站点，攻击者在论坛发帖的过程中，将恶意脚本连同正常的信息一起注入帖子内容中。随着帖子被后台服务器存储，恶意脚本也被存储下来。当其他用户浏览该帖子的时候，恶意脚本便会在他们的浏览器中执行。
应用或者 API 将未净化的用户输入存储下来了，并在后期在其他用户或管理员的页面展示出来。 - DOM型XSS 与两种跨站方式不同，它利用了客户端浏览器对请求的网页进行 DOM 渲染。会动态的将攻击者可控的内容加入页面的JavaScript框架。如：
可利用性：攻击者利用浏览器中的解释器发送基于文本的攻击脚本。几乎所有数据源都能成为攻击媒介，包括内部数据源比如数据库中的数据。
普遍性：XSS 是 OWASP Top 10 中第二普遍的安全问题，存在于近三分之二的应用中。
可检测性：自动化工具能够自动发现一些 XSS 问题，特别是在一些成熟的技术中，如：PHP、J2EE、JSP、ASP.NET。
影响：攻击者能在受害者的浏览器中执行脚本以劫持用户会话、破坏网站、插入恶意内容、重定向用户、使用恶意软件劫持用户浏览器等等。
防范：将不可信数据与动态的浏览器内容区分开
- 使用设计上就会自动编码来解决 XSS 问题的框架，如：Ruby 3.0 或 React JS
- 为了避免服务器 XSS，最好的办法是根据数据将要置于 HTML上下文 (包括：主体、属性、JavaScript、CSS 或 URL)的所有不可信数据进行恰当的转义
- 为了避免客户端 XSS，最好的选择是避免传递不受信任的数据到 JavaScript 和可以生成活动内容的其他浏览器 API
- 使用内容安全策略 (CSP) 是对抗 XSS 的深度防御策略
攻击案例：
A8：不安全的反序列化
当应用程序接收到恶意的反序列化对象时，会出现不安全的反序列化漏洞。不安全的反序列化会导致远程代码执行。即便反序列化漏洞不会导致远程代码执行，也可以重播、篡改或删除序列化对象以欺骗用户、进行注入攻击和提升权限
可利用性：对反序列化的利用较困难，因为在不更改或调整底层可被利用代码的情况下，货架漏洞 （Shelf Exploit）很少起作用。
可检测性：有些工具可用于反序列化缺陷，但经常需要人工帮助来验证开发问题。
影响：可能导致远程代码执行攻击，这是可能发生的最严重的攻击之一。
当存在以下情况时易受攻击：分布式应用程序或那些需要在客户端或文件系统上存储状态的程序，可能正在使用对象序列化。具有公共侦听器或依赖于客户端维护状态的分布式应用程序，很可能允许对序列化数据进行篡改。这种攻击可使用于二进制格式（如：Java 序列化），或基于文本的格式（如：Json.Net）
- 序列化机制允许创建任意数据类型
- 有可用于将应用程序链接在一起的类，以在反序列化期间或之后改变应用程序行为，或者使用非预期的内容来影响应用程序行为
- 应用程序或 API 接收反序列化攻击者提供的恶意对象，或者应用程序使用了不具有恰当防篡改控制的系列化不透明客户端状态
- 安装状态发送到缺失了完整性控制的不受信客户端
防范：
- 不接受来自不受信源的序列化对象
- 使用只允许原始数据类型的序列化媒体
- 对序列化对象执行完整性检查或加密，以防止恶意对象创建或数据篡改
- 在创建对象之前强制执行严格的类型约束
- 隔离反序列化代码，使其在非常低的特权环境 (如：临时容器) 中运行
- 记录反序列化的例外情况和失败信息，如：传入的类型不是预期类型或者反序列化处理引发的例外情况
- 限制或监视来自于容器或服务器传入或传出的反序列化网络连接
- 监视反序列化，当用户持续进行反序列化时，对用户进行警告
攻击案例：
A9：使用含有已知漏洞的组件
组件 (如：库、框架和其他软件模块) 运行和应用程序具有相同的权限。如果使用含有已知漏洞的组件，这样的攻击可以造成严重的数据丢失或服务器被接管。使用含有已知漏洞的组件的应用程序和 API 可能会破坏应用程序防御，造成各种攻击并产生严重影响。
可利用性：虽然很容易找到许多对已知漏洞的已编好的利用代码，但是对于其他漏洞需要集中精力开发定制的利用方法。
普遍性：大多数的应用和 API 都存在，因为大多数的开发团队并不会把 及时更新组件/库 作为他们的工作重心。
可检测性：可被扫描器 (如：Retire.js) 或头部检查发现。但验证是否可被利用需要可被描述的攻击行为。
影响：从最低的受损到主机被完全接管和数据的泄露都有可能发生。
当存在以下情况时易受攻击：
- 软件的任一部分过时了。包括：操作系统、Web/App 服务器、DBMS、应用程序、API 和所有的组件、运行环境和库
- 没有及时修复或升级底层平台、框架和依赖关系
- 没有对组件进行安全配置
防范：
- 移除不使用的依赖、不需要的功能、组件、文件和文档
- 利用工具如：versions、DependencyCheck、retire.js 等来持续的记录客户端和服务器端以及它们的依赖库的版本信息
- 对使用的组件持续监控如 CVE 和 NVD 等漏洞中心
- 使用虚拟补丁技术去检测和保护库和组件
A10：不足的日志记录和监控
不足的日志记录和监控，以及事件响应继承的丢失或无效，使得攻击者能够进一步供给系统，保持持续性或转向更多系统，以及篡改、提取或销毁数据。
可利用性：对不足的日志记录及监控的利用是每一个重大安全事件的温床。攻击者依靠监控的不足和响应的不及时来达成他们的目标而不被知晓。
可检测性：在渗透测试后检查日志。
当存在以下情况时易受攻击：
- 未记录可审计事件（如：登录、登录失败和高价值事务）
- 应用或 API 的日志对可疑活动未做记录
- 根据应用程序持有的数据的风险、警报阈值和响应升级不到位
防范：
- 确保所有登录、访问控制失败、输入验证失败记录了足够的上下文，以识别可疑或恶意账户，并未后期取证需要保存足够的时间
- 确保高价值事务有完整性控制的审计跟踪，以防止篡改或删除
- 建立有效的检测和告警机制，使可疑活动在可接受的时间内被发现和应对
攻击案例：
补充一些以往 OWASP Top 10 中比较著名的漏洞
跨站请求伪造（CSRF）
一个跨站请求伪造攻击迫使登录用户的浏览器将伪造的HTTP请求，包括受害者的会话cookie和所有其他自动填充的身份认证信息，发送到一个存在漏洞的web应用程序。这种攻击允许攻击迫使受害者的浏览器生成让存在漏洞的应用程序认为是受害者的合法请求的请求。
CSRF 属于跨站脚本漏洞的一种衍生，基本原理是：攻击者利用 XSS 的注入方式注入一段脚本，当受害者点击浏览器运行该段脚本时，脚本伪造受害者发送一个合法请求。
可利用性：攻击者创建伪造HTTP请求并通过图片标签、iframe、跨站脚本或许多其它技术诱使受害用户提交这些请求。如果该受害用户已经经过身份认证，那么攻击就能成功。
普遍性：曾今在 OWASP 组织 2010年列出的十大 Web 安全漏洞中排名第五，但由此产生了许多防御框架，包括大大降低这种漏洞影响范围的自动化 CSRF 防御措施，已经从一个广泛影响的漏洞变得不那么常见了。
可检测性：跨站请求伪造漏洞可以很容易通过渗透测试或代码分析检测到。
影响：攻击者能欺骗受害者用户完成该受害者所允许的任意状态改变的操作。
防范：
- 将独有的令牌包含在一个隐藏字段中，这将使得该令牌通过 HTTP 请求体发送，避免其包含在 URL 中从而被暴露出来
- 利用已有的 CSRF 防护方案。许多框架如Spring, Play, Django以及AngularJS，都内嵌了CSRF防护，一些web开发语言如.Net也提供了类似的防护。
攻击案例：
未受有效保护的 API
现代应用程序通常涉及丰富的客户端应用程序和API，如：浏览器和移动APP中的JavaScript，其与某类API(SOAP/XML、REST/JSON、RPC、GWT等）连接。这些API通常是不受保护的，并且包含许多漏洞。
可利用性：攻击者可以通过检查客户端代码或监控网络通信来进行逆向工程。
普遍性：现在Web应用程序越来越广泛的使用客户端（浏览器、移动客户端、桌面客户端等）访问后台API接口（XML, JSON,RPC,GWT,自定义格式）Microservice,Service, Endpoint等API可能会受到各种常见的安全威胁。
可检测性：代码扫描工具往往难以发现 API 相关的漏洞，人工审计也会有困难，所以这些漏洞经常发现不良。
影响：数据泄露、损坏、销毁、整个应用受到未授权访问；甚至是整个主机被控制。
防范：
- 确保 Client 和 API 之间通过安全信道进行通讯
- 确保 API 有强安全级别的认证模式，并且所有的凭据、密钥、令牌都得到保护
- 确保不管使用哪种数据格式，解析器都应当做好安全加固，防止攻击
- 为 API 访问实现权限控制
攻击案例：
