使用Postman破解API|api漏洞挖掘方法|渗透测试技巧

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧

技能树, 渗透测试, 漏洞, 黑客技术

Detectify Crowdsource不是一般的漏洞赏金平台。这是一个由最优秀的道德黑客组成的仅限邀请的社区，他们热衷于保护现代技术和最终用户。众包黑客Hakluke和Farah Hawa在这个访客博客上联手讨论了黑客和防御者如何（安全地）破解 API 以帮助使互联网更安全。

Baaackkk iiin myyy dayyyyy API 不像现在那么普遍。这是由于单页应用程序 (SPA) 的流行。10 年前，Web 应用程序倾向于遵循这样一种模式，即大多数应用程序在呈现给用户之前在服务器端生成。任何需要的数据都将由生成 UI 的同一台服务器直接从数据库中收集。它可能看起来像这样：

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧
10年前的Web应用模型

许多现代 Web 应用程序倾向于遵循通常称为 SPA（单页应用程序）的不同模型。在这个模型中，通常有一个 API 后端、一个 JavaScript UI 和数据库。API 只是作为 web 应用程序和数据库之间的接口。对 API 的所有请求都是直接从 Web 浏览器发出的。

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧
现代 Web 应用程序倾向于遵循通常称为 SPA 的不同模型

这通常是一个更好的解决方案，因为它更容易扩展并允许更专业的开发人员在项目上工作，即前端开发人员可以在前端工作，而后端开发人员则在 API 上工作。这些应用程序也往往感觉更快速，因为不是每个请求都需要页面加载。

相反，同一页面的不同组件会神奇地更新，给人一种与原生应用程序类似的感觉。这种模型也变得越来越流行，因为 100 亿 ⁽ᶜᶦᵗᵃᵗᶦᵒⁿ ⁿᵉᵉᵈᵉᵈ⁾ 不同的前端 JavaScript 框架（React、Vue 和 Angular 等）已经出现。持怀疑态度的人可能会得出结论，当今可用的 JavaScript 框架数量之多可笑，这是 Illuminati 煽动的旨在减缓 webapp 开发进度的协调尝试。不过这可能不是真的。

这就是说——现在到处都有 API，所以我们应该知道如何破解和保护它们。如果你还在阅读——你的手指可能会悬停在 ctrl+w 上。你的大脑在想“这篇文章的标题承诺教我黑客，而不是什么是 SPA。我是一个知识分子，作者的幽默尝试是徒劳的，生命短暂，我正在浪费时间阅读这个傻瓜的……” 拿着它！我们快到了。我保证。冷却您的喷气式飞机。

设置测试 API

Postman 是一个方便的应用程序，它使 API 安全测试变得轻而易举。您可以从其官方网站下载 Postman 。 本质上，Postman 只是另一个 HTTP 客户端，可用于轻松修改并向 API 发送请求。

如果您在文件中有一组 API 请求，您可以通过单击应用程序左上角的“导入”按钮将它们导入 Postman ：

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧

导入集合后，您将看到 Postman 中加载的 API 调用，如下所示： 

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧

通过单击单个 API 调用，将在右侧看到完整的 API 请求。此外，请求的不同部分将被分解为Params、Authorization、Headers、Request Body等部分。这将使您可以轻松地处理每个部分。

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧

由于 Postman 专门用于 API，因此您有许多内置选项来测试 API 中主要存在的功能。例如，通过单击请求方法旁边的下拉箭头，您可以看到大量不同的请求动词以进行测试：

Postman 中的响应视图看起来像这样，响应也分为不同的部分，如正文、Cookie、标题等，因此您可以仔细分析每个部分。

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧

由于 Postman 专门用于 API，因此您有许多内置选项来测试 API 中主要存在的功能。例如，通过单击请求方法旁边的下拉箭头，您可以看到大量不同的请求动词以进行测试：

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧

对于 GET 请求，您可以通过Params选项卡添加/删除以及编辑参数。当您选中/取消选中参数时，您可以看到它们相应地出现在 URI 字段中。

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧

在添加授权值时，Postman 为您提供了多种选项供您选择，您可以根据目标 API 处理授权的方式选择一个。

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧
使用Postman破解API|api漏洞挖掘方法|渗透测试技巧

您还可以按照以下步骤将授权值添加到整个集合或子集合：

1-单击集合/子集合名称旁边的三个点，然后选择“编辑”选项

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧

2-转到“授权”选项卡，选择身份验证类型并添加其值。

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧

3-最后，转到单个 API 请求并选择Inherit auth from parent选项

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧

