Noname API Security Workshop

1. Explore your Akamai API Security instance

Overview Page

浏览 Akamai API 安全概览页面。点击左上角的 Akamai 图标即可导航至该页面。概览页面有各种小部件，以不同的方式总结安全问题：

• 按严重性分类的结果：结果的严重性取决于多种因素，这些因素根据 API 服务发现的态势结果确定该服务的总体风险。点击严重性级别可查看该级别所有结果的筛选列表。点击左上角的 Akamai 图标可返回上一个视图。
• 攻击者组（过去 30 天）：攻击者组提供了对攻击者不同状态的洞察：未识别、正在调查、已阻止和已监控。点击攻击者组可查看该类型攻击者的筛选问题列表。单击左上角的 Akamai 图标返回上一个视图。
• OWASP API 安全 Top 10 2023：安全问题数量映射到 OWASP API 安全 Top 10 2023。发现和运行时事件是故意分开的。单击 OWASP 表中的任意数字以筛选该类型的特定问题。请注意，本次研讨会将重点关注特定的 OWASP Top 10 API 漏洞，即排名第一的条目 - 损坏的对象级授权或 BOLA。
• 运行时事件（过去 30 天）：此图表显示过去 30 天内检测到的运行时事件数量。将鼠标移到线上可查看特定日期的事件计数。图表下方显示了事件类型列表。单击任何事件类型可查看该类型的事件的筛选列表。单击左上角的 Akamai 图标可返回上一个视图。
• 攻击者（过去 30 天）：此图表显示过去 30 天内发现的攻击者数量。将鼠标移到线上可查看特定日期的攻击者数量。
• 态势发现：此图表显示在发现的 API 上检测到的态势发现数量。将鼠标移到线上可查看特定日期的发现数量。图表下方显示发现类型列表。单击任何发现类型可查看该类型的发现的筛选列表。单击左上角的 Akamai 图标可返回上一个视图。

Findings Page

单击Findings可浏览Findings页面。每个发现都有相关的风险级别（严重、高、中、低或信息）和模块（Posture、Recon）。Findings由在环境中检测到的错误配置组成。每个发现都会显示检测时间、触发的 API（如果有多个 API，也可能显示Environment）、状态、OWASP Top 10 API 标签和 API 所有者。在研讨会的这个阶段，页面上将显示多个发现。

Filters（位于屏幕右侧）可应用于发现列表，可以通过单击屏幕顶部Views下拉列表旁边的蓝色磁盘图标保存这些发现以供以后查看。 Columns（也在屏幕右侧）可以显示或删除，并用于自定义组视图。您还可以使用搜索框搜索所有字段。您已保存的任何自定义视图都可以从仪表板顶部的Views下拉列表中选择。

选择发现类型并展开它，直到您看到填充了检测时间的行。这些是单独的发现。单击Finding可查看该发现的详细信息。发现详细信息包含有关发生了什么、为什么这是个问题以及补救步骤的易于理解的信息。单击Evidence按钮可查看与发现相关的取证证据。请注意，某些发现可能没有启用证据按钮，因为发现通常不是攻击，因此没有要查看的会话。弱密码等发现将启用证据按钮，这将向您显示已识别密码的列表。您还可以通过时间线对该发现发表评论、分享发现、下载发现详情、更改发现状态并对该发现采取行动（取决于您启用的工作流集成）。

Incidents Page

单击Runtime -> Incidents以浏览Incidents页面。每个事件都有相关的风险级别（严重、高、中、低或信息）。Incidents由使用 API 检测到的异常组成。每个事件都会显示检测时间、触发的 API（如果有多个 API，这也可以显示环境）、状态、事件结果（尝试或成功）、响应代码、OWASP Top 10 API 标签、攻击者置信度分数、攻击者标识符类型、国家/地区、IP 信誉和 API 所有者。此时，研讨会中可能不存在运行时事件。

