在这个时代，Web 和移动应用程序一般是由 RESTful 网络服务供给支撑的。 公共和私有 API 在互联网上十分普遍，测验这些 API 绝非易事，但有一些东西能够协助你。 虽然(一般用与浸透测验)东西不能代替技术，但即使是最熟练的木匠也能用锤子比用鞋子更有用地钉钉子。

Postman 便是这样一个东西，它在开发者中现已流行了很多年。 在咱们进入怎么设置它的主题之前，咱们先来快速介绍一下这个东西是什么以及能够做什么。 Postman 是一个商业桌面应用程序，可用于 Windows、 Mac OS 和 Linux。 它的大部分功用是免费的，也有付费的功用，比方供给协作和文档功用。 与浸透测验人员比较，这些特性对开发人员更有含义。 它用于办理测验各种 API 调用的 HTTP 恳求集.合，以及包含变量的环境。 它并不能代替你的署理(如：Burp，ZAP，Mitmproxy 等等) ，可是实际上弥补了浏览器和客户端应用程序层缺失的功用。 关于这款东西主要的代替计划是开源东西 Insomnia 和高档 REST 客户端，商业产品 SoapUI，或建立在 Swagger/Swagger UI 或 curl 的自定义东西。

设置 Postman

在其官方网站上（https://www.getpostman.com,）能够找到 Postman，供给 Windows 和 MacOS 的装置程序，以及 Linux 的 tar 包。 它也能够在 Ubuntu 的 Snap for Ubuntu ( HTTPs://snapcraft.io/postman )和其他社区保护的 repos 中找到，比方 Arch Linux 的 AUR。 设置它的第一步当然是程序装置。

在第一次发动 Postman 时，你会看到一个屏幕，提示你创立一个帐户，注册谷歌，或许用现有的凭证进行登录。 可是， Postman 并不需求一个帐户来履行后续的运用。

登录的帐户用于协作/同步/等; 这些是付费的功用。正如我前面提到的，这几个功用关于开发人员来说很棒，但对你来说，或许并不关怀。 事实上，假如你一般需求对你的客户端机械能保密，就像咱们在 Secure Ideas 所做的工作，那么你或许明确地不期望将你的项目同步到另一个第三方服务器。

假如你低头看窗口的底部，你会看到一些浅灰色的文字，上面写着跳过登录，直接把我带到了应用程序界面。 点击这个灰色的链接，你将移动到下一个屏幕——一个提示你创立东西的对话框。

有几个部分你不会在这儿运用到，所以让咱们看看你真实关怀的三个功用:

• 集.合（Collection）——一个你能够用恳求填充的通用容器。 它还能够作为一些装备挑选的尖端目标，比方身份验证规则(Authentication rules) ，咱们稍后将对其进行详细阐明。
• 恳求（Request）——这个是最主要的功用。 这些是你即将构建的 HTTP 恳求，运用你想要运用的任何办法、HTTP Body等。 这些有必要一直在一个集.合中。
• 环境（Environment） ——这儿能够保存你期望在某个当地控制并宣布跨恳求乃至跨集.合所运用的变量。

运用 Postman 的根本知识

是时分创立咱们的第一个 Postman 集.合并宣布 HTTP 恳求。

左上角的 New 按钮一般用于创立集.合和恳求。 让咱们首要创立一个集.合。 这有点像一个单独的应用程序。 你将用于对相关恳求进行分组。

集.合还能够作为具有身份验证指令的尖端项，这些身份验证指令将对单个恳求进行承继。 现在，只需给它起个姓名，然后点击创立按钮就行了。 这儿，我起的姓名是“测验集.合”。

默许状况下，你现已翻开了一个未命名的恳求选项卡。 让咱们来看看 UI 的这一部分。

1. 活动选项卡
2. 此恳求的称号。 这仅仅一些描绘性的称号，你能够写也能够不写。
3. HTTP 办法。 这个下拉控件答应你更改此恳求的办法。
4. 恳求的 URL。 这是完好的途径，就像在你的浏览器的地址栏相同。
5. 用于设置恳求的各种特点的选项卡式界面，包含参数、HTTP 头、HTTP 主体等。
6. 发送按钮。 这实际上是将恳求提交到指定的 URL。
7. 保存按钮。 第一次单击此选项时，你需求指定你的集.合，因为恳求有必要归于某个集.合。