这将为您省去为每个请求设置授权值的麻烦。

Postman 的另一个方便的特性是它允许用户使用 BurpSuite 代理 API 请求。为了进行设置，您需要执行以下步骤：

1:从右上角的下拉菜单中单击设置选项

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧

2:转到代理选项卡并执行以下操作：

  • 关闭使用系统代理
  • 打开添加自定义代理配置
  • 设置了 代理服务器的IP地址和端口，以配合您打嗝套房代理设置。默认值为 127.0.0.1 和 8080。
    您的最终设置应如下所示：
使用Postman破解API|api漏洞挖掘方法|渗透测试技巧

3:要在没有任何错误的情况下代理 HTTPS 请求，您可以在“常规”选项卡下关闭SSL 证书验证。

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧

API 漏洞的类型

API 有多种形状和大小，攻击 API 的方法会因这些形状和大小而有很大差异。在一个博客中涵盖所有攻击类型是不可能的，但我们将介绍其中的一堆！

API 暴露

与 Web 应用程序非常相似，API 可以具有不同级别的可见性。有些可以通过互联网访问，而有些则只能在内部使用。更基本的 API 黑客之一就是简单地访问您应该无法访问的 API。这可以通过多种方法来实现，包括：

  • 强制浏览：如果幸运的话，供内部使用的 API 可能会意外暴露在 Internet 上，这可能是由于配置错误，或者仅仅是因为假设没有人能够找到它。API 位置可以通过多种方式发现，包括分析 JavaScript 文件、分析暴露的源代码、观察主机名（例如 api.internal.example.com）和 Google dorking。
  • 旋转：在外部主机上发现像 SSRF 这样的漏洞可能允许您转向内部 API。

缓解措施

有许多最佳实践可以帮助减轻无意暴露 API 的风险，包括实施严格的部署实践、通过 IAM 和网络分段强制执行最小权限原则。

错误配置的缓存

对于需要身份验证的 API，返回的数据通常是动态的，并且范围限定为每个 API 密钥。例如，/api/v1/userdetails以 Bob 身份访问应返回 Bob 的详细信息，而以 Jane 身份访问同一端点应返回 Jane 的详细信息。

当 API 不使用标准Authorization标头，而是使用自定义标头（如X-API-Key. 缓存服务器可能不会将此识别为经过身份验证的请求，并且可能会缓存它。

如果是这种情况，并且没有Cache-Control或Pragma标题，则简单地访问/api/v1/userdetails可能会泄露另一个用户的信息。

缓解措施

对此的解决方法是实现Cache-Control或Pragma标头并使用标准Authorization标头。

暴露的令牌

我们不应该忽视最基本的身份验证黑客。通过任何方式发现 API 密钥可能会为您提供对 API 的访问权限。更糟糕的是，供内部使用的 API 通常不需要实现复杂的身份验证流程，因此可以实现静态令牌作为其身份验证。可以在代码存储库、客户端 JavaScript、拦截流量等中发现秘密令牌。

缓解措施

在您的 DevOps 管道中实施代码扫描通常会在 API 密钥部署到它们不应该存在的地方之前捕获它们。一些代码存储库提供者（包括GitHub）还能够在推送 API 密钥之前检测它们。

JWT的弱点

如果您的 API 令牌是由两个点 (.) 分隔的三个 base64 blob，则它可能是一个JSON Web 令牌 (JWT)。像许多事情一样，这些令牌在理论上是安全的，但是有很多方法会以引入安全问题的方式来弄乱实现。在我们深入研究 JWT 攻击之前，我们将快速阅读 JWT 入门。 

这是一个示例 JWT 令牌，根据您的审美欣赏进行了着色：

使用Postman破解API|api漏洞挖掘方法|渗透测试技巧
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

有三个由点分隔的 base64 编码字符串，第一部分（红色）是header. 第二个（紫色）是payload，第三个（蓝色）是signature。

如果我们解码第一部分，也称为标头，我们将看到以下内容

{
"alg":"HS256",
"typ":"JWT"
}

这概述了我们使用的算法 (HS256) 和令牌类型 (JWT)。如果您之前没有使用过 JWT，您可能会想“为什么我们需要算法？” . 我们很快就会到达那里！

如果我们解码第二部分，也称为有效载荷，我们将看到以下内容：

{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}

此部分可以包含任何内容，但至少需要包含某种用户标识符和超时 (iat)。

