接口安全测试常用的测试点

小码菌

已于 2023-04-01 10:03:23 修改

阅读量569

点赞数 2

文章标签：安全性测试

于 2023-04-01 09:40:52 首次发布

本文链接：https://blog.csdn.net/qq_37772593/article/details/129892878

版权

API十大安全风险：

1.失效的对象级别授权
2.失效的用户身份验证
3.过度的数据暴露
4.资源缺乏和速率限制
5.失效的功能级授权
5.批量分配
7.安全配置错误
8.注入
9.资产管理不当
10.日志和监视不足
**

第一部分：

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

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

使用 burpsuite对 oid 参数进行遍历，尝试越权访问他人订单详情，可以看到成功查看到了他人订单信息。

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

案例：

未校验令牌的有效性
更新密码接口微信啊之请求频率，旧密码参数可暴力破解
短信验证码或邮箱验证码有效期超过10分钟或长度小于6位
3、过度数据暴露：开发人员把所有的对象属性都暴露给最终用户

防御：
不要以拦客户端来过滤敏感数据
检查API的响应，确认其中仅包含合法数据
停止用通用API向用户发送一切的过程(必须避免将所有信息直接执行toString(),to_json()，然后发送给客户端，只选择返回给授权用户的属性，并专门发送这些信息)
对于敏感数据应使用加密技术进行保护。
4、资源缺乏和速率限制:
随着资源的缺乏和速率的限制，每个API都有有限的资源和计算能力，这取决于它的环境。当有太多请求同时进来，API没有足够的计算资源来处理这些请求就会出现这种漏洞。

然后，API可能变得不可用或对新的请求没有反应；如果API的速率或资源限制没有被正确设置，或者限制没有在代码中被定义，那么 API 就很容易出现这个问题。

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

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

措施：防止这种 API 漏洞尤其重要，因为攻击者不难找到结构化函数，因此所有业务层面的功能都必须使用基于角色的授权方法进行保护。一定
要在服务器上实现授权，不能试图从客户端保证功能的安全。在创建功能和资源级别时，用户应该只被赋予做它们需要的事情的权限，实践最小权限的方法
6、批量分配：后端应用对象可能包含许多个属性，其中一些属性可以有客户端直接更新(如user.fristname,user.address),而某些属性则不应该跟新(如user.isvip标志)

如何防止：
如果可能，请避免使用将客户输入自动绑定到代码变量或内部对象中的函数。
仅将客户端可更新的属性列入白名单。
使用内置功能将客户端不应该访问的属性列入黑名单
如果可能，为输入数据有效负载准确、明显的定义和实施schema格式
7、安全配置错误：安全配置错误可以发生在一个应用程序堆栈的任何层面，包括平台、web服务器、应用服务器、数据库、框架和自定义代码。

案例：比如攻击者在服务器的根目录下找到.bash_history文件，该文件包含DevOps团队用于访问API的命令,攻击者可由此命令获取权限认证信息（Zm9vOmjhcg==base64解码：foo:bar）以及接口信息。

$curl -X GET ‘https://api.server/endpoint/’-H ‘authorization:Basic Zm9vOmjhcg==’
8、注入：服务端未对客户端提供的数据进行验证、过滤或净化，数据直接使用或者凭借到SQL/NoSQL/LDAP查询语句，OS命令、XML解释器和ORM(对象关系映射器)/ODM(对象文档映射器)中，产生注入攻击。

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

<?xml version="1.0" encoding="utf-8"?>

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

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

措施：应该做到对所有的 API、他们的用途和版本进行严格的盘点。主要关注因素包括，部署到什么环境中，如生产或开发，谁应
该对它们有网络访问权限、收集和处理哪些数据，是常规数据还是敏感数据、API的存活时间、当然还有它们的版本。一旦完成，需要实施一个流程，将文档添加
到任何新创建的 API 或服务中。这应该包括 API 的所有方面，包括速率限制、如何请求和相应、资源共享、可以连接到哪些端点、以及它任何以后需要审计的内
容，还需要避免在生产中使用非生产 API，考虑给 API 增加一个时间限制等。

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

API 的脆弱项：

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

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

第二部分

*日常的接口测试工作主要是验证接口的功能性（入参、出参、边界值等），我在接口测试过程中遇到的一些接口安全性的问题，整理成了通用的测试点，不一定适用于全部的产品，仅做参考。

一、登录接口校验
(1) 验证登录接口中密码是否密文传输

这个测试点听起来很荒唐，应该大家都知道密码应该加密，但是在很多时候，研发人员为了赶工就会忽略这个点，所以建议大家测试登录功能的时候，一定要F12查看一下登录接口中密码是否是密文。

(2) 验证登录接口是否可以爆破登录

对于一些安全性较高的系统，测试的时候有必要验证一下是否可以爆破登录，可以使用Burpsuit进行爆破登录测试。当然现在很多系统都是用手机号码进行动态登录，如果还是常规的账户和密码登录，就一定要对安全性提出质疑了，密码强度符合等保要求么？验证码要不要加上去？

二、接口规则校验
(1) 验证接口类型是否合理

理论上来说，除了查询接口使用GET，其余的接口都应该使用POST，这样接口的安全性更高。沐沐以往的接口测试过程中确实遇到了不少业务接口使用get，参数拼接在url上及其不安全。此外，还有一个特殊情况，即不需要用户登录的系统，查询类的接口也不建议使用GET，在安全扫描中会出现跨站点请求伪造的问题。

(2) 验证新增和修改接口是否是独立的接口

这个测试点有点离谱了，沐沐在测试过程中发现新增和修改接口共用同一个，这样似乎是没有什么问题，但是后期遇到了一些复杂的业务逻辑，新增和修改接口融合在一起，导致了生产数据被篡改。所以接口设计还是要严谨一点，新增和修改接口尽量是独立的接口。

(3) 验证POST接口中是否将参数拼接成URL

沐沐曾经还遇到过将post接口的参数拼接到了url上，如果数据量较大的时候，url字符长度太大接口就会报错，可能此类情况并不常见，但是遇到过就记录下来了。

三、接口越权校验
接口的越权分为水平越权和垂直越权，我们可以通过Burpsuit、Appcan等工具进行越权测试，测试过程中也遇到了以下问题：

验证接口url上是否区域编码、身份证号等参数；
验证接口url上存在true或false时，进行篡改，功能、数据是否越权；
验证接口url上存在type=1或2时，进行篡改，功能、数据是否越权；
接口参数中存在pagesize或者size时，进行篡改，是否进行最大值限制；
接口body参数中存在身份证号码时，篡改参数值，接口是否返回正确提示。