网站关键词排名没有了,网页设计学校模板,长沙seo招聘,英文谷歌优化《API Testing and Development with Postman》最新第二版封面 文章目录 第十四章 API 安全测试1 OWASP API 安全清单1.1 相关背景1.2 OWASP API 安全清单1.3 认证与授权1.4 破防的对象级授权#xff08;Broken object-level authorization#xff09;1.5 破防的属性级授权Broken object-level authorization1.5 破防的属性级授权Broken property-level authorization1.6 不受控制的资源消耗Unrestricted resource consumption1.7 不受限制地访问业务流Unrestricted access to business workflows1.8 不安全地使用 API 接口Unsafe consumption of APIs 2 模糊测试Fuzzy2.1 相关概念2.2 实战在 Postman 中执行模糊测试2.3 绕开 Collection Runner 的测试方案 3 利用 Postman 内置随机变量实现模糊测试4 小结 写在前面 本章为全书的倒数第二章作者简要介绍了 API 安全测试的相关概念并对 OWASP API 安全清单和模糊测试Fuzzy Testing进行了重点讲解后半部分作者利用数据驱动测试演示了模糊测试在 Postman 中的具体应用只可惜在实现方案和叙述的条理性上较为敷衍导致我在实测过程中又踩了不少坑。特此梳理出来既是对自己创新方案的复盘也能让更多后来者少走弯路。 第十四章 API 安全测试 本章概要 OWASP API 安全清单用 Postman 进行模糊测试Fuzz testing的方法 1 OWASP API 安全清单
1.1 相关背景
OWASPOpen Web Application Security Project是一个非营利组织专注于提高软件安全性提供免费、开放的资源如工具、文档、论坛等帮助开发者和安全人员构建安全的应用程序知名项目包括 OWASP Top 10十大 Web 应用安全风险和 API Security Top 10API安全十大风险相关资源 网站门户https://owasp.org/2023 最新版 API 安全清单https://owasp.org/www-project-api-security/
1.2 OWASP API 安全清单
API Security Top 10 是 OWASP 针对 API 安全的核心文档罗列了 API 面临的十大安全风险。适用于开发者、安全工程师和架构师帮助识别和缓解API安全威胁。
1.3 认证与授权
黑客最先尝试的攻击方式是身份验证即通过用户名密码攻击。
最简单的方式是暴力破解brute-force attack因此 API 接口应采取在一定时间段内 限制登录次数 的防护措施。
具体实现以 GitPod 演示项目为例可利用 Postman 内置的随机数据变量高频多次调用登录接口多次手动点击或 Collection Runner 设置迭代次数
测试脚本
for (let i 0, len 50; i len; i) {pm.sendRequest({url: pm.variables.replaceIn({{base_url}}/token),method: POST,header: { Content-Type: multipart/form-data},body: {mode: formdata,formdata: [{ key: username, value: pm.variables.replaceIn({{$randomUserName}}) },{ key: password, value: pm.variables.replaceIn({{$randomPassword}}) }]}},function (err, resp) {if (err) {console.error(JSON.parse(err));return;}pm.test(${i 1}: Response JSON have detail attribute, function () {pm.expect(resp.json()).to.eql({ detail: Incorrect user name or password });});})
}实测结果鉴权接口疑似不具备限制登录次数功能 【图 14.1 构造不同的用户名和密码多次高频调用登录接口模拟暴力破解过程】
1.4 破防的对象级授权Broken object-level authorization
这是 2023 年十大安全清单排名第一的高风险议题
问题描述未正确验证用户对对象的访问权限导致越权访问。应对措施实施严格的权限验证确保用户只能访问授权资源。示例用登录普通用户user1/12345的登录令牌去访问管理员帐号看看示例项目是否会响应 403 错误。
实测结果 【图 14.2 用 user1 的登录令牌访问管理员 admin 的帐号信息后台报 403 错误符合预期】
1.5 破防的属性级授权Broken property-level authorization
示例用 user1/12345 登录先用 user1 为创建人即 create_by 字段添加一个正常的待办项然后看看是否可以通过 PUT 请求篡改该创建人信息例如改为 user2。
测试脚本
// PUT requests Post-response
pm.collectionVariables.set(reqPut, pm.request);// Pre-request
pm.sendRequest(pm.collectionVariables.get(reqPut),function(err, resp) {if(err) {console.error(Updated failure, err);return;}pm.test(PUT req: status code should be 200, () {console.log(resp)pm.expect(resp.code).to.eq(200);});}
)// Post-response
pm.test(The creator should not be updated (user1) after running PUT req,() {const [{ created_by: creator }] pm.response.json();pm.expect(creator).to.eql(user1)});实测结果 【图 14.3 实测属性级授权漏洞篡改失败符合预期】
但实测发现在创建待办项时人为设置创建人为 非当前登录用户如 user2最后仍然创建成功了说明该接口还是有问题的 【图 14.4 创建任务时篡改创建人信息最终任务创建成功说明该接口仍然支持篡改信息】
1.6 不受控制的资源消耗Unrestricted resource consumption
方式一通过耗尽所有系统资源来损害系统导致系统瘫痪denial-of-service attacks拒绝服务攻击
方式二由于未对接口调用次数进行限制大量请求将拖慢响应速度如果接口调用了第三方付费资源还会产生大量费用。
1.7 不受限制地访问业务流Unrestricted access to business workflows
攻击者可能会利用抓包、监控请求数据等方式获取系统内部通信 API从而获悉内部工作流结构给系统带来严重威胁例如恶意逃票等。
应对措施仔细考虑暴露了哪些接口严格控制接口访问权限。
1.8 不安全地使用 API 接口Unsafe consumption of APIs
典型案例引用了被黑客攻击的第三方 API。
这类测试较为棘手可能需要搭建一个模拟服务器让从第三方 API 响应的数据在该模拟器上先行缓冲或者模拟危险数据进行测试看看本地后台是否能够鉴别该类数据。
2 模糊测试Fuzzy
2.1 相关概念
定义模糊测试Fuzzy 是一种通过向程序提供无效、随机或意外的输入来发现漏洞和错误的测试技术。
主要特征
非通用测试技术有助于发现未考虑到、或未测试到的问题
具体的运行方式
手动执行通过在 UI 中输入伪随机数据来完成极少编程执行以程序的形式运行绝大多数。工具如 PeachFuzzer 或自定义输入集。
输入的生成
生成大量随机或半随机数据可能包含格式错误或危险字符如转义字符、引号等。输入通常是随机的但有一些边界限制例如字节 vs ASCII/Unicode 字符串。输入可以偏向已知的“危险”字符例如转义字符、引号等。
输入内容的具体方式
通过命令行参数注入通过文件输入通过网络协议通过 API 输入特别适合模糊测试易于用程序控制
模糊查询的应用场景
安全测试场景揭示未能预见的攻击方向发现错误处理机制中的薄弱环节等API 测试场景具有易于访问且数量巨大的测试输入尤其适合 API 测试。
2.2 实战在 Postman 中执行模糊测试
以 GitHub 开源项目 Big List of Naughty Strings 的 JSON 文件为数据源利用 Collection Runner 对 GitPod 演示项目 ToDo List App 进行基于数据驱动的模糊测试看看 POST /tasks 接口在大量随机输入下的响应情况。
首先从开源项目下载原始数据文件 blns.base64.json。该原始数据为 Base64 编码的字符串数组
[, dW5kZWZpbmVk, dW5kZWY, bnVsbA, ...
]使用前需要先处理成如下格式可使用 vim 宏的批量操作完成
[{naughtyString:}, {naughtyString:dW5kZWZpbmVk}, {naughtyString:dW5kZWY}, {naughtyString:bnVsbA}, ...
]然后创建测试集合 FuzzyTest 以及 POST 请求 Create a task其 URL 设置为 {{base_url}}/tasks其中 base_url 为集合变量其值为 GitPod 演示项目的基础 URL启动链接https://gitpod.io/new/#https://github.com/djwester/todo-list-testing。
接着在测试请求的请求体中输入如下内容这里有个大坑后面会讲
{description: {{naughtyString}},status: Draft
}上述代码中的 naughtyString 为数据驱动测试启动后、经 Pre-request 脚本处理得到的动态变量
const atob require(atob);
const encoded_string pm.iterationData.get(naughtyString);
pm.collectionVariables.set(naughtyString, atob(encoded_string));对应的 Post-response 响应后脚本如下
pm.test(Status code is 201, function() {pm.response.to.have.status(201);
});一切准备就绪后启动 Collection Runner加载 JSON 映射文件执行模糊测试 【图 14.5 利用 Collection Runner发起基于JSON 文件数据驱动的模糊测试】
由于是分别读取每行数据并调用创建接口整个过程需要多等些时间最终得到结果 【图 14.6 Collection Runner 运行结束后的实测截图】
由于作者演示时用的是本地部署的 ToDo List App全套数据测完只用了 114和我实测时的 2356 真是天壤之别没办法Python 基础有限几次尝试本地部署都失败了。但奇怪的是除了 10 个请求因为网络原因发送失败其余 666 个都成功了并没有报错。
可高兴不到一分钟我就知道出问题了。作者并没有交代要用 user2 登录而我新增任务前压根儿就没登录导致后续的数据清空全部失败了 【图 14.7 由于新增任务时没有登录导致后续的批量删除全部失败神坑】
没办法只能重置项目重新来过……
先 Ctrl C 中断 GitPod 项目运行重置数据命令 poetry run python remove_tables.py然后执行 make run-dev 重新启动。
这次先用 user2/12345 换取登录令牌再到新增接口中完成鉴权 【图 14.8 用 user2 的登录令牌完成新增接口的鉴权设置】
然后只选取新增接口再次上传 JSON 数据集运行 Collection Runner 【图 14.9 重新运行 Collection Runner 的配置界面截图】
也不知道是不是这份死磕精神感动了马克思第二次运行居然全部成功了 【图 14.10 第二次运行结果截图676 条数据全部新增成功】
接着在浏览器查看项目首页也没有书中说的 alert 注入问题当真欧皇附体 借着这波好运赶紧再跑一遍数据批量清空。在 GET {{base_url}}/task 接口的响应后脚本中输入以下内容直接用 JS 脚本批量删除书中方法太过陈旧还得再消耗一次 Collection Runner 免费额度不知道作者怎么想的
const tasks pm.response.json();
const task_ids tasks.map(t t.id);const base_url pm.collectionVariables.get(base_url);
const auth {type: bearer,bearer: [{key: token,value: pm.collectionVariables.replaceIn({{token}}),type: string}]
};
const getCallback task_id (err, response) {if(err) {console.error(err);return;}pm.test(Deleting id(${task_id}): Status should be OK, function() {pm.expect(response.status).to.eql(OK);});
};for(const id of task_ids) {// Delete the task by idpm.sendRequest({url: ${base_url}/tasks/${id},method: DELETE,auth}, getCallback(id));
}结果还是报错 仔细一想真相大白了新增接口必须在请求体中手动指定 created_by 字段否则 一律按匿名处理就当是作者故意挖的坑吧。
只有再重来一遍了 再次执行批量删除只有一次是后台原因删除失败五次请求未发送其余全部删除成功终于熬出头了 2.3 绕开 Collection Runner 的测试方案
其实只要具备 JavaScript 基础完全可以跳过 Collection Runner 的限制在 Pre-request / Post-response 脚本中实现批量新增和删除。
批量新增的纯 JS 脚本实现 将原始 JSON 数据集不经任何处理直接放到 Postman 的私有模块中例如 my-blns const data [, dW5kZWZpbmVk, dW5kZWY, bnVsbA, TlVMTA, KG51bGwp, // ...e3sgIiIuX19jbGFzc19fLl9fbXJvX19bMl0uX19zdWJjbGFzc2VzX18oKVs0MF0oIi9ldGMvcGFz,c3dkIikucmVhZCgpIH19
];
module.exports {data
};新建请求 GET {{base_url}}/tasks用于在批量新增后查询总的待办项列表 在 Pre-request 中输入以下脚本 const atob require(atob);
const { data } pm.require(your/package/path/to/my-blns);
// console.log(data.length);const postRequest description ({url: pm.collectionVariables.replaceIn({{base_url}}/tasks),method: POST,header: { Content-Type: application/json },body: {mode: raw,raw: JSON.stringify({description,status: Draft,created_by: user2})}
});data.map(d atob(d)).map((description, i) pm.sendRequest(postRequest(description), (err, resp) {if(err) {console.error(err);return;}pm.test(Create task_${i1} completed: the status code should be 201,() pm.expect(resp.code).to.eql(201));}));在 Post-response 输入以下脚本 pm.test(Task list length should be greater than 0, function () {pm.expect(pm.response.json()).to.be.an(array).and.to.have.lengthOf.at.least(1, Task list length should be greater than 0);
});至于批量删除刚才实测过程中已经看过脚本了这里只说明一下实现逻辑。利用列表查询接口 GET {{base_url}}/tasks 获取到任务列表后批量提取任务列表的 id然后分别调用 DELETE 接口 POST {{base_url}}/tasks/:id 完成删除注意删除待办项时别忘了在请求中带上鉴权配置对象 auth。
这样就可以在 Postman 中随意批量新增和删除待办任务了完全不受 Collection Runner 的制约。
3 利用 Postman 内置随机变量实现模糊测试
其实就是将上传的 JSON 文件内容用 Postman 内置的各种随机变量实现同样的模糊测试效果例如将新增接口请求体中的 JSON 改为
{description: {{$randomLoremSentence}},status: Draft,created_by: user2
}或者借助测试脚本引入 lodash 实现更多模糊测试效果
const _ require(lodash);
// _.sample(collection): Gets a random element from collection.
const description _.sample([{{$randomAbbreviation}}, {{$randomAdjective}}]);
const jsonBody {description,status, Draft,created_by: user2
}4 小结
本章内容整体感觉较敷衍上半部分介绍相关概念几乎全是蜻蜓点水式的描述后半段实战环节的条理性又明显不如前面的章节漏掉很多关键细节且在方案选择上过分依赖 Collection Runner致使我在实测过程中浪费了不少免费额度。不过依次填完这些坑后我也有机会用纯 JavaScript 脚本的方式实现待办任务的批量创建与删除顺便学习了用 pm.sendRequest() 发送 POST 请求和 DELETE 请求的写法也算是因祸得福了吧。 后记 最后再跟大家分享个操作技巧遇到不会写的 Postman 脚本可以利用其自带的 AI 机器人 Postbot 直接给答案。本章实测中几种 pm.sendRequest() 的写法就是这么来的比查官方文档快多了。大家一定要学会使用 AI 工具千万不要故步自封成为 AI 时代的 “新文盲”。