第三部分（也称为签名）用密钥对前两部分进行签名。在这种情况下，它使用 HS256 算法进行签名，这可以通过查看标头中的“alg”值来确定。这个想法是密钥应该只为应用程序的所有者知道。当应用程序收到 JWT 令牌时，它可以通过解密签名并将其与标头和有效负载中的数据进行比较来验证令牌是否合法。如果数据匹配则数据被验证，否则它是无效的。

那么为什么会有人使用 JWT？这是因为它不需要服务器端会话管理。传统上，当用户登录时，应用程序会为用户分配一个秘密令牌并将该令牌存储在数据库中。每当用户使用他们的令牌发出请求时，应用程序需要检查令牌是否在数据库中。如果是，则允许用户继续，否则不允许。

当我们使用 JWT 时，我们引入了一种信任从客户端发送的数据的方法，而不是仅仅信任存储在数据库中的信息。如果应用程序收到可以使用密钥验证的 JWT 令牌，则应用程序没有理由不信任它。

正如我们之前提到的，理论上 JWT 令牌是完全安全的。问题是它们通常以不安全的方式实施。这里有些例子：

  • None 算法：JWT 的一些实现将允许您指定“None”作为算法。如果算法为“无”，应用程序将不会检查签名的有效性，因此您可以简单地将有效负载更新为您想要的任何内容。最明显的利用是将用户 ID 更新为另一个用户以控制他们的帐户。
  • 暴力破解：可以暴力破解 JWT 令牌的密钥。这种攻击的可行性将取决于密钥的强度。您可以尝试使用此工具破解 JWT 令牌。可以在Auth0 的博客上找到有关该方法的完整文章。
  • 简单地改变有效载荷：在极少数情况下，服务器可能会完全跳过令牌验证并信任有效载荷中的数据。虽然我没有亲眼见过这种情况，但我已经读到它发生在野外！
  • 将 RS 切换到 HS：一些较旧的 JWT 库存在一个缺陷，您可以在其中欺骗期望使用非对称加密签名的令牌的应用程序接受对称签名的令牌。最终被使用的对称签名令牌实际上是一个公钥，它通常可以以某种方式获得，或者从他们的 HTTPS 密钥中重用。有这种方法的一个伟大的书面记录在这里。
  • 在超时未兑现，那么JWT令牌仍然有效，直到永远。iat

缓解措施

JWT 弱点的最佳缓解方法是为所有 JWT 操作使用广泛使用的、信誉良好的 JWT 库。

授权问题/IDOR

授权是检查经过身份验证的用户是否有权访问特定用户的过程。与授权相关的常见漏洞称为不安全的直接对象引用 (IDOR)。例如，在发票应用程序的 API 中，我们可能有一个端点用于获取发票的详细信息：

/api/v1/invoices/?id=1234

该id参数是应返回的发票的标识符。如果这个端点是安全的，我应该只能获得属于我的发票的详细信息。例如，如果我创建了一个 ID 为 1234 的发票，那么它应该返回详细信息。如果我尝试访问不是通过浏览创建的发票/api/v1/invoices/?id=1233，它应该返回错误。

如果我能够更改标识符以查看其他用户的发票详细信息，这就是一个称为 IDOR 的漏洞。

为了解决 IDOR 问题，当今许多 API 都使用 UUID 作为对象标识符。UUID 如下所示：

f1af4910-e82f-11eb-beb2-0242ac130002

需要注意的是，使用 UUID 作为标识符并不是缓解 IDOR 问题的有效方法。事实上，UUID RFC特地将这一点称为：

不要假设 UUID 很难猜测；例如，它们不应该用作安全功能（仅拥有就可以访问的标识符）。可预测的随机数源会加剧这种情况。

虽然将 UUID 用作对象 ID 而不是整数是一种很好的做法，但它们永远不应用作抵御 IDOR 攻击的唯一保护措施。

缓解措施

授权问题通常很难以自动化方式检测。代码库的结构应该以难以在特定端点上发生授权错误的方式设置。为实现这一点，应尽可能在堆栈上实施授权措施。可能在类级别，或使用中间件。

未记录的端点

遇到您攻击的 API 没有文档（或至少没有您可以访问的文档）的情况是很常见的。带有文档的 API 具有超出文档内容的端点也很常见。有时，这些端点的存在本身可能是一个安全问题——例如，端点可能是为管理目的而设计的，并允许您作为弱势用户执行管理任务。其他时候，这些端点可能会出现漏洞，因为它们没有像容易发现的端点那样经过彻底的测试。