Filters（位于屏幕右侧）可应用于事件列表，单击屏幕顶部Views下拉列表旁边的蓝色磁盘图标即可保存事件列表以供日后查看。Columns（也在屏幕右侧）可显示或删除，并用于自定义组视图。您还可以使用搜索框搜索所有字段。您已保存的任何自定义视图都可以从仪表板顶部的Views下拉列表中选择。

选择事件类型并展开它，直到看到填充了检测时间的行。这些是单个事件。单击Incidents可查看该事件的详细信息。事件详细信息包含易于理解的信息，包括发生了什么、为什么会出现问题以及补救步骤。 点击“Evidence”按钮可查看与该事件相关的取证证据。您还可以通过时间线对该事件发表评论、分享该事件、下载事件详细信息、更改事件状态、对该事件采取行动（取决于您启用的工作流集成）、查看攻击者信息（以及其他相应的攻击者问题），并最终阻止该攻击者。阻止与活动集成相关联，并将与现有的内联基础设施（如 WAF、负载平衡器或 API 网关）配合使用，以根据攻击者的 IP 地址、有效负载标头、cookie 和/或用户令牌/标识符阻止恶意流量。

Attackers Page

点击Runtime -> Attackers可浏览Attackers页面。正如之前在问题页面中看到的，攻击者有一个关联的 IP 地址、标头、cookie 或用户令牌/标识符，可用于根据您启用的集成来阻止该攻击者。由于攻击者很少只关注一个 API 端点，因此“攻击者”页面中的每个条目都会向 Akamai API 安全管理员显示与该攻击者相关的单个问题数量。

可以显示或删除列，并且可以构建过滤器以创建特定视图。您还可以使用搜索框搜索攻击者，并将其添加到允许列表以静音相关问题

Inventory Page

现在导航到页面顶部的 Inventory 标签

Stats Page

浏览Stat页面，了解 API 的数量和类型，以及基于分类和标签在这些 API 中找到的数据。您还可以根据 API 的身份验证或分类类型深入研究它们。

API Page

浏览在您的环境中发现的 API 的完整列表和详细信息。此列表包含每个 API 的主机、方法和路径以及其他属性。可以根据一个或多个属性过滤 API。要过滤这些 API，请选择表格右侧的“Filters”按钮。例如，尝试过滤来自特定流量源集成、面向互联网且没有身份验证的所有 API。查看请求和响应字段中的数据类型。

单击屏幕顶部Views下拉列表旁边的蓝色磁盘图标，可以保存应用于 API 清单的过滤器以供以后查看。过滤器也可以保存为新组或用于策略。可以显示或删除列并保存自定义组视图。可以从此仪表板下载 OpenAPI 规范，并打开 Swagger UI 以详细查看 API 规范。您还可以使用搜索框搜索 API。

单击 API 以查看该 API 的详细信息。

Changes Page

浏览Changes页面。此页面显示在您的环境中发现的任何增量。跟踪的更改包括新 API、字段更改、数据类型和基于先前对环境的了解而确定的标题。

可以显示或删除列，并可以构建过滤器以创建特定视图。您还可以使用搜索框搜索更改仪表板，并配置平台以在发现新 API 时收到通知。

单击Change条目并查看与该更改相关的详细信息。详细信息页面中有一个指向相关 API 的链接。该 API 的架构以 OpenAPI 规范格式显示。如果您熟悉 GIT 符号和颜色编码，您将熟悉绿色突出显示（已添加）和红色突出显示（已删除）条目。

Datatypes Page

浏览Datatypes页面。此页面显示 API 中自动识别的所有数据类型。数据类型基于开箱即用的正则表达式模式（IP 地址、信用卡号、社会保险号等）或用户自定义的正则表达式模式。

您可以使用搜索框搜索数据类型，也可以使用Manage按钮跳转到数据类型设置仪表板来创建和编辑数据类型。

