接口测试系列之——接口安全测试

Testerhome社区爱好者合力编写了《2021接口测试白皮书》，并于今年2月底发布。本文节选自其中的的「安全测试」章节。点击链接可下载完整版《2021接口测试白皮书》。

“开源 Web 应用安全项目”(OWASP)在 2019 年发布了 API 十大安全风险《OWASP API 安全 Top10》：失效的对象级别授权、失效的用户身份验证、过度的数据暴露、资源缺乏和速率限制、失效的功能级授权、批量分配、安全配置错误、注入、资产管理不当、日志和监视不足位列其中。我们以此为依据对 API十大安全风险进行介绍。

▌失效的对象级别授权

失效的对象级别授权是指:用户与服务器使用 API 进行通信时，服务器端未进行对象级别的权限控制或限制不严格。攻击者可以通过修改请求数据中的对象ID 等信息，实现未授权获取或修改敏感信息。

案例:在使用某个功能时通过用户提交的对象 ID(如订单号、记录号)来访问或操作对应的数据，且未进行严格的权限限制。

如下图所示，正常订单查询请求:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7IW4Plxe-1648105140097)(/img/bVcYIxK)]

如下图所示，使用 burpsuite 对 oid 参数进行遍历，尝试越权访问他人订单详情，可以看到成功查看到了他人订单信息:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sIiQQb6N-1648105140099)(/img/bVcYIxM)]

▌失效的用户身份验证

失效的用户身份验证是指:API 在访问时未对请求方进行身份验证或身份验证存在问题导致易被破解，那么攻击者可以实现未授权对 API 进行操作。

案例：

未校验令牌的有效性;
更新密码接口未限制请求频率，旧密码参数可暴力破解;
短信验证码或者邮箱验证码有效期超出 10 分钟或者长度小于 6 位。

▌过度的数据暴露

发生过度数据暴露的主要原因之一是，开发人员和编码人员对他们的应用程序将使用的数据种类没有足够的洞察力。正因为如此，开发人员倾向于利用通用流程，在这种流程中，所有的对象属性都暴露给最终用户。

例如：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1v0exJEZ-1648105140099)(/img/bVcYIxR)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wsVB2k9R-1648105140100)(/img/bVcYIxW)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0PCFwdlu-1648105140100)(/img/bVcYIx0)]

利用过度暴露的数据十分容易，通常通过嗅探流量分析 API 的响应获取不应该返回给用户的多余敏感信息。

防御:

不要依赖客户端来过滤敏感数据;
检查 API 的响应，确认其中仅包含合法数据;

停止用通用 API 向用户发送一切的过程也很重要。例如，必须避免将所有信息直接执行 to_json()和 to_string()，然后发送给客户端。应该专门挑选需要返回给授权用户的属性，并专门发送这些信息;

对于敏感数据应使用加密技术进行保护。这样，即使该数据的位置作为过度数据暴露漏洞的一部分被泄露出去，也有一个良好的第二道防线，即使数据落入恶意用户或威胁行为者手中，也能保护数据。

▌资源缺乏和速率限制

随着资源的缺乏和速率的限制，每个 API 都有有限的资源和计算能力，这取决于它的环境。大多数还需要处理来自用户或其他程序的请求，要求它执行所需的功能。当有太多的请求同时进来，而 API 没有足够的计算资源来处理这些请求时，就会出现这种漏洞。然后，API 可能变得不可用或对新的请求没有反应。

如果 API 的速率或资源限制没有被正确设置，或者限制没有在代码中被定义，那么 API 就很容易出现这个问题。

具体案例如下图所示：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rdCP3ytQ-1648105140101)(/img/bVcYIx2)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NotW815F-1648105140101)(/img/bVcYIx6)]

上述代码没有进行限制，我们可以通过短时间大量无限请求/api/users 访问所有的用户，造成其他客户端请求无法相应的问题。

修改后：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-e8GKUYdO-1648105140102)(/img/bVcYIx7)]

API 将限制匿名用户每小时发出 200 次请求，已经被系统审核过的已知用户会有更大的回旋余地，每小时有 5000 个请求，但即使是他们也受到限制，以防止在高峰期意外超载，或者在用户账户被泄露并被用于拒绝服务攻击时进行补偿。

对用户调用 API 的频率执行明确的时间窗口限制，定义并强制验证所有传入参数和有效负荷的最大数据量，例如字符串的最大长度和数组中元素的最大数量。在突破限制时通知客户，并提供限制数量及限制重置的时间。

▌失效的功能级授权

失效的功能级授权漏洞允许用户执行应该被限制的功能，或者让他们访问应该被保护的资源。

如下图所示，攻击者为站点普通用户权限，通过经验对站点可能存在的管理功能 URL 进行猜测，多次尝试之后发现本应无权访问的 admin_statuspage 页面可以访问成功：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QIwJWoVs-1648105140102)(/img/bVcYIx9)]