我在 HTTP://localhost:4000上设置了一个示例目标，所以我将从填写这个恳求并保存到我的某个集.合作为开端。我将宣布一个 POST 恳求，到 HTTP://localhost:4000/legacy/auth ，没有任何参数(这是一个测验 API。 任何人都能够通过身份验证)。 当我点击保存按钮时，我将命名恳求并为它挑选一个集.合，如下图所示：

然后单击"保存到测验集.合"(依据你的集.合称号进行调整)按钮来保存我的恳求。 现在，单击 Send 按钮将宣布恳求。 然后我将看到呼应填充在窗口的下窗格中，如下图所示：

1. 选项卡界面有 Body , Cookies , Headers 及测验成果。 咱们还没有编写任何测验，可是请留意图中标出的呼应返回的cookie ，headers。
2. 实际呼应的 HTTP Body 坐落较大的文本窗格中。
3. 咱们有可读性较好的打印办法或原始的呼应主体的选项，以及不同类型的下拉列表(我相信这是预填充的呼应头 content-type)。这儿还有一个自定义包装按钮，以防你有其他特别的操作。
4. 关于呼应的衡量标准包含 HTTP状况码、呼应时间和呼应大小。

关于 Cookies 的一个旁注

现在，假如咱们运用 Postman 重新宣布恳求，咱们将留意到一个重要的工作: 之前在呼应中设置的 cookie 会被主动包含。 它仿照了浏览器一般为你做的工作。 正如你对浏览器的期望相同，在这个 cookie 规模内宣布的任何恳求，Postman 都将主动包含该 cookie。

假如你想移除某个 cookie 该怎么做呢？ 这很简单。 在 Postman 的发送按钮下面，有一个相似链接的按钮，上面写着 Cookies。 点击这个按钮，会翻开一个对话框，在那里你能够删去或修正任何你需求的 cookies。

这便是基于 cookie 的 API。 可是让咱们面对现实: 现在咱们常见的 API 都会运用无记名令牌（Bearer Token）这比运用 Cookies 更为普遍。

为什么要设置署理？

通过运用 Postman，咱们能够将其作为一个优秀的东西，从零开端制造恳求并办理这些恳求。 通过 Burp 署理 Postman 的流量，咱们能够得到这些好处: 咱们能够与Burp 的 intruder 功用结合进行模糊测验，咱们也能够运用 Burp 的被迫扫描器检测杰出的安全问题，咱们也能够运用 Burp 的扩展插件，这一部分咱们将在本系列文章的后续章节中看到。 而且咱们能够运用Burp 的 Repeater 篡改恳求。 或许你会说，咱们也能够在 Postman 里边进行篡改啊。 可是我要说的是运用 Repeater 有两个重要的原因: 1) Postman 的设计是用于宣布正确、有用的恳求。 在某些状况下，它会测验纠正格局不正确的语法。 而在测验安全问题时，咱们或许不期望它纠正咱们篡改的过错。 2)通过运用 Repeater，咱们坚持了在 Postman 中的恳求的干净状况以及在 Repeater 中已篡改的恳求这两者之间的分离。

设置 Burp Suite

对 Burp 的实际介绍超出了这篇文章的规模。 假如你正在阅读这篇文章，很或许你现已对它很熟悉了

现在，发动 Burp，查看 Proxy 下的 Options 选项卡。 最上面的部分是署理监听器（Proxy Listeners），你应该会在127.0.0.1和端口8080上看到一个监听器。 它有必要一向运行(留意复选框)。 假如它在默许状况下没有运行，那一般意味着端口不可用，你需求将监听器(以及Postman)更改为不同的监听端口。 只需将 Burp 正在监听的端口以及你在 Postman 中设置的署理的地址和端口是同一个，那么你的设置应该没什么问题。

一起查看 Proxy 下的 Intercept 选项卡并验证 Intercept 是否封闭。

在 Postman 中装备 Burp 署理

Postman 是署理感知的，这意味着咱们要将它指向咱们的中心人署理，也便是 Burp Suite。 咱们将通过点击右上角的扳手图标(1)翻开设置对话框，然后点击下拉菜单上的设置选项(2)。 这会翻开一个比较大的设置对话框，在顶部有不同类别设置的标签。 找到"署理"选项卡并单击进行设置。

翻开 Postman 设置面板

在这个标签页上有三件事能够做:

1. 翻开大局署理装备开关（Global Proxy Configuration）
2. 封闭"运用体系署理（Use System Proxy）"开关
3. 将署理服务器 IP 地址和端口设置为和你在 Burp Suite 署理中设置的相同