我们可以利用以下几种方法来发现未记录的端点：

  • 使用与 API 接口的应用程序并捕获流量。也许目前最常用的工具是 Burp Suite。 
    • 设置 Burp Suite 来代理应用程序流量
    • 使用所有应用程序功能
    • 通过查看目标选项卡检查使用的端点。
  • 观察错误。许多 API 会给出足够详细的错误来枚举未记录的端点和参数。例如，向 发送一个空白的 POST 请求/api/v1/randomstring可能会导致出现类似Invalid route, valid routes are [/users,/invoices,/customers].
  • 分析客户端 JavaScript。如果您知道与 API 交互的应用程序，您可以分析该应用程序中的 JavaScript 以收集可访问的 API 端点列表。
  • 使用Kiterunner，这是Assetnote 的一个工具，专为 API 上的内容发现而设计
  • 暴力破解端点，Assetnote 网站上有一些优秀的API词表
httparchive_apiroutes_2020_11_20.txt95301145.3mb2021 年 5 月 28 日晚上 9:30下载
httparchive_apiroutes_2021_01_28.txt2254566.6mb2021 年 5 月 28 日晚上 9:30下载
httparchive_apiroutes_2021_02_28.txt2235446.5mb2021 年 5 月 28 日晚上 9:30下载
httparchive_apiroutes_2021_03_28.txt2151146.3mb2021 年 5 月 28 日晚上 9:30下载
httparchive_apiroutes_2021_04_28.txt2176226.3mb2021 年 5 月 28 日晚上 9:30下载
httparchive_apiroutes_2021_05_28.txt2200746.4mb2021 年 5 月 28 日晚上 9:30下载
httparchive_apiroutes_2021_06_28.txt2239656.5mb2021 年 6 月 28 日晚上 8:21下载
httparchive_aspx_asp_cfm_svc_ashx_asmx_2020_11_18.txt632001.7mb2021 年 5 月 28 日晚上 9:30下载
httparchive_aspx_asp_cfm_svc_ashx_asmx_2021_01_28.txt46286928.7kb2021 年 5 月 28 日晚上 9:30下载
httparchive_aspx_asp_cfm_svc_ashx_asmx_2021_02_28.txt43958883.3kb2021 年 5 月 28 日晚上 9:30下载
httparchive_aspx_asp_cfm_svc_ashx_asmx_2021_03_28.txt45928926.8kb2021 年 5 月 28 日晚上 9:30下载
httparchive_aspx_asp_cfm_svc_ashx_asmx_2021_04_28.txt45430917.3kb2021 年 5 月 28 日晚上 9:30下载
httparchive_aspx_asp_cfm_svc_ashx_asmx_2021_05_28.txt46447958.5kb2021 年 5 月 28 日晚上 9:30下载
httparchive_aspx_asp_cfm_svc_ashx_asmx_2021_06_28.txt45921947.3kb2021 年 6 月 28 日晚上 8:21下载
httparchive_cgi_pl_2020_11_18.txt263744.0kb2021 年 5 月 28 日晚上 9:30下载
httparchive_cgi_pl_2021_01_28.txt223329.5kb2021 年 5 月 28 日晚上 9:30下载
httparchive_cgi_pl_2021_02_28.txt207827.2kb2021 年 5 月 28 日晚上 9:30下载
httparchive_cgi_pl_2021_03_28.txt219628.7kb2021 年 5 月 28 日晚上 9:30下载
httparchive_cgi_pl_2021_04_28.txt217528.6kb2021 年 5 月 28 日晚上 9:30下载
httparchive_cgi_pl_2021_05_28.txt216128.4kb2021 年 5 月 28 日晚上 9:30下载
httparchive_cgi_pl_2021_06_28.txt214228.0kb2021 年 6 月 28 日晚上 8:45下载
httparchive_directories_1m_2020_11_18.txt100000030.1mb2021 年 5 月 28 日晚上 9:30下载
httparchive_directories_1m_2021_01_28.txt67368618.0mb2021 年 5 月 28 日晚上 9:30下载
httparchive_directories_1m_2021_02_28.txt67070817.9mb2021 年 5 月 28 日晚上 9:30下载
httparchive_directories_1m_2021_03_28.txt67554718.0mb2021 年 5 月 28 日晚上 9:30下载
httparchive_directories_1m_2021_04_28.txt67503118.0mb2021 年 5 月 28 日晚上 9:30下载
httparchive_directories_1m_2021_05_28.txt67495018.1mb2021 年 5 月 28 日晚上 9:30下载
httparchive_directories_1m_2021_06_28.txt67286518.0mb2021 年 6 月 28 日晚上 8:50下载
httparchive_html_htm_2020_11_18.txt1940085.0mb2021 年 5 月 28 日晚上 9:30下载
httparchive_html_htm_2021_01_28.txt1141272.3mb2021 年 5 月 28 日晚上 9:30下载
httparchive_html_htm_2021_02_28.txt1069952.1mb2021 年 5 月 28 日晚上 9:30下载
httparchive_html_htm_2021_03_28.txt1141052.3mb2021 年 5 月 28 日晚上 9:30下载
httparchive_html_htm_2021_04_28.txt1132612.2mb2021 年 5 月 28 日晚上 9:30下载
httparchive_html_htm_2021_05_28.txt1143042.3mb2021 年 5 月 28 日晚上 9:30下载
httparchive_html_htm_2021_06_28.txt1135572.3mb2021 年 6 月 28 日晚上 8:22下载
httparchive_js_2020_11_18.txt4319406171.8mb2021 年 5 月 28 日晚上 9:31下载
httparchive_js_2021_01_28.txt156980328.6mb2021 年 5 月 28 日晚上 9:30下载
httparchive_js_2021_02_28.txt150894927.6mb2021 年 5 月 28 日晚上 9:30下载
httparchive_js_2021_03_28.txt160686729.3mb2021 年 5 月 28 日晚上 9:30下载
httparchive_js_2021_04_28.txt160738129.3mb2021 年 5 月 28 日晚上 9:30下载
httparchive_js_2021_05_28.txt163055429.8mb2021 年 5 月 28 日晚上 9:31下载
httparchive_js_2021_06_28.txt164641930.1mb2021 年 6 月 28 日晚上 8:45下载
httparchive_jsp_jspa_do_action_2020_11_18.txt10506212.9kb2021 年 5 月 28 日晚上 9:30下载
httparchive_jsp_jspa_do_action_2021_01_28.txt10096166.8kb2021 年 5 月 28 日晚上 9:31下载
httparchive_jsp_jspa_do_action_2021_02_28.txt9866162.7kb2021 年 5 月 28 日晚上 9:31下载
httparchive_jsp_jspa_do_action_2021_03_28.txt10125166.8kb2021 年 5 月 28 日晚上 9:31下载
httparchive_jsp_jspa_do_action_2021_04_28.txt10085166.0kb2021 年 5 月 28 日晚上 9:31下载
httparchive_jsp_jspa_do_action_2021_05_28.txt10289169.2kb2021 年 5 月 28 日晚上 9:31下载
httparchive_jsp_jspa_do_action_2021_06_28.txt10248168.9kb2021 年 6 月 28 日晚上 8:21下载
httparchive_parameters_top_1m_2020_11_21.txt81507912.9mb2021 年 5 月 28 日晚上 9:31下载
httparchive_parameters_top_1m_2021_01_28.txt2812512.9mb2021 年 5 月 28 日晚上 9:31下载
httparchive_parameters_top_1m_2021_02_28.txt2792922.9mb2021 年 5 月 28 日晚上 9:31下载
httparchive_parameters_top_1m_2021_03_28.txt2841302.9mb2021 年 5 月 28 日晚上 9:31下载
httparchive_parameters_top_1m_2021_04_28.txt2851682.9mb2021 年 5 月 28 日晚上 9:31下载
httparchive_parameters_top_1m_2021_05_28.txt2862533.0mb2021 年 5 月 28 日晚上 9:31下载
httparchive_parameters_top_1m_2021_06_28.txt2883993.0mb2021 年 6 月 28 日晚上 8:16下载
httparchive_php_2020_11_18.txt748871.7mb2021 年 5 月 28 日晚上 9:31下载
httparchive_php_2021_01_28.txt616211.0mb2021 年 5 月 28 日晚上 9:31下载
httparchive_php_2021_02_28.txt58685983.3kb2021 年 5 月 28 日晚上 9:31下载
httparchive_php_2021_03_28.txt618471.0mb2021 年 5 月 28 日晚上 9:31下载
httparchive_php_2021_04_28.txt616651.0mb2021 年 5 月 28 日晚上 9:31下载
httparchive_php_2021_05_28.txt614411.0mb2021 年 5 月 28 日晚上 9:31下载
httparchive_php_2021_06_28.txt614691.0mb2021 年 6 月 28 日晚上 8:21下载
httparchive_subdomains_2020_11_18.txt153797628.4mb2021 年 5 月 28 日晚上 9:31下载
httparchive_subdomains_2021_01_28.txt122745316.4mb2021 年 5 月 28 日晚上 9:31下载
httparchive_subdomains_2021_02_28.txt111844114.8mb2021 年 5 月 28 日晚上 9:31下载
httparchive_subdomains_2021_03_28.txt123415416.4mb2021 年 5 月 28 日晚上 9:31下载
httparchive_subdomains_2021_04_28.txt122840116.4mb2021 年 5 月 28 日晚上 9:31下载
httparchive_subdomains_2021_05_28.txt126014116.9mb2021 年 5 月 28 日晚上 9:31下载
httparchive_subdomains_2021_06_28.txt127175117.1mb2021 年 6 月 28 日晚上 8:58下载
httparchive_txt_2020_11_18.txt6260138.9kb2021 年 5 月 28 日晚上 9:31下载
httparchive_txt_2021_01_28.txt524889.0kb2021 年 5 月 28 日晚上 9:31下载
httparchive_txt_2021_02_28.txt487183.5kb2021 年 5 月 28 日晚上 9:31下载
httparchive_txt_2021_03_28.txt502285.7kb2021 年 5 月 28 日晚上 9:31下载
httparchive_txt_2021_04_28.txt498385.7kb2021 年 5 月 28 日晚上 9:31下载
httparchive_txt_2021_05_28.txt523091.3kb2021 年 5 月 28 日晚上 9:31下载
httparchive_txt_2021_06_28.txt534694.5kb2021 年 6 月 28 日晚上 8:46下载
httparchive_xml_2020_11_18.txt8969168.5kb2021 年 5 月 28 日晚上 9:31下载
httparchive_xml_2021_01_28.txt7811132.7kb2021 年 5 月 28 日晚上 9:31下载
httparchive_xml_2021_02_28.txt7543127.9kb2021 年 5 月 28 日晚上 9:31下载
httparchive_xml_2021_03_28.txt7990136.4kb2021 年 5 月 28 日晚上 9:31下载
httparchive_xml_2021_04_28.txt7940135.3kb2021 年 5 月 28 日晚上 9:31下载
httparchive_xml_2021_05_28.txt7760133.0kb2021 年 5 月 28 日晚上 9:31下载
httparchive_xml_2021_06_28.txt7890135.3kb2021 年 6 月 28 日晚上 8:46下载