单击Datatypes以过滤 API 清单，从而仅查看包含该数据类型的 API。可以使用Tages对数据类型进行分组，从而提高警报和审计 (DLP) 的灵活性。用户可以添加多个开箱即用的标准标签（敏感、PCI、PII、凭据等）和自定义标签。平台标配的标签与计算与资产和问题相关的风险级别的算法相关联。

单击Datatypes，然后单击Manage按钮。请注意，您现在位于Settings部分（由页面右上方突出显示的齿轮表示）。在这里，您可以创建新的自定义Datatype、数据类型Tags或自动Data Policy，以针对您的 API 处理的数据启用 DLP。

创建自定义数据类型、标签和策略

我们现在将创建自定义数据类型以突出显示 Noname 的 DLP 功能。请按照以下说明操作：

自定义 DataType 和 Tag

1. 点击Create DataType按钮，输入firstname+lastinitial-dt作为Datatype Name。例如：michaelj-dt
2. 从下拉菜单中选择一个Icon
3. 从下拉菜单中选择一个Tag
4. 点击右上角的“X”删除FILTER by FIELD NAME选项
5. 选择+Add Filter by Field Value按钮
6. 将Filter by Field Value正则表达式设置为不属于您注册的电子邮件地址的随机单词；例如：.*pineapplejuice.*
7. 可选择Obfuscate datatype
8. 可选择Ignore Headers
9. 单击Save

Custom Data Policy

1. 单击Data Policies按钮，然后单击Create Data Policy按钮
2. 输入策略名称并选择严重性
3. 选择root组，以便所有 API 都应用此数据策略
4. 向下滚动到Conditions，注意Where条件已设置为Datatype。保留此设置
5. 对于In的值，选择Both，以便将策略应用于请求和响应
6. 对于Is any of，选择您之前定义的自定义数据类型

您现在已配置适用于清单中所有 API 的自定义数据策略

2. 探索并与 crAPI Web 界面互动

crAPI 概述

在社区贡献者的帮助下，OWASP 率先推出了 Completely Ridiculous API (crAPI) 服务，旨在提高人们对其十大 API 列表中十大最关键 API 安全风险的认识。crAPI 在设计上存在漏洞，我们在这里使用它，是因为它被普遍接受为真实世界 API 漏洞的准确表示。

可选：浏览 crAPI Web 服务的 github 页面：

https://github.com/OWASP/crAPI

可选：探索 crAPI 网络和 API 服务所面临的挑战：

https://github.com/OWASP/crAPI/blob/develop/docs/challenges.md

探索 crAPI Web 应用程序

1. 在新的浏览器选项卡中启动 crAPI 的实验室实例。您将进入Dashboard页面。
2. 浏览Dashboard页面。请注意嵌入的 Google 地图，其中显示了您的车辆的位置。

2. 点击Shop探索商店

3. 点击Community浏览社区页面
4. 点击+New Post添加新帖子。为其添加标题和说明，然后点击Add New Post。
5. 点击任何不属于您自己的社区帖子。点击*Add Comment并添加新评论

3. 探索并与 crAPI API 互动

现在让我们开始与支持 crAPI Web 应用程序的 API 进行交互。

crAPI APIs

Completely Ridiculous API (crAPI) 服务可能看起来像一个简单的 Web 服务，但与当今的许多现代应用程序一样，它增加了一组 API 服务（端点），用于接收和提供由客户端浏览器呈现的数据。正如您之前在 Noname 系统中探索的那样，它们由商店、身份和社区 API 服务组成。我们将通过使用浏览器的检查模式来探索这些 API 调用。

1. 导航到 crAPI Dashboard 页面
2. 右键单击页面上的任意位置（谷歌地图除外），然后选择Inspect。新的 Web 浏览器Inspect窗格显示在浏览器底部或右侧
3. 在Inspection窗格中，点击Network，然后点击FETCH/XHR (Chrome) 或XHR (Firefox)

