OWASP TOP 10的风险分析、预防措施以及攻击范例（下）
OWASP TOP 10的风险分析以及预防措施（A04-A10）
A04：2021-不安全设计 Insecure Design
风险说明：
不安全设计是一个广泛的类别，代表不同的弱点，表示为“缺少或无效的控制设计”。不安全设计不是所有其他前10个风险类别的来源。不安全设计和不安全的实现之间存在差异。我们区分设计缺陷和实现缺陷是有原因的，它们有不同的根本原因和补救措施。安全设计仍然可能存在实现缺陷，从而导致可能被利用的漏洞。一个不安全设计不能通过一个完美的实现来修复，因为根据定义，所需的安全控制从未被创建来抵御特定的攻击。导致不安全设计的因素之一是开发的软件或系统中缺乏固有的业务风险分析，因此无法确定需要何种级别的安全设计。
- 需求和资源管理：收集应用程序的业务需求并与业务部门协商，包括所有数据资产和预期业务逻辑的机密性、完整性、可用性和真实性方面的保护需求。考虑应用程序的公开程度，以及是否需要租户隔离（除访问控制外）。编制技术要求，包括功能性和非功能性安全要求。计划和协商所有设计、建造、测试和运营的预算，包括安全活动。
- 安全设计：安全设计是一种文化和方法，它不断评估威胁，并确保代码经过稳健的设计和测试，以防止已知的攻击方法。威胁建模应整合到细化会议（或类似活动）中；查看数据流和访问控制或其他安全控制中的更改。在用户故事开发中，确定正确的流程和故障状态，确保责任方和受影响方充分理解并同意这些状态。分析预期和故障流的假设和条件，确保其仍然准确和可取。确定如何验证正确行为所需的假设和实施条件。确保结果记录在用户故事中。从错误中吸取教训，并提供积极的激励以促进改进。安全设计既不是附加组件，也不是可以添加到软件中的工具
- 安全开发生命周期：安全的软件需要安全开发生命周期、某种形式的安全设计模式、AppSec规划方法、安全的组件库、工具和威胁建模。在整个项目和软件维护过程中，在软件项目开始时联系您的安全专家。考虑利用OWASP软件保证成熟度模型（SAMM）来帮助构建您的安全软件开发工作。
预防措施：
- 与应用安全专业人员建立并使用安全的开发生命周期，以帮助评估和设计与安全和隐私相关的控制
- 建立并使用安全设计模式的库，或使用AppSec规划中现有的要素
- 对关键身份验证、访问控制、业务逻辑和密钥流使用威胁建模
- 将安全语言和安全控制集成到用户事故中
- 在应用程序的每一层（从前端到后端）集成合理性检查
- 编写单元和集成测试，以验证所有关键流是否能够抵抗威胁模型。为应用程序的每一层编译正确用例和误用案例
- 根据暴露和保护需要，对系统层和网络层进行分层
- 通过设计在所有层中严格隔离租户
- 限制用户或服务的资源消耗
攻击范例：
- 身份凭证恢复工作流可能包括NIST 800-63b、OWASP ASVS和OWASP Top 10中已禁止的“问题和答案”功能。 “问题和答案”不能作为可信的证据来证明身份，因为不止一个人知道答案，这就是为什么它们被禁止的原因。应删除此类代码，并用更安全的设计替换。
- 一家连锁电影院允许团体预订折扣，支持最多15名观众而不 要押金。攻击者可以对这种流量进行威胁建模，并测试他们是否可以在几个请求中同时预订600个座位和所有电影院，从而造成巨大的收入损失。
- 零售连锁店的电子商务网站没有针对黄牛党运行的机器人的保护，黄牛党购买高端显卡然后在拍卖网站上销售。这给显卡制造商和零售连锁店老板创造了糟糕的形象，并与那些无法以任何价格获得这些卡的爱好者产生了持久的伤害。适当的反机器人设计和域逻辑规则，例如在可用的几秒钟内进行的购买，可能会被识别为不可信的购买并拒绝此类交易。
A05：2021-安全配置错误 Security Misconfiguration
风险说明：
您的应用程序可能受到攻击，如果应用程序是：
- 应用程序栈的任何部分缺少适当的安全加固，或者云服务的权限配置错误
- 应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、帐户或权限）
- 默认帐户和密码仍然可用且没有更改
- 错误处理机制向用户纰漏堆栈信息或其他大量错误信息
- 对于升级的系统，最新的安全特性被禁用或未安全配置
- 应用程序服务器、应用程序框架（如：Struts、Spring、ASP.NET）、库文件、数据库等没有进行安全配置
- 服务器不发送安全标头或指令，或未被设定安全参数
- 您的应用软件已过期或易受攻击
缺少一个体系的、可重复的应用程序安全配置过程，系统将处于高风险中。
预防措施：
应实施安全的安装过程，包括：
- 一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的耗费
- 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。
- 检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分。在检查过程中，应特别注意云存储权限
- 一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括：分段、容器化和云安全组（ACL）
- 向客户端发送安全指令，例如：安全标头
- 一个能够验证所有环境中进行了正确的安全配置和设置的自动化过程
攻击范例：
- 应用程序服务器附带了未从产品服务器中删除的应用程序样例。这些样例应用程序具有已知的安全漏洞，攻击者利用这些漏洞来攻击服务器。假设其中一个应用程序是管理员控制台，并且没有更改默认账户，攻击者就可以通过默认密码登录，从而接管服务器。
- 目录列表在服务器端未被禁用。攻击者发现他们很容易就能列出目录列表。攻击者找到并下载所有已编译的Java类，他们通过反编译来查看代码。然后，攻击者在应用程序中找到一个严重的访问控制漏洞。
- 应用程序服务器配置允许将详细的错误信息（如：堆栈信息）返回给用户，这可能会暴露敏感信息或潜在的漏洞，如：已知含有漏洞的组件的版本信息
- 云服务提供商向其他CSP用户提供默认的网络共享权限。这允许攻击者访问存储在云端的敏感数据。
A06：2021-自带缺陷和过时的组件 Vulnerable and Outdated Components
风险说明：
如果满足下面的某个条件，那么您的应用就易受此类攻击：
- 如果您不知道所有使用的组件版本信息（包括：服务端和客户端）。这包括了直接使用的组件或间接依赖的组件
- 如果软件易受攻击，不再支持或者过时。这包括：系统、Web服务器、应用程序服务器、数据库管理系统（DBMS）、应用程序、API和所有的组件、运行环境和库
- 如果您没有定期做漏洞扫描和订阅使用组件的安全公告
- 如果您不基于风险及时修复或升级底层平台、框架和依赖库。很可能发生这种情况：根据变更控制，每月或每季度进行升级，这使得组织在这段时间内会受到已修复但未修补的漏洞的威胁
- 如果软件工程师没有对更新的、升级的或打过补丁的组件进行兼容性测试
- 如果您没有对组件进行安全配置
预防措施：
应制定一个补丁管理流程：
- 移除不使用的依赖、不需要的功能、组件、文件和文档
- 利用如versions、OWASP Dependency Check、retire.js等工具来持续的记录客户端和服务器端以及它们的依赖库的版本信息。持续监控如CVE和NVD等是否发布已使用组件的漏洞信息，可以使用软件分析工具来自动完成此功能。订阅关于使用组件安全漏洞的警告邮件
- 仅从官方渠道安全的获取组件，并使用签名机制来降低组件被篡改或加入恶意漏洞的风险
- 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，可以考虑部署虚拟补丁来监控、检测或保护
每个组织都应该制定相应的计划，对整个软件生命周期进行监控、评审、升级或更改配置。
攻击范例：
- 通常组件都是以与应用相同的权限运行的，这使得组件里的缺陷可能导致各式各样的问题。这些缺陷可能是偶然的（如：编码错误），也可能是蓄意的（如：组件里的后门）。下面是一些已被利用的漏洞：
CVE-2017-5638，一个Struts2远程执行漏洞。可在服务端远程执行代码，并已造成巨大的影响。
虽然物联网（IoT）设备一般难以通过打补丁来修复。但对它打补丁非常重要（例如：医疗设备）。
有些自动化工具能帮助攻击者发现未打补丁的或配置不正确的系统。例如：Shodan
IOT搜索引擎能帮助您发现从2014年4月至今仍存在心脏出血漏洞的设备。
A07：2021-身份识别和身份验证错误 Identification and Authentication Failures
风险说明：
- 允许像是攻击者已经拥有有效用户名称和密码列表的撞库自动化攻击
- 允许暴力或其他自动化攻击
- 允许预设、脆弱、常见的密码，像是"Password1"或"admin/admin"
- 使用脆弱或无效的认证资讯回复或忘记密码的流程，如不安全的"知识相关问答"
- 使用明码、被加密的或使用较脆弱杂凑法的密码(参考A3: 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中，必须被安全的储存，并且在登出后、闲置、超时后被注销
攻击范例：
- 使用已知列表密码的撞库攻击是一种常见的攻击方式，假设应用沒有实施自动化威胁或撞 库攻击的保护，在这种情況下，应用会被利用为密码预报的工具来判断认证凭据是否有效
- 大多数身份验证攻击都是由于密码作为单一因素持续使用而发生的。一旦考虑，最佳实践、密码轮换和复杂性要求鼓励用户使用和重用弱密码。建议组织按照NIST
800-63停止这些做法并使用多因素认证- 应用会话超时设置错误。一个用户使用公用电脑来访问应用时，用户没有选择“登出”而是简单的关闭浏览器标签页就离开。一小时后，一个攻击者使用同一个浏览器，而那个应用仍处于前面用户认证通过的状态
A08：2021-软件和数据完整性故障 Software and Data Integrity Failures
风险说明：
软件和数据完整性故障与无法防止违反完整性的代码和基础设施有关。这方面的一个例子是，应用程序依赖于不受信任的源、存储库和内容分发网络（CDN）的插件、库或模块。不安全的CI/CD管道可能会带来未经授权的访问、恶意代码或系统安全风险。最后，许多应用程序现在包括自动更新功能。其中，更新包在没有进行充足完整性验证的情况下被下载，并应用于以前受信任的应用程序。攻击者可能会上传自己的更新包，以便在所有安装上分发和运行。另一个例子是，对象或数据被编码或序列化为攻击者可以看到和修改的结构，很容易受到不安全的反序列化的影响。
预防措施：
- 使用数字签名或类似机制来验证软件或数据来自预期来源，且未被修改
- 确保库和依赖项目，如：npm 或 Maven，正在使用受信任的存储库。如果您的风险较高，请考虑托管一个经过审核的、内部已知合格的存储库
- 确保使用软件供应链安全工具（如：OWASP Dependency Check 或 OWASP CycloneDX）来验证组件不包含已知漏洞
- 确保对代码和配置更改进行审核，以最大限度地减少恶意代码或配置引入软件管道的可能性
- 确保您的CI/CD管道具有适当的隔离、配置和访问控制，以确保代码在构建和部署过程中的完整性
- 确保通过特定形式的完整性检查或数字签名来检测序列化数据是否存在篡改或重播，所有未签名或未加密的序列化数据不会发送到不受信任的客户端
攻击范例：
- 许多家庭路由器、机顶盒、设备固件和其他设备通过没有签名的固件进行更新。未签名固件是越来越多的攻击者的目标，预计情况只会变得更糟。这是一个主要问题，因为很多时候除了在未来的版本中修复和等待以前的版本过期之外，没有任何其他补救措施。
- 众所周知一种新的攻击机制，即，最近值得注意的SolarWinds Orion攻击。开发该软件的公司具有安全的构建和更新完整性流程。尽管如此，这些都能够被颠覆。几个月来，该公司向18,000多个组织分发了一个高度针对性的恶意更新，其中大约100个组织受到影响。这是历史上同类性质中影响最深远和最严重的违规行为之一。
- 一个React 应用程序调用一组Spring Boot 微服务。作为函数程序员，他们试图确保他们的代码是不可变的。他们提出的解决方案是将用户状态序列化，并在每个请求中来回传递。攻击者注意到“rO0”Java
对象签名（在 base64 中），并使用 Java Serial Killer工具在应用服务器上获取远程代码执行权。
A09：2021-安全日志和监控故障 Security Logging and Monitoring Failures
风险说明：
2021年版OWASP Top 10中，该类别是为了帮助检测、升级和应对活跃的违规行为。如果不进行日志记录和监测，就无法发现违规行为。任何时候都会发生日志记录、检测、监视和主动响应不足的情况:
- 需要审计的事件，例如：登录、失败的登录和高价值交易，但未记录
- 警告和错误未生成日志或日志记录不充分或日志消息不清晰
- 应用程序和 API的日志未进行安全可疑活动的监控
- 日志只存储在本地
- 适当的警报阈值和响应升级过程不到位或无效
- 渗透测试和动态应用安全测试（DAST）工具（例如：OWASP ZAP）的扫描没有触发警报
- 应用无法实时或接近实时地检测、升级或或对主动攻击发出警报
- 如果让用户或攻击者看到日志和警报事件，您就容易受到信息泄露的攻击（查看“A01:2021-失 效的访问控制”）
预防措施：
开发人员应根据应用的风险，实施以下部分或全部控制：
- 确保所有的登录、访问控制和服务器端输入验证失败都可以被记录在足够的用户上下文中，以识别可疑或恶意的帐户，并保留足够的时间以允许延迟的取证分析
- 确保日志是日志管理解决方案以方便使用的格式生成的
- 确保日志数据被正确编码加密，以防止对日志或监控系统的注入或攻击
- 确保高价值交易有完整性控制的审计跟踪，以防止篡改或删除，例如：只附加数据库表或类似的内容
- DevSecOps团队应该建立有效的监控和警报，以便发现可疑的活动并迅速做出反应
- 建立或采用事故应对和恢复计划，例如：美国国家标准技术研究所(NIST)800-61r2或更高版本
- 有一些商业和开源的应用程序保护框架，如：OWASP ModSecurity核心规则集，以及开源的日志相关软件，如：Elasticsearch、Logstash、Kibana（ELK），具有自定义仪表盘和告警功能
攻击范例：
- 一家儿童健康计划供应商的网站运营者由于缺乏安全监控和记录而无法发现漏洞。一个外部团体告知儿童健康计划供应商，某恶意攻击者已经获取并修改了超过350万儿童的数千份敏感健康记录。事后审查发现，网站开发人员没有修复重大漏洞。由于没有对系统进行日志记录或监控，因此数据泄露可能自2013年以来一直在进行，时间超过7年
- 印度一家大型航空公司发生数据泄露事件，涉及数百万乘客十多年的个人信息，包括护照和信用卡信息。数据泄露发生在一家第三方云托管服务提供商，该提供商在一段时间后通知了航空公司此次泄露事件。
- 欧洲一家大型航空公司遭遇一起可报告的GDPR违规事件。据报道，攻击者利用支付应用程序的安全漏洞，获取了超过40万客户的支付记录，从而导致了此次攻击。该航空公司因此被隐私监管机构处以2000万英镑的罚款
A10：2021-服务端请求伪造 Server-Side Request Forgery
风险说明：
一旦Web应用在获取远程资源时没有验证用户提供的URL，就会出现SSRF缺陷。它允许攻击者强制应用程序发送一个精心构建的请求到一个意外目的地，即使是在有防火墙、VPN或其他类型的网络访问控制列表（ACL）保护的情况下。
随着现代Web应用为终端用户提供便利的功能，获取URL成为一种常见的场景。因此，SSRF安全攻击事件也在不断增加。此外，由于云服务和架构的复杂性，SSRF的严重性也越来越高
预防措施：
开发者可以通过实现以下部分或全部防御手段，纵深防御来阻止SSRF:
网络层防御建议：
- 在隔离的网络中设置多个远程资源访问功能的网段，以减少SSRF的影响。
- 执行“默认拒绝”防火墙策略或网络访问控制规则，以阻止除必要的内部网通信外的所有通信。
- Tips：建立基于应用的防火墙规则的所有权和生命周期、在防火墙上记录所有接受和阻止的网络流
应用层防御建议：
- 检查和验证所有客户端提供的输入数据
- 使用白名单允许列表允许列表执行URL统一资源标志符、端口和目标
- 不要给客户端发送原始的回复
- 禁用 HTTP 重定向
- 注意URL的一致性，以避免DNS重新绑定和“检查时间，使用时间”(TOCTOU)竞争条件等攻击
- 不要通过使用黑名单拒绝列表或正则表达式来缓解SSRF。攻击者拥有有效载荷列表、工具和绕过拒绝列表的技能
需额外考虑的措施:
- 不要在前端系统上部署其他与安全相关的服务（如：OpenID）。控制这些系统上的本地流量（如：localhost）
- 对于专用和可管理的前端用户，可以在独立系统上使用网络加密（如：）来满足非常高的安全保护需求
攻击范例：
- 如果网络架构未进行网络隔离，攻击者可以访问并绘制出内部网络地图，并根据连接结果或SSRF有效载荷连接的运行时间和拒绝时间判 断内部服务器端口是打开还是关闭
- 攻击者可以访问本地文件或内部服务，以获得敏感信息，例如： file:///etc/passwd http://localhost:28017/
- 大多数云服务提供商都有元数据存储，比如：通过http://169.254.169.254/访问。攻击者可以通过读取元数据来获取敏感信息。
- 攻击者可以滥用内部服务进行进一步的攻击，比如：远程代码执行（RCE）或者拒绝服务攻击（DoS）