你可以使用如下命令一次性下载所有的密码字典

wget -r --no-parent -R "index.html*" https://wordlists-cdn.assetnote.io/data/ -nH

缓解措施

拥有一个强大的、结构化的方法和流程来记录 API 功能可以避免很多麻烦。Swagger正是这一点的绝佳标准。此外，最好在编码之前用文档规划 API 功能，而不是相反。

不同版本

当一个组织发布一个 API 时，它可能会与许多不同的应用程序接口。如果 API 在任何时候更新，它可能会为这些应用程序中的一个或多个引入重大更改。出于这个原因，多个 API 版本通常被实现为支持旧 API 模式的一种方式，同时也随着时间的推移为新用户升级 API。

值得测试 API 的所有版本。旧版本可能仍然存在已在新版本中修复的安全问题，而较新的/前沿/测试版可能引入了新的安全问题。

api 版本控制的常见模式是：

/api/v1/
/api/v2/
/api/beta/

检查非生产路线名称总是值得的，例如：

qa
devenv
devenv1
devenv2
preprod
pre-prod
test
testing
staging
stage
dev
development
deploy
slave
master
review
prod
uat
prep
Version2

该词表取自DNSCewl 中的示例集。

缓解措施

可以通过定义的生命周期支持 API 版本。例如，当您发布 API 的第 2 版时，您可能会通知您的用户第 1 版将达到生命周期终止 (EoL) 并在未来的特定日期被弃用。预生产/测试版只有在经过彻底的安全问题测试后才能公开访问。