4. 在主浏览器窗口中，刷新 crAPI Dashboard 页面。Inspection 窗格现在应该包含数据。
5. 在 Inspection 窗格中，单击 Dashboard 项。在该视图中，单击 Headers 和 Response 以分别查看标头和响应。

6. 点击Response页面，查看 crAPI Web App 从Dashboard API 调用收到的数据。点击Inspection窗格底部的{} 括号，以易于阅读的格式呈现结果

7. 让我们看看是否可以访问 dashboard API URL 并获取响应数据（包括敏感用户信息），而无需使用任何身份验证（和授权）。从 Headers 部分复制 Request URL，并将其粘贴到新的浏览器选项卡中。

8. 切换到浏览器中的 crAPI 仪表板选项卡，在 Inspect 窗格中，注意仪表板 API 的标头页面的 Authorization 字段的值。我们将从此会话中“借用”此令牌以访问 API 并请求数据。该值以 Bearer 开头，后跟一长串数字和字母。

9. 在您的工作站上，打开 Postman 并登录 Postman 应用程序（如果需要）。可选择创建一个新的个人类型的 Postman 工作区。
10. 单击 [+] 符号 以启动新选项卡。将其保留为 GET 请求。
11. 将 Request URL 从 Headers 部分粘贴到 URL 框中。这是您刚刚在新浏览器选项卡中尝试的 URL。
12. 单击 Headers 选项卡，并使用 Key Authorization 创建一个新选项卡，并将 Inspection 窗格中的承载令牌粘贴到其中。回想一下，此值必须以单词“Bearer”开头，后跟一长串数字和字母。
13. 单击 Send。您应该会看到邮递员请求成功。
14. 如果尚未选择，请单击 Body以查看 API 响应的结果。您已成功访问为 crAPI 仪表板 页面提供支持的 API 并收到返回数据。

12. 返回您的网络浏览器，探索当您点击 crAPI Dashboard页面时发生的其他 API 调用。具体来说，点击地图下方的 Refresh Location。

13. 在 Inspection 窗格中，单击 location API 服务进行探索

14. 在 Inspection 窗格中，单击 location API 的 Response 选项

4. 使用 BOLA 攻击 crAPI 服务

至此，我们已经了解了很多有关 location API 服务的知识：

• URL 需要一个无法猜测的 carID 参数，并且该参数对于每个用户+车辆都是唯一的
• 当使用有效的 carID 参数调用时，API 会返回车辆的地理位置。

对以下 API URL 的请求：

https://<partner>.nnsworkshop.com/identity/api/v2/vehicle/{CAR_ID}/location

Returns:

CopyCopy

{
  "carId": "{CAR ID}",
  "vehicleLocation": {
    "id": 3,
    "latitude": "{SOME LATITUDE}",
    "longitude": "{SOME LONGITUDE}"
  },
  "fullName": "{SOMEONE'S FULL NAME}"
}

现在让我们去寻找一些与其他用户关联的 carID，这样我们就可以访问他们的车辆位置，即使我们无权查看它（BOLA）。如果我们幸运的话，我们在整个 web+API 应用程序中看到的过度数据暴露将泄露一些可供我们用作攻击者的信息。

1. 在 crAPI 浏览器选项卡中，单击 Contact Mechanic按钮。您是否在那里的 API 响应中看到与 carID 相关的任何内容？

2. 在 crAPI 浏览器选项卡中，单击 Shop。查看 API 及其响应数据。那里有泄漏的 carID 吗？
3. 在 crAPI 浏览器选项卡中，单击 Community，然后在 Inspection 窗格中选择 recent API。看到什么了吗？BINGO

