什么是OWASP？
在 开放Web应用基金会致力于创造一个更安全的网络应用环境。它免费提供文章、工具、技术和论坛，让每个开发人员都能创建安全的代码。其最著名的项目之一是 OWASP Top 10。
什么是 OWASP 前 10 名？
OWASP Top 10 是根据开放 Web 应用程序安全项目公开共享的 10 个最关键的 Web 应用程序安全漏洞列表。根据 OWASP，漏洞是应用程序中的一个弱点，它允许恶意方对应用程序的利益相关者（所有者、用户等）造成伤害。
OWASP Top 10 列表由全球 Web 应用程序安全专家开发并定期更新。它旨在教育公司了解他们需要缓解以保护其 Web 应用程序的漏洞和关键安全风险。
在 Top 10 列表旁边，OWASP 还发布和维护以下资源：
- OWASP Juice Shop：用于安全培训的故意不安全的 Web 应用程序
- OWASP 测试指南：应用程序测试的“最佳实践”
OWASP 前 10 名名单
1.失效的访问控制
访问控制强制实施策略，使用户无法在其预期权限之外进行操作。失败的访问控制通常会导致未经授权的信息泄露、修改或销毁所有数据、或在用户权限之外执行业务功能。常见的访问控制脆弱点包括：
- 违反最小特权原则或默认拒绝原则，即访问权限应该只授予特定能力、角色或用户，但实际上任何人都可以访问。
- 通过修改 URL（参数篡改或强制浏览）、内部应用程序状态或 HTML 页面，或使用修改 API 请求的攻击工具来绕过访问控制检查。
- 通过提供唯一标识符（不安全的直接对象引用）允许查看或编辑其他人的帐户。
- API没有对POST、PUT 和DELETE强制执行访问控制。
- 特权提升。 在未登录的情况下假扮用户或以用户身份登录时充当管理员。
- 元数据操作，例如通过重放或篡改 JSON Web 令牌 (JWT) 来访问控制令牌，或操纵cookie 或隐藏字段以提升权限，或滥用 JWT 失效。
- CORS 配置错误以致允许未授权或不可信的API访问。
- 以未通过身份验证的用户身份强制浏览的通过身份验证时才能看到的页面或作为标准用户身份访问特权页面。
预防措施
访问控制只在受信服务器端代码或无服务器API中有效，这样攻击者才无法修改访问控制检查或元数据。
- 除公有资源外，默认为“拒绝访问”。
- 使用一次性的访问控制机制，并在整个应用程序中不断重用它们，包括最小化跨源资源共享 (CORS) 的使用。
- 建立访问控制模型以强制执行所有权记录，而不是简单接受用户创建、读取、更新或删除的任何记录。
- 特别的业务应用访问限制需求应由领域模型强制执行。
- 禁用Web服务器目录列表，并确保文件元数据（例如： .git）和备份文件不存在于Web的根目录中。
- 在日志中记录失败的访问控制，并在适当时向管理员告警（例如：重复故障）。
- 对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具带来的危害。
- 当用户注销后，服务器上的状态会话标识符应失效。无状态的JWT令牌应该是短暂的，以便让攻击的攻击机会窗口最小化。 对于时间较长的JWT，强烈建议遵循OAuth标准来撤销访问。
开发人员和QA人员应进行访问控制功能的单元测试和集成测试。
2.加密机制失效
首先要确认：对传输中数据和存储数据都有哪些保护需求。 例如，密码、信用卡号、医疗记录、个人信息和商业秘密需要额外保护，尤其是在这些数据属于隐私保护法（如：欧盟GDPR) 或法规条（如：金融数据保护标准PCI DSS)适用范围的情况下。 对于这些数据，要确定：
- 在传输数据过程中是否使用明文传输？这和传输协议有关，如：HTTP、SMTP、经过TLS升级（如STARTTLS ）的FTP。外部网络流量是有害的。需要验证所有的内部通信，如，负载平衡、Web服务器或后端系统之间的流量。
- 无论是在默认情况下还是在旧的代码中，是否还在使用任何旧的或脆弱的加密算法或传输协议？
- 是否使用默认加密密钥、生成或重复使用脆弱的加密密钥，或者是否缺少适当的密钥管理或密钥回转？加密密钥是否已经提交到源代码存储库？
- 是否未执行强制加密，例如，是否缺少安全相关的HTTP（浏览器）指令或标头？
- 接收到的服务器证书和信任链是否经过正确验证？
- 初始化向量是否忽略，重用或生成的密码操作模式是否不够安全？ 是否正在使用不安全的操作模式，例如欧洲央行正在使用的操作模式？ 当认证加密更合适时是否使用加密？
- 在缺乏密码基密钥派生函数的情况下，是否将密码用作加密密钥？
- 随机性是否用于并非旨在满足加密要求的加密目的？ 即使选择了正确的函数，它是否需要由开发人员播种，如果不需要，开发人员是否用缺乏足够熵/不可预测性的种子覆盖了内置的强大播种功能？
- 是否使用过时的散列函数，例如 MD5 或 SHA1，或者在散列函数需要加密时使用非加密散列函数？
是否在使用已弃用的加密填充方法，例如 PCKS number 1 v1.5？ - 加密的错误消息或侧信道信息是否可以利用，例如使用填充预言机攻击的形式？
预防措施
对应用程序处理、存储或传输的数据分类，并根据隐私法、监管要求或业务需求确定哪些数据是敏感的。
- 对于没有必要存储的敏感数据，应当尽快清除，或者通过PCI DSS标记化或拦截。 未存储的数据不能窃取。
- 确保加密存储的所有敏感数据。
- 确保使用了最新的、强大的标准算法、协议和密钥；并且密钥管理到位。
- 确保加密传输过程中的数据，如使用安全协议（例如具有前向保密 (FS) 密码的 TLS、服务器的密码优先级和安全参数）。确保强制执行数据加密，如使用HTTP 严格安全传输协议 (HSTS) 等指令。
- 禁用缓存对包含敏感数据的响应。
- 根据数据分类应用实施所需的安全控制。
- 不要使用FTP 和SMTP 等传统协议来传输敏感数据。
- 使用具有工作因子（延迟因子）的强自适应和加盐散列函数存储密码，例如 Argon2、scrypt、bcrypt 或PBKDF2。
- 必须选择适合操作模式的初始化向量。对于大多数模式，可以使用CSPRNG（密码安全伪随机数生成器）。对于需要随机数的模式，则初始化向量 (IV) 不需要使用CSPRNG。 在所有情况下，对于一个固定密钥，永远不应该使用两次IV。
- 始终使用经过验证的加密，而不仅仅是加密。
- 密钥应以加密方式随机生成并作为字节数组存储在内存中。 如果使用密码，则必须通过适当的密码基密钥派生函数将其转换为密钥。
- 确保在适当的地方使用加密随机性，并且没有以可预测的方式或低熵进行播种。 大多数现代 API 不需要开
发人员为 CSPRNG 设置种子以获得安全性。 - 避免使用的已废弃的加密函数和填充方案，例如 MD5、SHA1、PKCS number 1 v1.5。
- 单独验证每个安全配置项的有效性。
3.注入攻击
在以下情况下，应用程序易受攻击：
- 应用程序不会验证、过滤或清洗用户提供的数据。
- 动态查询或无上下文感知转义的非参数化调用直接在解释器中使用。
- 恶意数据在对象关系映射（ORM）搜索参数中用于提取额外的敏感记录。
- 恶意数据被直接使用或连接。SQL或命令包含动态查询、命令或存储过程中的结构和恶意数据。
一些更常见的注入包括：SQL、NoSQL、OS命令、对象关系映射（ORM）、LDAP和表达式
语言（EL）或对象图导航库（OGNL）注入。这一概念在所有解析器中都是相同的。源代码审查是
检测应用程序是否易受注入攻击的最佳方法。强烈鼓励针对所有参数、标题、URL、cookies、
JSON、SOAP和XML数据输入的自动测试。组织可以在CI/CD管道中引入静态（SAST）、动态
（DAST）和交互式（IAST）应用程序安全测试工具，以在产品部署之前识别引入的注入缺陷。
预防措施
防止注入需要将数据与命令和查询分开：
- 推荐的选择是使用安全的API，这样可以避免完全使用解释器、提供参数化接口或迁移到对象关系
映射工具（ORM）。注意：即使参数化，如果PL/SQL或T-SQL将查询和数据连接起来，或者使用EXECUTE IMMEDIATE或exec（）执行恶意数据，则存储过程仍然可以引入SQL注入。 - 使用肯定（positive）或“白名单”服务器端输入验证。这并不是一种完美的防御，因为许多应用
程序需要特殊字符，例如移动应用程序中的文本区域或API。 - 对于任何残余的动态查询，请使用该解释器的特定转义语法转义特殊字符。注意：SQL结构（如表名、列名等）无法转义，因此用户提供的结构名是危险的。这是报表编写软件中的常见问题。
- 在查询中使用LIMIT和其他SQL控件，以防止在SQL注入的情况下大量披露记录。
4.不安全的设计
不安全设计是一个广泛的类别，代表不同的弱点，表示为“缺少或无效的控制设计”。不安全设计
不是所有其他前10个风险类别的来源。不安全设计和不安全的实现之间存在差异。我们区分设计缺陷和实现缺陷是有原因的，它们有不同的根本原因和补救措施。安全设计仍然可能存在实现缺陷，从而导致可能被利用的漏洞。一个不安全设计不能通过一个完美的实现来修复，因为根据定义，所需的安全控制从未被创建来抵御特定的攻击。导致不安全设计的因素之一是开发的软件或系统中缺乏固有的业务风险分析，因此无法确定需要何种级别的安全设计。
- 需求和资源管理
收集应用程序的业务需求并与业务部门协商，包括所有数据资产和预期业务逻辑的机密性、完整性、可用性和真实性方面的保护需求。考虑应用程序的公开程度，以及是否需要租户隔离（除访问控制外）。编制技术要求，包括功能性和非功能性安全要求。计划和协商所有设计、建造、测试和运营的预算，包括安全活动。 - 安全设计
安全设计是一种文化和方法，它不断评估威胁，并确保代码经过稳健的设计和测试，以防止已知的攻击方法。威胁建模应整合到细化会议（或类似活动）中；查看数据流和访问控制或其他安全控制中的更改。在用户故事开发中，确定正确的流程和故障状态，确保责任方和受影响方充分理解并同意这些状态。分析预期和故障流的假设和条件，确保其仍然准确和可取。确定如何验证正确行为所需的假设和实施条件。确保结果记录在用户故事中。从错误中吸取教训，并提供积极的激励以促进改进。安全设计既不是附加组件，也不是可以添加到软件中的工具。 - 安全开发生命周期
安全的软件需要安全开发生命周期、某种形式的安全设计模式、AppSec规划方法、安全的组件库、工
具和威胁建模。在整个项目和软件维护过程中，在软件项目开始时联系您的安全专家。考虑利用
OWASP软件保证成熟度模型（SAMM）来帮助构建您的安全软件开发工作
预防措施
- 与应用安全专业人员建立并使用安全的开发生命周期，以帮助评估和设计与安全和隐私相关的控制。
- 建立并使用安全设计模式的库，或使用AppSec规划中现有的要素。
- 对关键身份验证、访问控制、业务逻辑和密钥流使用威胁建模。
- 将安全语言和安全控制集成到用户故事中。
- 在应用程序的每一层（从前端到后端）集成合理性检查。
- 编写单元和集成测试，以验证所有关键流是否能够抵抗威胁模型。为应用程序的每一层编译正确用
例和误用案例。 - 根据暴露和保护需要，对系统层和网络层进行分层。
- 通过设计在所有层中严格隔离租户。
- 限制用户或服务的资源消耗。
5.安全配置错误
您的应用程序可能受到攻击，如果应用程序是：
- 应用程序栈的任何部分缺少适当的安全加固，或者云服务的权限配置错误。
- 应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、帐户或权限）。
- 默认帐户和密码仍然可用且没有更改。
- 错误处理机制向用户纰漏堆栈信息或其他大量错误信息。
- 对于升级的系统，最新的安全特性被禁用或未安全配置。
- 应用程序服务器、应用程序框架（如：Struts、Spring、ASP.NET）、库文件、数据库等没有进
行安全配置。 - 服务器不发送安全标头或指令，或未被设定安全参数。
- 您的应用软件已过期或易受攻击（参见“6:2021-脆弱和过时的组件”）。
缺少一个体系的、可重复的应用程序安全配置过程，系统将处于高风险中。
预防措施
应实施安全的安装过程，包括：
- 一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的耗费。
- 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功
能和框架。 - 检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分
（参见“6:2021-脆弱和过时的组件”）。在检查过程中，应特别注意云存储权限（如：S3桶权
限）。 - 一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括：分段、容器化和云安全组（ACL）。
- 向客户端发送安全指令，例如：安全标头。
- 一个能够验证所有环境中进行了正确的安全配置和设置的自动化过程。
6. 自带缺陷和过时的组件
如果满足下面的某个条件，那么您的应用就易受此类攻击：
- 如果您不知道所有使用的组件版本信息（包括：服务端和客户端）。这包括了直接使用的组件或间
接依赖的组件。 - 如果软件易受攻击，不再支持或者过时。这包括：系统、Web服务器、应用程序服务器、数据库
管理系统（DBMS）、应用程序、API和所有的组件、运行环境和库。 - 如果您没有定期做漏洞扫描和订阅使用组件的安全公告。
- 如果您不基于风险及时修复或升级底层平台、框架和依赖库。很可能发生这种情况：根据变更控制，每月或每季度进行升级，这使得组织在这段时间内会受到已修复但未修补的漏洞的威胁。
- 如果软件工程师没有对更新的、升级的或打过补丁的组件进行兼容性测试。
- 如果您没有对组件进行安全配置（参见“A05:2021–安全配置错误”)
预防措施
应制定一个补丁管理流程：
- 移除不使用的依赖、不需要的功能、组件、文件和文档。
- 利用如versions、OWASP Dependency Check、retire.js等工具来持续的记录客户端和服务器端
以及它们的依赖库的版本信息。持续监控如CVE和NVD等是否发布已使用组件的漏洞信息，可以
使用软件分析工具来自动完成此功能。订阅关于使用组件安全漏洞的警告邮件。 - 仅从官方渠道安全的获取组件，并使用签名机制来降低组件被篡改或加入恶意漏洞的风险 (参见
“A08:2021-软件和数据完整性故障”)。 - 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，可以考虑部署虚拟补丁来监控、检测或保护。
每个组织都应该制定相应的计划，对整个软件生命周期进行监控、评审、升级或更改配置。
7.身份识别和身份验证错误
允许像是攻击者已经拥有有效用户名称和密码列表的撞库自动化攻击。
- 允许暴力或其他自动化攻击。
- 允许预设、脆弱、常见的密码，像是"Password1"或"admin/admin"。
- 使用脆弱或无效的认证资讯回复或忘记密码的流程，如不安全的"知识相关问答"。
- 使用明码、被加密的或使用较脆弱杂凑法的密码(参考3: 2017-敏感性资料泄漏)。(TODO)
https://github.com/OWASP/Top10/issues/553 - 不具有或是无效的多因素认证。
- 于URL中泄漏会话(session) ID(如URL重写)。
- 成功登入后没有轮换会话(session) ID。
- 没 有 正 确 的 注 销 会 话 (session) ID。用 户 的 会 话(session)或 认 证tokens(主 要 是 单 一 登 入(SSO)token) 没有在登出时或一段时间没活动时被适当的注销
预防措施
- 在可能的情况下，实施多因素认证来防止自动化撞库攻击、暴力破解、以及遭窃认证资讯被重复
利用的攻击。 - 不要交付或部署任何预设的认证凭证，特别是管理者。
- 实施弱密码的检查，如测试新设定或变更的密码是否存在于前10000个最差密码清单。
- 将密码长度、复杂度和轮换政策与NIST 800-63b文件“第5.1.1节-被记忆的秘密或其他现代基于
证据的密码政策”的内容保持一致。 - 对所有结果使用相同的讯息回应，确保注册、认证凭据回复以及API路径能够抵御帐号枚举攻击。
- 限制或增加登入失败尝试的延迟。记录所有失败并于侦测到撞库、暴力破解或其他攻击时发出告
警。 - 使用服器端、安全的内建会话管理器，在登入后产生有高熵值的新随机会话ID。会话ID不应出现
在URL中，必须被安全的储存，并且在登出后、闲置、超时后被注销。
8. 软件和数据完整性故障
软件和数据完整性故障与无法防止违反完整性的代码和基础设施有关。这方面的一个例子是，
应用程序依赖于不受信任的源、存储库和内容分发网络（CDN）的插件、库或模块。不安全的
CI/CD管道可能会带来未经授权的访问、恶意代码或系统安全风险。最后，许多应用程序现在包括
自动更新功能。其中，更新包在没有进行充足完整性验证的情况下被下载，并应用于以前受信任的
应用程序。攻击者可能会上传自己的更新包，以便在所有安装上分发和运行。另一个例子是，对象
或数据被编码或序列化为攻击者可以看到和修改的结构，很容易受到不安全的反序列化的影响。
预防措施
- 使用数字签名或类似机制来验证软件或数据来自预期来源，且未被修改。
- 确保库和依赖项目，如：npm 或 Maven，正在使用受信任的存储库。如果您的风险较高，请考虑
托管一个经过审核的、内部已知合格的存储库。 - 确保使用软件供应链安全工具（如：OWASP Dependency Check 或 OWASP CycloneDX）来验
证组件不包含已知漏洞。 - 确保对代码和配置更改进行审核，以最大限度地减少恶意代码或配置引入软件管道的可能性。
- 确保您的CI/CD管道具有适当的隔离、配置和访问控制，以确保代码在构建和部署过程中的完整性。
- 确保通过特定形式的完整性检查或数字签名来检测序列化数据是否存在篡改或重播，所有未签名或
未加密的序列化数据不会发送到不受信任的客户端。
9.安全日志和监控故障
2021年版OWASP Top 10中，该类别是为了帮助检测、升级和应对活跃的违规行为。如果不进
行日志记录和监测，就无法发现违规行为。任何时候都会发生日志记录、检测、监视和主动响应不
足的情况:
- 需要审计的事件，例如：登录、失败的登录和高价值交易，但未记录。
- 警告和错误未生成日志或日志记录不充分或日志消息不清晰。
- 应用程序和 API的日志未进行安全可疑活动的监控。
- 日志只存储在本地。
- 适当的警报阈值和响应升级过程不到位或无效。
- 渗透测试和动态应用安全测试（DAST）工具（例如：OWASP ZAP）的扫描没有触发警报。
- 应用无法实时或接近实时地检测、升级或或对主动攻击发出警报。
- 如果让用户或攻击者看到日志和警报事件，您就容易受到信息泄露的攻击（查看“A01:2021-失
效的访问控制”）。
预防措施
开发人员应根据应用的风险，实施以下部分或全部控制：
- 确保所有的登录、访问控制和服务器端输入验证失败都可以被记录在足够的用户上下文中，以识别疑或恶意的帐户，并保留足够的时间以允许延迟的取证分析。
- 确保日志是日志管理解决方案以方便使用的格式生成的。
- 确保日志数据被正确编码加密，以防止对日志或监控系统的注入或攻击。
- 确保高价值交易有完整性控制的审计跟踪，以防止篡改或删除，例如：只附加数据库表或类似的内容。
- DevSecOps团队应该建立有效的监控和警报，以便发现可疑的活动并迅速做出反应。
- 建立或采用事故应对和恢复计划，例如：美国国家标准技术研究所(NIST)800-61r2或更高版本。
- 有一些商业和开源的应用程序保护框架，如：OWASP ModSecurity核心规则集，以及开源的日
志相关软件，如：Elasticsearch、Logstash、Kibana（ELK），具有自定义仪表盘和告警功能。
10.服务端请求伪造
一旦Web应用在获取远程资源时没有验证用户提供的URL，就会出现SSRF缺陷。它允许攻击
者强制应用程序发送一个精心构建的请求到一个意外目的地，即使是在有防火墙、VPN或其他类型
的网络访问控制列表（ACL）保护的情况下。
随着现代Web应用为终端用户提供便利的功能，获取URL成为一种常见的场景。因此，SSRF安
全攻击事件也在不断增加。此外，由于云服务和架构的复杂性，SSRF的严重性也越来越高。
预防措施
开发者可以通过实现以下部分或全部防御手段，纵深防御来阻止 SSRF:
网络层防御建议：
- 在隔离的网络中设置多个远程资源访问功能的网段，以减少SSRF的影响。
- 执行“默认拒绝”防火墙策略或网络访问控制规则，以阻止除必要的内部网通信外的所有通信。
提示:
建立基于应用的防火墙规则的所有权和生命周期。
在防火墙上记录所有接受和阻止的网络流(参见“A09:2021-安全日志和监控故障”)。
应用层防御建议：
- 检查和验证所有客户端提供的输入数据。
- 使用白名单允许列表允许列表执行URL统一资源标志符、端口和目标。
- 不要给客户端发送原始的回复。
- 禁用 HTTP 重定向。
- 注意URL的一致性，以避免DNS重新绑定和“检查时间，使用时间”(TOCTOU)竞争条件等攻击。
- 不要通过使用黑名单拒绝列表或正则表达式来缓解SSRF。攻击者拥有有效载荷列表、工具和绕过
拒绝列表的技能。
需额外考虑的措施:
- 不要在前端系统上部署其他与安全相关的服务（如：OpenID）。控制这些系统上的本地流量（如：
localhost）。 - 对于专用和可管理的前端用户，可以在独立系统上使用网络加密（如：vpn）来满足非常高的安全
保护需求。
|