限速

大多数情况下，API 对用户可以请求它们的次数没有任何保护。这被称为“缺乏速率限制”，当攻击者可以调用 API 数千次以导致一些意外行为时，就会发生这种情况。服务器将尝试满足这些请求中的每一个，这可能会：

  • 通过使用请求重载服务器来对服务器进行 DOS 处理
  • 允许攻击者快速泄露敏感的用户信息，例如：用户 ID、用户名、电子邮件等。
  • 通过强制登录 API 绕过身份验证
  • 通过强制向受害者发送电子邮件/短信的功能来淹没受害者的收件箱

让我们看一个攻击场景，其中对检查凭据的 API 端点没有速率限制：

GET /api/v1/user/1234/login/?password=mypassword

通常，您不会看到这样在 GET 请求中发送的密码，但出于本演示的目的，假设您看到了。为了在上面的端点中暴力破解密码，攻击者可以使用BurpSuite 的 Intruder工具。这个工具允许我们自定义不同类型的蛮力攻击，但在这个例子中，我们将提供一个简单的密码列表。

在几秒钟内，Intruder 将发出数百个 API 请求，对每个请求尝试不同的密码。

GET /api/v1/user/1234/login/?password=notmypassword1
GET /api/v1/user/1234/login/?password=notmypassword2
GET /api/v1/user/1234/login/?password=notmypassword3
.
.
.
GET /api/v1/user/1234/login/?password=correctpassword!