4. 让我们继续对 location API 服务进行攻击。由于我们必须使用授权承载令牌进行测试，因此我们将切换回使用 Postman 和我们在上一个活动中用于仪表板的 GET 请求选项卡。
5. 在 Inspection 窗格中，单击 location API 服务并选择 Headers。复制 Request URL 并粘贴到 Postman 中，替换上一个仪表板练习中现有的 URL。将其保留为 GET 请求。
6. 在 Postman 中，将粘贴的 URL 中的 car_id 参数替换为另一个用户的 carID。您可以在 Response 页面上的 recent API 服务的 Inspection 窗格中找到另一个 carID。请记住，在发出此 API 请求时，您仍将使用自己的授权承载令牌。

参考: https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa1-broken-object-level-authorization.md

“泄漏”API 与 BOLA 漏洞相结合，使我们能够访问他人车辆的位置信息。让我们看看现实世界中泄漏 API 如何给知名公司和个人造成严重破坏的例子。

2021 年 5 月：Peloton 环境中的泄漏 API 使任何人都可以访问骑手的私人帐户数据

https://techcrunch.com/2021/05/05/peloton-bug-account-data-leak/

让我们看看现实世界中存在泄漏 API 的例子。

2020 年 9 月：澳航环境中存在泄漏的 API 暴露了托尼·阿博特的护照详细信息

https://www.theguardian.com/australia-news/2020/sep/16/former-australian-pm-tony-abbotts-passport-details-and-phone-number-obtained-by-hacker

2021 年 10 月：密苏里州中小学教育部 (DESE) 教育工作者认证搜索工具泄露了每位教师的社会安全号码

https://ritcyberselfdefense.wordpress.com/2024/02/19/remember-that-time-missouri-leaked-the-social-security-numbers-of-every-single-teacher/

5. 自动化 BOLA 攻击

现在我们已经成功手动攻击此 API 并检索到单个位置，让我们尝试大规模利用该漏洞。

1. 在 Postman 中，使用脚本登录 crAPI 服务，方法是单击 00-Sign Ups and Login，选择 Login请求，然后单击蓝色 Send按钮。这将允许您收到一个新的授权承载令牌，Postman 将自动处理该令牌以用于后续请求。具体来说，它将作为全局变量部分中的环境变量填充，然后可以由 BOLA 自动化脚本使用。
2. 展开 API01:2019 Broken Object Level Authorization 文件夹，然后单击 Get Vehicle IDs。
3. 为应对攻击，单击 Postman 屏幕底部的 Console 按钮，打开底部控制台屏幕。
4. 要查看自动攻击的代码，请点击 API 请求中的Tests

3. 点击 API01:2019 Broken Object Level Authorization 文件夹右侧的三个点按钮，然后选择Run Collection。在新屏幕上，保留找到的参数，然后点击橙色Run按钮。
4. 在 Postman 控制台中，查看此攻击的结果。向下滚动到底部可查看所有仪表板+位置 URL，其中 VehicleID 参数已自动填充。展开其中一个条目可查看成功检索位置数据的响应主体。

6. 在 Noname 中查看 BOLA 检测

Akamai API Security 应该能够捕获您刚刚执行的自动 BOLA 攻击。让我们回顾一下相关的运行时事件。

1. 切换回 Noname 平台浏览器
2. 点击“安全 -> 运行时 -> 事件”，查找“Internet-Facing API with Broken Object Level Authorization”问题类型。
3. 如果尚未展开，请展开问题类型并点击与您的攻击相关的问题以查看其详细信息。

4. 在事件详细信息中，点击 Evidence按钮并查看显示用户活动的事件时间线，包括在相关事件之前和期间访问了哪些资源。证据中的每一行代表一个 API 事务。点击各行将调整底部显示的请求和响应。