默许的署理接口是127.0.0.1，端口是8080，这儿假设你的 Postman 和你的 Burp Suite 是在同一台机器上运行的。 假如你想运用不同的端口，你需求在这儿指定它，并确保它被设置为与 Burp 中的署理接口相同。

现在你能够署理流量了，还有一个问题需求考虑。 现在，大多数公共 API 都运用了 SSL/TLS 。 这是一件十分好的工作，但它也意味着当 Burp 作为署理中心人在处理 Postman 的 API 恳求和呼应时，你会遇到证书过错的问题，除非你的体系现已信任了 Burp 的证书颁发机构。 处理这个问题有两个办法:

1. 你能够封闭 Postman 中的证书验证。 在 General 设置选项卡下面有一个 SSL 认证验证选项。 设置为 关掉（Off），将使 Postman 疏忽任何证书问题，包含 Burp Suite 的 PortSwigger CA 。
2. 你能够将你的Burp Suite CA 设置到体系信任存储。 详细的设置细节和渠道有联系。
   
   

验证署理是否正常工作

用 Postman 宣布一些恳求。 在 Burp 的 Proxy 选项卡上查看你的 HTTP 前史记录。

在 Burp Suite 中的署理前史记录

故障扫除

• 你宣布的恳求存在延迟和超时问题？ 在 Burp 中的署理选项卡上查看"拦截"是否封闭。 查看 Postman 中的署理设置是否与 Burp 中的署理接口相匹配。
• Postman 收到了呼应，但呼应没有显现在 Burp 的署理前史中（等等）？ 翻开 Postman 的”设置"界面，查看"大局署理装备"是否翻开。 确保你没有激活 Burp 前史记录的过滤器来过滤掉你一切的恳求。 假如没有捕获过滤规模外的流量，模仿还要确保是否在 Burp 中设置了规模（scope）。

现在咱们现已做好了根本的东西链设置。

集.合变量

Postman 中的变量简直能够用于恳求中的任何字段。 语法是在它们的两头运用两层花括号。有几个当地我能够运用变量定义它们。 假如它们是静态的，或许我会将它们设置为集.合变量。 例如，我一向运用 http://localhost:4000作为我的测验主机。 假如我将测验 API 的端口从4000改为4001，我不期望一个个修正每个恳求的 URL。接下来我介绍一下咱们该怎么将它移动到一个集.合变量中。首要，在菜单侧栏中翻开"集.合"列表中修正该集.合的对话框。 我能够单击… 按钮或许右键单击集.合称号。这两种操作，咱们会得到相同的上下文菜单，然后挑选修正（Edit）。

这将翻开一个修正集.合的对话框。 默许视图包含集.合的称号和描绘的文本框，可是在这两个字段之间还有一行选项卡。

其间一个标签叫做变量（Variables）。这便是咱们想要的，点击这个标签会翻开另一个对话框，用于修正动量。

Postman 集.合变量修正界面

它有一个表格，其间包含某个变量的变量称号、 初始值列和 当时值列。 这两个值列之间的差异与 Postman 的付费功用进行同步有关。 在这儿重要的一个点是，你将输入初始值，然后选项卡进入当时值字段。 这将主动将当时初始值填充到当时值字段中，而且它将如图所示。 现在我有了一个名为 API_host 的集.合变量，其值为 http://localhost:4000。 在完结了变量的修正之后需求点击更新按钮。

现在是时分修正我的恳求，并引证该变量，而不是运用硬编码的主机名和端口。

Postman中的恳求，将URL更改为指向一个变量

我仅仅简单地用占位符替换了每个 URL 中对应的部分:  {{API_host}}，把鼠标悬停在占位符上能够翻开这个变量，会显现变量值和规模。 这儿有一些色彩编码也能够协助咱们。 当变量有用时，文本会变成橙色，可是假如我输入一个无效的变量名，文本将变成红色。

我仍然需求对每个恳求进行一次更新，让它们运用某个变量。 可是在将来，假如我改动了端口，或许假如我切换到了 HTTPS，或许假如我将我的测验 API 布置到一个完全不同的主机上; 那么我就能够回到集.合变量那里并更新变量的值，我的一切恳求都会相应地发生改动。

现在，集.合变量关于相对静态的字段以及不会常常发生改动的字段是很合适的，可是假如我在一个多租户的处理计划中测验多个环境和布置，乃至多个租户呢？ 我或许会运用相同的恳求集.合，可是运用不同的变量集.合。 那么在这种情下环境变量就能够处理这个问题。