由于没有速率限制，服务器会很乐意为所有这些请求提供响应，攻击者可以继续尽快暴力破解不同的密码，直到找到正确的密码。

为了防止速率限制错误，应用程序应该对用户在特定时间范围内请求 API 的频率实施限制。设置的确切限制将取决于该 API 或端点的用例。

缓解措施

速率限制可以通过许多不同的方式实现。每个帐户、每个 IP 地址、每个端点、整个 API 等。一些反向代理也可用于实现应用程序范围的节流，而无需额外开发。您使用的确切实现将取决于您的特定应用程序的要求。

竞争条件

竞争条件是在同一毫秒内向 API 发送两个或多个请求。当 API 没有处理这种情况的机制时，可能会导致 API 以意外的方式处理请求。

在易受攻击的电子商务应用程序上兑换折扣或促销代码时，可能会出现竞争条件的潜在攻击场景。 

POST /api/v1/discount
Target: www.ecommerce.com
Connection: close

{
"code","first10",
"amount":"10"
}

BurpSuite 有一个名为Turbo Intruder的扩展，它允许用户使用内置race.py脚本测试条件竞争。

在 Turbo Intruder 中配置攻击后，攻击者可以向 API 发送多个并发请求以兑换此促销代码。

POST /api/v1/discount		200 OK
POST /api/v1/discount		200 OK
POST /api/v1/discount		200 OK
POST /api/v1/discount		404 Not Found
POST /api/v1/discount		404 Not Found

如果 API 在收到第一个并发请求后没有立即使促销代码失效，则折扣金额可能会增加一倍、三倍等。

这种攻击被称为“条件竞争”，因为它是攻击者发送修改资源请求的速度与应用程序更新该特定资源的速度之间的竞争。

缓解措施

不幸的是，缓解竞争条件问题通常意味着牺牲性能。缓解竞争条件的方法包括利用锁和其他线程安全功能。大多数编程语言都内置了线程安全功能，但通常需要手动指定。

XXE注入

XXE 代表XML 外部实体，这个注入漏洞可以在任何使用 API 处理 XML 数据的地方进行测试。SOAP API 也可能容易受到 XXE 注入的影响，因为它们基于 XML。 

使用 XML 的 API 端点如下所示：

POST /soap/v2/user HTTP/1.1
Host: example.com
Content-Type: text/xml


 <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE dtd[<!ENTITY username SYSTEM "https://example.com/?username">]>
<SOAP-ENV:Envelope>
<SOAP-ENV:Body>
<getUser>
<id>&username;</id>
</getUser>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

XML 文档使用实体来表示单个数据对象，而 XML 文档类型定义 (DTD) 用于定义要使用的实体、文档的结构等。

XXE 注入是指攻击者注入指定 DTD 之外的自定义外部实体。一旦这些外部实体被 API 解析，攻击者就可以访问应用程序的内部文件，升级到 SSRF，将敏感数据泄漏到攻击者控制的域或 DOS 服务器。

这是一个请求示例，其中攻击者注入了一个名为 xxe 的外部自定义实体，该实体的目的是检索内部文件：