5. 要遏制此 BOLA 攻击，请关闭证据视图，然后单击Take Action -> Block Attacker。您可以轻松地从此页面阻止攻击者，但由于这是一个可能包含来自许多学生的许多 BOLA 的研讨会，因此让我们找到要阻止的特定用户/IP。单击Runtime -> Attackers按钮。
6. 在攻击者左侧列表中找到您的用户电子邮件，选中与您的活动相对应的攻击者活动行的复选框，然后单击Take Action。在Actions下，勾选Block Attacker的复选框。将计数保留为 5 分钟，然后勾选aws-prevention的复选框，然后单击Submit。 Noname 平台现在将指示 AWS WAF 阻止您的 IP 地址。

7. 尝试向 crAPI 服务发出另一个 Postman 请求以测试阻止。这可以是任何请求，例如步骤 1 中的登录请求。您应该看到 WAF 拒绝了流量。您必须等待 5 分钟（默认）才能访问 crAPI 服务，因为阻止规则是计时器（用户可在阻止启动期间调整）。
8. 除了 BOLA 之外，还提出了另一个 ML 检测到的问题：Internet-Facing API Access Attempt With Missing Authentication。为什么这是一个基于机器学习的问题，而不仅仅是检测到有人收到 401 错误？在这种情况下，平台会指出有人试图在省略 授权标头的情况下访问 API。这只有当用户绕过我们的 Web 应用程序或移动应用程序时才有可能，这使得这种行为极其可疑。当我们通过将 API 调用复制到浏览器中的另一个选项卡来测试 API 是否确实强制执行身份验证时，触发了此问题。

恭喜您完成针对易受攻击的应用程序的自动 API 安全攻击！

7. 对数据进行分类并触发 DLP 违规

接下来，我们将返回 API 服务处理的数据的数据类型和 DLP。

1. 在 Postman, 点击 Create Post 00-Sign Ups collection
2. 点击 Body 部分 查看您正在准备的 API 请求的正文
3. 回想一下，您之前使用 REGEX VALUE 字词在 Noname 中创建了一个自定义数据类型。修改 Content 值 (This is my POST) 以包含与您的正则表达式匹配的字符串。例如，如果您的正则表达式为 .*pineapplejuice.*，则将内容更新为 This is my POST about pineapplejuice!
4. 点击 Send.

5. 在 Akamai API 安全浏览器中， 点击 Inventory, 然后点击 Datatypes 页签. 您注意到您的数据类型出现了吗？点击您的数据类型即可查看与该数据类型相关的 API。
6. 现在 点击 Security -> Findings. 您是否看到与您的数据类型相对应的Data Policy Violation类型的问题？

DLP 活动到此结束.

8. Active Testing

Akamai API Security Active Testing 模块可帮助开发人员使用 DevOps 原则自动执行 API 安全测试，使用他们已用于单元/集成测试等任务的管道。这种“左移”到软件开发生命周期有助于确保业务逻辑问题永远不会影响生产。

配置应用程序源

1. 要配置主动测试，我们首先需要 API 集合的规范。在此处下载规范: https://<partner>.nnsworkshop.com/guide/crapi-spec.json
2. 通过点击Testing（位于 Noname 信息中心顶部）导航至“主动测试”
3. 通过点击+New Application按钮创建新应用
4. 设置 application name 为 crAPI - <your name>, 设置 Base URL 为 https://<partner>-crapi.nnsworkshop.com, 将App Location保留在All Applications，随意添加一些标签或将该字段留空，然后单击下一步
5. 扫描仪需要了解 API 的功能要求。为了发现这一点，我们将添加一个 Open API 规范作为源。
6. 在 Source Name 字段中，输入一个值，例如 oas，并将 Source Type 字段保留为 OpenAPI / Swagger (REST)。将 Import Method 单选按钮保留为 File，单击 Choose File，然后单击 upload new file（位于弹出窗口的底部）。选择您之前下载的要上传的 Open API 规范文件，然后单击弹出窗口中的文件名以将其选中用于配置。最后，单击 Next

配置 Application Secrets