如下图所示攻击者为站点普通权限用户，站点使用已知框架，攻击者查阅新建管理用户功能需发送的数据包详情，并构造数据包进行发送，发现可以新建用户成功。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6QzNUiPS-1648105140103)(/img/bVcYIyc)]

防止这种 API 漏洞尤其重要，因为攻击者不难找到结构化 API 中未受保护的函数，因此所有业务层面的功能都必须使用基于角色的授权方法进行保护。一定要在服务器上实现授权，不能试图从客户端保证功能的安全。在创建功能和资源级别时，用户应该只被赋予做它们需要的事情的权限，实践最小权限的方法。

▌批量分配

后端应用对象可能包含许多属性，其中一些属性可以由客户端直接更新(如，user.firstname 或 user.address)，而某些属性则不应该更新(如，user.isvip 标志)。

案例：
一个乘车共享应用程序为用户提供了编辑个人资料基本信息的选项。用户可以更新“user_name”、“age”两个参数。

PUT /api/v1/users/me
{"user_name":"inons","age":24}
发现/api/v1/users/me 接口返回一个附加“credit_balance”参数:

GET/api/v1/users/me {"user_name":"inons","age":24,"credit_balance":10}

攻击者构造报文，重放第一个请求:
PUT/api/v1/users/me {"user_name":"attacker","age":60,"credit_balance":99999}

攻击者无需支付即可篡改自己的信用值。

如何防止：

如果可能，请避免使用将客户输入自动绑定到代码变量或内部对象中的函数;2. 仅将客户端可更新的属性列入白名单;
使用内置功能将客户端不应访问的属性列入黑名单;
如果可能，为输入数据有效负载准确、明显的定义和实施 schema 格式。

▌安全配置错误

概述：
安全配置错误可以发生在一个应用程序堆栈的任何层面，包括平台、Web服务器、应用服务器、数据库、框架和自定义代码。

案例：
比如攻击者在服务器的根目录下找到.bash_history 文件，该文件包含DevOps团队用于访问 API 的命令:
$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg=='，攻击者可由此命令获取权限认证信息(Zm9vOmJhcg== base64 解码:foo:bar)以及接口信息。

▌注入

概述：
服务端未对客户端提供的数据进行验证、过滤或净化，数据直接使用或者拼接到 SQL/NoSQL/LDAP 查询语句、 OS 命令、XML 解释器和 ORM(对象关系映射器)/ODM(对象文档映射器)中，产生注入类攻击。

案例：
判断服务端是否支持 XML 解析，如果支持，可以尝试 XML 注入。

]>
&entityex;
API 未对来自外部系统(如，集成系统)的数据进行验证、过滤或净化。

▌资产管理不当

不当的资产管理缺陷是现代的产物，以业务速度前进的组织有时每天都能旋转出成百上千的服务和微服务。这通常是快速完成的，而且没有创建任何的附带文档，也没有解释相关的 API 是用来做什么的，需要多长时间或其重要性。这可能会快速产生 API 蔓延，随着时间的推移可能会变得无法控制，特别是如果没有全面的政策来定义 API 可以存在多久。这种环境下，很有可能一些 API 会丢失、被遗忘或者未销毁。

这就导致了如果资产管理不当会直接导致攻击者可以访问敏感数据，甚至可以通过旧的、未打补丁的 API 版本连接到同一数据库。

如何消除不当的资产管理缺陷:应该做到对所有的 API、他们的用途和版本进行严格的盘点。主要关注因素包括，部署到什么环境中，如生产或开发，谁应该对它们有网络访问权限、收集和处理哪些数据，是常规数据还是敏感数据、API

的存活时间、当然还有它们的版本。一旦完成，需要实施一个流程，将文档添加到任何新创建的 API 或服务中。这应该包括 API 的所有方面，包括速率限制、如何请求和相应、资源共享、可以连接到哪些端点、以及它任何以后需要审计的内容，还需要避免在生产中使用非生产 API，考虑给 API 增加一个时间限制等。

▌日志和监视不足

如果没有日志和监视，或者日志和监视不足，就会导致无法及时发现攻击者的恶意活动，同时也就无法快速定位跟踪可疑活动并作出及时响应，给攻击者留有足够的时间来破坏系统。

API 的脆弱项：

没有生成任何日志、日志级别没有正确设置、或日志消息缺失足够的细节信息;
不能保证日志的完整性;
没有对日志进行持续监视;
API 基础设施没有被持续监视。

建议：

应该有一个记录各种认证和授权事件的系统，比如登陆失败、暴力攻击、访问敏感数据等;
必须建立有效的监测和警报系统，此系统能够发现可疑活动并作出及时反应;
日志应保证有足够的详细信息记录攻击者的行为，识别恶意活动;
如果出现问题，必须通知相关团队。5.必须采用行业标准制定事故相应和恢复计划。