环境变量（Environment Variables）

你或许现已留意到了窗口右上角的界面。 让咱们翻开看看:

在 Postman 中的环境变量界面

1. 环境挑选器下拉菜单。能够挑选一个环境。
2. 快速查看按钮，点击后能够查看你的环境中设置的内容。
3. 办理环境按钮，这儿是真实进行修正环境的当地。

首要，咱们需求点击办理环境按钮。 这会翻开一个较大但空白的对话框，底部有一个 Add 按钮。 点击这个增加按钮。

你会看到另一个对话框。 这一个看起来简直和集.合变量对话框相同，除了它有一个姓名。

在这儿，我把我的命名为 LocalTest。

我还增加了许多其他的变量，其间一个叫做bearer_token，值为 foo。 另一个是 user_id值为1。

一旦完结修正，咱们点击对话框底部邻近的增加按钮，然后封闭办理环境对话框。 在我能够在这个环境中运用这个变量之前，还有最终一个重要的、常常被忘记的进程：咱们需求从环境挑选器下拉菜单中挑选这个环境。

现在这些额定的变量能够像上面的 API_host 变量相同进行拜访: {{bearer_token}} 和 {{user_id}}

路由参数

在现代API中运用路由参数是很常见的。这些是作为URL主途径的一部分所供给的值。例如，考虑以下状况http://localhost:4000/user/42/preferences

这样的URL中的数字42实际上是一个参数，很或许是本例中的用户 ID。 当服务器端应用程序路由传入恳求时，服务端会提取该值，并使其随时可用于最终处理恳求和构造呼应的函数。 这是一个路由参数。 这关于修正参数或是在 Postman 中运用也比较简单。语法是将参数以冒号(:)后跟参数名的办法直接放入 URL 中。 关于 Postman 中的这个示例恳求，我将其输入为{{API_host}}/user/:userId/preferences。 然后，在恳求的参数（Params）选项卡上，我能够看到它被列出并设置了详细的值。 在下图中，我将其设置为在前面的环境变量中指定的user_id变量。

我也能够把我的变量直接写到URL中，但在我看来，这种办法更干净。

无记名令牌（Bearer Tokens）

幻想一下这样一个场景: 你宣布某种类型的授权恳求，它用一个 bearer token 进行呼应，然后你需求在一切其他恳求中运用该令牌。 这样做的手动办法或许仅仅宣布验证恳求，然后从呼应中仿制并张贴令牌到别的一个环境变量。 一切其他的恳求都能够运用这个环境变量。

这样也能够正常宣布恳求，假如你有一个短期的令牌，那么这种做法或许会很苦楚。关于这个问题，有一个更优雅的处理计划。想想下面的呼应:

咱们现已宣布了恳求，而且收到了一个包含令牌的 JSON 呼应。 现在，我想用主动化的办法运用新的bearer token来更新我的环境变量。 在恳求界面上，有几个标签能够做到。 最右边的一个叫做测验。 这主要用于主动查看呼应，以确定 API 是否失效，就像单元测验相同。 可是咱们能够通过一些 JavaScript 句子来达到咱们的意图。

我增加上面的脚本，单击保存，然后再次运行我的恳求。 似乎一切的工作都和第一次一模相同。可是假如我运用快速查看（Quick Look）按钮来查看环境变量时……

咱们能够看到当时值现已被主动更新。 这是第一步——我现在将值存储在一个我能够轻松引证的当地，可是它不会将Bearer token 这个令牌放入我的恳求中。 我有两个办法。 第一个办法是，假如翻开恳求的 Authorization 选项卡，咱们能够从类型下拉列表中设置一个Bearer token，并将其指向我的变量。

这种办法还不错，可是我需求在每个恳求上都进行相同的设置。可是每个新的恳求的默许授权类型是承继父类身份验证（Inherit auth from parent）。在本例中，父类是个集.合。因而，假如我将这个恳求切换回默许的类型，那么我就能够进入修正集.合（Edit Collection）进行设置(与我进入Collection变量的上下文菜单相同) ，然后进入Collection的Authorization选项卡。

这个功用展示的接口简直与恳求中的 Authorization 接口相同，我能够以相同的办法设置身份验证到信息。 现在的不同之处在于它是在集.合中办理的。 在默许状况下，我创立的每个新的恳求都将包含该bearer token，除非我成心更改了该恳求的类型。 例如，我的身份验证恳求或许不需求bearer token，因而我需求在恳求的 Authorization 选项卡大将类型设置为 No Auth。