现在我们已经添加了源，我们需要设置供 Active Testing 使用的身份验证配置文件。身份验证对于对 API 进行更智能和更有针对性的测试是必不可少的。为了为 API 提供身份验证，我们将利用 Postman 集合从 crAPI 应用程序中为 Jane Doe 和 John Smith 生成动态令牌。这些令牌由 Active Testing 自动获取，并存储为secrets。secrets在测试阶段用作 Authorization 标头中的身份验证令牌。

首先让我们创建我们的“Jane Doe” secrets。

1. 点击 Open Secrets Manager

2. 点击 + Add Secret

3. 设置 secret name 为 Jane Doe
4. 设置 secret type 为 Postman Collection. 将出现附加字段
5. 从以下链接下载 Jane Doe 身份验证 Postman 集合。接下来，在Collection File下拉菜单中，上传您刚刚检索到的文件。请注意将其上传到Collection File而不是Environment File。本实验不需要Environment File https://<partner>.nnsworkshop.com/guide/janeDoe.postman_collection.json

6. 设置 Secret Location 为 Body
7. 在 JSON Path 框中，输入 $.token

Jane Doe 密钥的配置到此结束，但我们还需要添加一个密钥。不要单击“保存”，而是继续执行以下步骤。

让我们添加“John Smith” secret

1. 点击 + Add Secret

2. 设置 secret name 为 John Smith
3. 设置 secret type 为 Postman Collection. 将出现附加字段
4. 从以下链接下载 John Smith 身份验证 Postman 集合。接下来，在Collection File下拉菜单中，上传您刚刚检索到的文件。请注意将其上传到Collection File而不是Environment File。本实验不需要Environment File https://<partner>.nnsworkshop.com/guide/johnSmith.postman_collection.json

5. 设置 Secret Location 为 Body
6. 在 JSON Path 框中，输入 $.token

7. 这样就完成了两个身份验证密钥的配置。点击 Save。Secret Manager 现在显示我们刚刚创建的两个密钥

配置 Jane Doe Authentication Profile

现在已将 Active Testing 配置为检索和存储用于以 Jane 或 John 进行身份验证的密钥。接下来，我们必须将 Active Testing 配置为在与受测应用程序交互时使用这些机密。这是通过身份验证配置文件控制的。

1. 在 General 下， 将 Authentication Name 设置为 Jane Doe，并将角色保留为 Reader / Writer.
2. 在映射部分将Type设置为Header，并将Key 设置为 Authorization
3. 在 Value 部分，输入 Bearer @。当您输入 @ 符号时，您应该会看到一个包含我们秘密的下拉菜单弹出。选择 Jane Doe

选择密钥后:

配置 John Smith Authentication Profile

1. 点击 + Add Auth
2. 在 General 下， 将 Authentication Name 设置为 John Smith,，并将角色保留为 Reader / Writer.
3. In the Mappings section set the Type to Header and the Key 设置为 Authorization
4. 在 Value 部分，输入 Bearer @。当您输入 @ 符号时，您应该会看到一个包含我们秘密的下拉菜单弹出。 选择 John Smith

选择密钥后:

5. 点击 Complete

使用主动测试扫描应用程序

现在配置已经完成，我们开始第一次扫描

1. 点击 Scan Application

Akamai API Security Active Testing 将自动解析已上传的 OpenAPI Spec 文件，清点要测试的 API，发现 API 之间的关系以及每个 API 所需的身份验证。

扫描状态将更改为 Pending，然后是 Scanning ，然后是 Finalizing，然后是 Passed

2. 单击扫描选单以查看结果

解决 Unreachable APIs

1. 点击 Inventory 在主动测试窗口顶部

在左上角的小部件中，您可能会注意到 Active Testing 已将多个 API 标记为unreachable。这表明该工具无法自动确定如何正确与 API 交互。解决此问题很重要；为了正确测试安全性，您必须知道如何成功与端点交互，否则，您将看到与安全问题无关的故障，而是与一般使用问题相关的故障。