POST /soap/v2/user HTTP/1.1
Host: example.com
Content-Type: text/xml

 <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE aa [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<SOAP-ENV:Envelope>
<SOAP-ENV:Body>
<getUser>
<id>&xxe;</id>
</getUser>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

如果 API 允许使用标准 XML 解析器来处理数据，那么这个注入的外部实体将被应用程序处理并将其内容返回/etc/passwd给攻击者。

缓解措施

确保使用的 XML 解析器设置为不解析 XML 实体。

切换内容类型

即使 API 可能使用 JSON 作为数据格式进行通信，底层服务器/框架仍可能接受其他数据格式，如 XML。因此，当您看到带有content-Typeof的 API 时application/json，您仍然可以尝试通过将其值切换为 XXE 来测试 XXE Content-Type: text/xml

例如，如果 API 使用 JSON：

POST /api/v1/user HTTP/1.1
Host: example.com
Content-Type: application/json

可以修改它以这种方式发送 XML 数据：

POST /soap/v2/user HTTP/1.1
Host: example.com
Content-Type: text/xml

 <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE aa [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>

缓解措施

此错误仅存在于旨在接受多种格式的框架上，其中每种格式对应一种对象。在这些情况下，框架通常可以选择将可用格式列入白名单。应该指出的是，这在 2021 年非常罕见。

HTTP 方法

API 通常支持各种类型的 HTTP 方法。一些常见的是GET，POST，PATCH，DELETE和OPTIONS。如果一个GET请求在其中的应用程序需要一个POST请求点发送，那么这可能会导致应用程序以意想不到的方式回应。

我们以CSRF为例。CSRF（跨站点请求伪造）是指攻击者诱使受害者提交请求，从而导致受害者帐户发生状态更改操作。这些更改可以是更改受害者的个人详细信息，在某些情况下，甚至更改受害者的密码导致帐户完全接管。

更改受害者个人详细信息的正常请求可能如下所示：

POST /api/v1/user
Target: www.example.com
Content-Type: application/json

{
  "name","victim", 
  "email":"[email protected]", 
  "location":"AU", 
  "csrftoken":"76hhs683bki0"
}

观察上述请求后，我们可能会得出结论，CSRF 攻击是不可能的，因为该csrftoken值是在请求正文中发送的。但是，如果 API 不限制可用于此请求的 HTTP 方法，则攻击者可能会通过使用 GET 方法发送此请求来绕过此保护。

GET /api/v1/user?name=hacked&[email protected]&location=FR
Target: www.example.com
Connection: close

此外，有时服务器根本不验证 CSRF 令牌，或者如果请求中根本不存在 CSRF 令牌参数，则接受请求。

REST API 中的另一个常见漏洞是在端点上正确应用了权限，但仅适用于一个 HTTP 动词。例如，您可能无法 GET 其他人的记录，但您可以使用 PATCH 动词来编辑他们的记录。

缓解措施

在路由中手动指定 HTTP 动词。不要不必要地使用动词，并确保指定的任何端点确实对所有动词应用了相同的控制。某些框架会自动执行此操作，而其他框架则不会。

注入漏洞

服务器端注入缺陷，如 SQL 注入、RCE、命令注入和SSRF，可以像在常规 Web 应用程序中一样存在于 API 中。每当任何注入的数据直接传递给后端的解释器时，就会为攻击者发送有针对性的查询和命令以访问内部数据或执行任意代码留下空间。

例如，让我们在以下 API 请求上测试 SSRF：

POST /api/v1/user
Target: www.example.com
Content-Type: application/json

{
  "name","victim", 
  "email":"[email protected]", 
  "profile_pic_url":"https://www.example.com/me.jpg"
}

攻击者可以在website通过发送如下请求在现场尝试 SSRF ：

POST /api/v1/user
Target: www.example.com
Content-Type: application/json

{
  "name","victim", 
  "email":"[email protected]", 
  "profile_pic_url":"http://localhost/admin"
}

如果后端解释器没有profile_pic_url正确验证该值，那么这可能导致攻击者利用 SSRF 并成功访问内部数据。

同样，如果此请求中的数据未正确验证，攻击者也可以尝试 SQL 注入：

POST /api/v1/orders
Target: www.example.com
Content-Type: application/json

{
  "offset":0,
  "limit":10,
  "scope":"orders_all",
}

通过查看请求正文，我们可能会提示这些参数的值正在发送到后端数据库解释器。因此，我们可以通过将这些值修改为目标查询来尝试 SQL 注入：

POST /api/v1/orders
Target: www.example.com
Content-Type: application/json

{
  "offset":0,
  "limit":10,
  "scope":"SELECT sleep(10)",
}

再一次，如果解释器没有正确验证这些值，那么这可能会导致 SQL 注入，攻击者可能会导致数据库中的时间延迟，甚至泄露敏感数据。

缓解措施

缓解 API 中的注入漏洞本质上与缓解 Web 应用程序中的注入漏洞相同。SAST/DAST 扫描器可以帮助解决这个问题，但安全开发实践是最好的缓解措施。参数化 SQL 查询，尽可能使用 ORM 和信誉良好的库，不要相信用户输入的任何内容！

from

Leave a Reply

您的邮箱地址不会被公开。 必填项已用 * 标注