偶然，我会遇到一些应用程序，需求从呼应中包含的XML或HTML主体中提取一些值。 在这种状况下，内置的xml2Json 函数有助于解析呼应内容。

运用 xml2Json 将 HTML 主体整合到 JSON 目标中

还有一个需求留意的功用是 Pre-request Script 选项卡，它运用相同的根本脚本接口。 正如你或许期望的那样，它在恳求发送之前履行。 我的一些搭档运用这个功用来设置bearer token令牌，这是一个完全有用的办法，只不过不是我平常所运用的办法。 当你仅仅需求一次性操作的时分，这种办法也会很有协助，虽然这种状况我一般遇不到。

设置 Jython

其间的一些扩展需求在 Burp Suite中设置Python环境，而Burp Suite在默许状况下是不装备Python环境信息的。假如你现已装备过了，那么你能够继续下面的操作。假如没有装备过，你能够翻开 Extender-Options 并设置Jython的独立JAR的方位。假如你需求这个下载jar包，你能够从jython.org上找到。

设置好途径后，导航到 BApp Store 选项卡，就能够开端下载咱们即将运用的扩展插件了。我想重点阐明的两个插件是JSON Web Token Attacker和Autorize。

现在让咱们更详细地看看这两个插件。

JSON Web Token Attacker

目前现已有许多处理身份验证和授权的办法。JWT或许是现代API上最常用的办法。假如在下图中查看Bearer token，你将留意到咱们正在运用的JWT的几个明显标志:三个片段，由冒号字符分隔。Base64编码的头部和声明部分，后面跟着加密签名。

这个令牌能够很容易地在Burp suite内置的解码器中解码。只需挑选令牌，Base64就能够解码整段文本。上图中的文本解码后，如下:

{"alg":"HS256","typ":"JWT"}.{"userid":1,"tokenid":"fac15939-de30-481d-9d13-6ae89ecd7370","iat":1552444637,"exp":155244823N30.Ü¢R¥çe4r-ø£m-³Ì@

虽然 Burp的 Decoder能够用这种办法以最小的损坏对文本进行解码，但我期望对其进行修正和重新编码。这样做将产生以下成果:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9LnsidXNlcmlkIjoxLCJ0b2tlbmlkIjoiZmFjMTU5MzktZGUzMC00ODFkLTlkMTMtNmFlODllY2Q3MzcwIiwiaWF0IjoxNTUyNDQ0NjM3LCJleHAiOjE1NTI0NDgyM04zMC7colISpedlNHItBvijbS0TmYWzzIFAAOmykTIWurMtDzVJ

这与原始值相似，但绝对不同。这是因为JWT不是单个base64编码的字符串。标头和声明部分是分开编码的，去掉了任何填充信息(由一个或两个等于号表明)。

在JWT完结中有一些缺点，虽然大多数缺点比较稀有。 对这些缺点的运用包含篡改JWT偏重新进行编码。虽然这能够手动完结，但JSON Web Token Attacker能更容易完结这个进程。咱们只需从恳求中仿制值，然后切换到该插件增加的Burp中的JOSEPH选项卡。接下来，翻开Manual子选项卡，并将值张贴到输入框中。然后点击加载按钮。

之后会显现一个进犯挑选的下拉框界面。 这儿有两种进犯办法: 密钥混杂（Key Confusion）和签名扫除（Signature Exclusion）。虽然对这些进犯的深入研究超出了本文要阐明的规模，但我会给出一个简介的总结，便是这两种进犯中的任何一种都会将头部的alg值更改为不同的算法;要么将其切换为None值(表明不需求签名)，要么将其从不对称加密切换到对称加密，这样咱们就能够用公钥生成有用的签名。其间任何一种办法的安全性的影响是，加密签名一般是确保令牌完好性的唯一办法。假如进犯者能够破解该签名，则能够修正该令牌，使其具有进犯者想要的任何声明。在这个示例中，这或许意味着进犯者会更改用户ID获取其他账户的会话并运用该帐户。

让咱们来看一下“签名扫除”进犯办法的操作进程，并逐渐完结根本的手动进犯:

1. 加载输入
2. 挑选签名扫除
3. 加载
4. 挑选一个有用载荷，这些是None的变体.
5. 更新
6. 获取生成的值并将其用于Repeater。假如你从一个有用的JWT作为进犯的开端，而且篡改的版别被接受了，那么你的进犯就成功了。之后你就能够继续篡改声明部分了。

密钥混杂的实际用法与签名扫除简直是相同的，仅仅你需求供给公钥并对其进行转换。 一般的做法是签名算法挑选 RS256，而且公钥可用于验证签名。

另一个你或许现已留意到的工作是，Burp中的署理前史现在有高亮显现的功用和一个新的上下文菜单。

这是一个用于半主动进犯的插件。 我个人不喜爱这样运用这个插件，部分原因是因为我发现它有时会变得混乱而且生成格局过错的恳求，还有一部分原因是因为我喜爱严格控制我发送的流量。别的，关于完结JWT失效黑名单的体系的一个稀有的状况是，格局不正确的令牌会将会话列入黑名单。

虽然如此，即使是手动进犯模式也极大地简化了生成修正过的JWT的进程。 这使得这种办法常常成为API测验的有用东西。我发现，产生这些漏洞运用的完结办法似乎并不常见，可是考虑到它们的严重性，应该一直对这些漏洞进行测验。

主动化（Autorize）

在API中或许会呈现各种授权问题。除非API是完全揭露的，不然你至少拥有通过身份验证的拜访权限和未通过身份验证的拜访权限。 假如存在某个特定用户拥有的资源或数据的概念，那么验证一个通过身份验证的用户不能拜访他们不拥有的任何资源是十分有含义的。有些API还具有多个垂直等级的拜访权限，特别是在有安排概念的状况下。一个用户或许比另一个用户有权拜访更多的数据或功用。相同，这取决于测验人员来承认是否强制履行了这种权限装备。最终，在多租户体系中(例如，每个客户机安排都有自己独立的空间) ，租户之间的数据或拜访走漏是最大的安全问题之一。

关于一切这些状况，通用的测验战略是将资源和功用映射到具有正确权限的用户。 然后，咱们用不同的拜访令牌或会话重新宣布相同的恳求，并比较咱们的拜访成果。当权限模型具有任何真实的复杂性时，这个验证进程或许会十分耗时。主动化能够显著提高测验效率。让咱们从导航到Burp中的Autorize选项卡作为开端，这样咱们就能够完结根底设置。

1. 在切换通过身份验证的上下文时,咱们要替换的标头有一个大文本框。这能够包含Cookie 和任何其他恳求标头,它们要像在正常恳求中相同进行设置。
2. 关于cookies，你能够点击“从最终一个恳求获取 cookie ”的按钮来主动填充该文本框。
3. 高亮显现的按钮“Autorize is…” 用于切换插件的开和关。 当封闭时，主动化将什么也不做。 当发动时，射中 proxy* 的传入恳求将运用你供给的标头或 cookie 进行替换偏重新宣布恳求，一起省略这些标头或 cookie。

* 界面底部的拦截过滤器选项卡可用于确定包含哪些恳求。

现在现已设置好了 Autorize，你能够通过 Postman 宣布新的恳求，并留意左侧的 Autorize 区域会被填充。

我的示例 API 刚好具有相同的呼应，从显现呼应长度的三个数字列(别离为74和6)能够看出这一点。 第一个是对未修正恳求的呼应，第二个是替换了令牌的恳求，第三个是未通过身份验证的呼应。 剩余的两列用交通信号灯相同的色彩表明强制履行。 图中的黄色部分代表的是一种不确定的呼应，而红色和绿色的部分别离用于表明授权是否得到强制履行或履行成功。

现在，能够运用底部的"未通过身份验证的恳求探测器"和"强制恳求探测器"选项卡来调整认证何时收效。 这能够让你依据你对 API 行为的了解创立匹配条件，而且能够极大地改进成果对呼应的解释。 关于较大的 API，或许那些你预期要进行多次测验的 API，这么做当然是值得的。 可是，关于一次性测验，我一般不对此进行调优，而是手动查看呼应或长度不一致的状况。

能够运用Autorize UI右侧的选项卡(相似于Burp中的典型恳求和呼应选项卡)来查看修正过的和未经身份验证的恳求和呼应。这关于研究恳求之间为什么存在差异、API做了什么以及对服务端来说是否是正确的恳求至关重要。

总结

虽然本文章的内容不够全面，可是期望这篇文章能够供给足够充沛的介绍，让咱们开端运用这些插件，这些插件在大多数API测验中都很有用，至少在现代API中是如此。主动化关于测验API和SOAP服务也是十分好用的，而JSON Web Token Attacker 则十分特定于某种现已变得相当流行的而且是常见的身份验证办法，特别是它在OAuth2完结中的运用。