解决 Vehicle Location 依赖性

1. 单击该 API GET /identity/api/v2/vehicle/{vehicleId}/location. 您可以使用搜索框过滤location，以便更轻松地找到该位置

2. 在此视图中，Request Editor位于页面底部附近。我们将手动编辑请求以修复可达性问题。向下滚动到 URL Params 行，注意 vehicleId 参数已映射到依赖项。让我们调查一下这是否配置正确。
3. 单击 vehicleId 行，将打开一个浮动窗口。将 Dependency Settings fieldAPI 更改为 GET /identity/api/v2/vehicle/vehicles。Request/Response 框選擇Response这会告诉 Active Testing 向此端点发出 GET 请求，该端点将返回用户的所有车辆作为依赖项。
4. 接下来，将 Dependency Settings field Path 更改为 0.uuid。这告诉 Active Testing 使用数组中返回的第一个项目中的字段 uuid，即 GET vehicle/vehicles 返回的字段。
5. 点击 Submit 将这些更改保存到依赖项
6. 点击 Publish Changes 保存对清单中 API 项目的更改。您应该会看到一条消息，显示“已Successfully Saved Overrides”
7. 接下来，我们将返回 Inventory 页面，并再次检查 location 端点的可达性。点击“Active Testing”页面顶部的 Inventory。找到 location API，注意旁边的点是黄色的。接下来，勾选您刚刚修改的 location API 的复选框，然后点击表格顶部的 Check Reachability
8. 可达性应该会成功，黄点会变成绿色。点击绿点可查看 Active Testing 如何验证可达性。检查完毕后关闭弹出窗口。

车辆定位可达性问题已解决。

改变 Create Order Reachability

作为课堂上的类似练习，尝试自行解决创建订单 API 的可达性问题。主动测试使用静态值 1 进行测试，但尝试将其更改为对 GET /workshop/api/shop/products API 的依赖，特别是响应中的产品 ID。以下是解决方案：

1. 导航到主动测试Inventory页面。
2. 点击 API 行 POST /workshop/api/shop/orders。您可以使用搜索框过滤 orders，以便更轻松地找到。请确保在过滤结果中选择正确的API。

3. 在此视图中，Request Editor位于页面底部附近。我们将手动编辑请求以更改可达性。向下滚动到 Body，注意 product_id 值已映射到静态值 1。
4. 单击 product_id 行，将打开一个浮动窗口。单击 Static 关键字并将其更改为 Dependency。将 Dependency Settings 字段 API 更改为 GET /workshop/api/shop/products。这会告知 Active Testing 向此端点发出 GET 请求，该端点会返回所有可用产品作为依赖项。请确保对依赖项使用 GET 端点，而不是使用相同路由的 POST 端点。
5. 接下来，将 Dependency Settings field Path 更改为 products.0.id。这告诉 Active Testing 使用产品数组中返回的第一个项目的字段 id，即 GET shop/products 返回的字段。
6. 点击 Submit 将这些更改保存到依赖项.
7. 点击 Publish Changes 保存对清单中 API 项目的更改。您应该会看到一条消息，显示“已Successfully Saved Overrides”
8. 接下来，我们将返回 Inventory 页面，并再次检查 orders 端点的可达性。点击“Active Testing”页面顶部的 Inventory. 找到 orders API，注意旁边的点是黄色的。接下来， 勾选您刚修改的 orders API 复选框，然后点击表格顶部的 Check Reachability。
9. 可达性应该会成功，黄点会变成绿色。点击绿点可查看 Active Testing 如何验证可达性。检查完毕后关闭弹出窗口。

创建订单可达性问题已解决。

运行另一次扫描

现在我们已经解决了可达性问题，但扫描返回了新问题！与您的研讨会负责人一起探讨这些问题。

主动测试活动到此结束。

9. What's Next?

Akamai Security Blog

Active Testing

Resources

Noname Learning Academy

-