API安全测试规范

本文主要是介绍API安全测试规范，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

1 失效的对象级授权

1.1 概述

失效的对象级别授权指未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据（直接的对象引用或限制的URL）。例如：访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。

1.2 测试用例

在发送的请求中改变对象的ID

/shops/{shopName}/revenue_data.json
通过遍历URL中的{shopName}，攻击者获取到不同商户的销售数据。

通过监控可穿戴设备的网络流量，其HTTP PATCH请求中的自定义请求头中存在字段: X-User-Id: 54796。通过替换X-User-Id字段的值为54795，攻击者接收到成功的HTTP响应，并可以修改其他用户的账户数据。

2 失效的用户身份认证

2.1 概述

用户身份认证过程中出现的安全问题，如弱口令、明文存储、弱加密、密码爆破、GET方式传输令牌和密码、认证绕过等。

2.2 测试用例

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

3 过度的数据暴露

3.1 概述

API接口被调用时返回了大量数据，很多数据可能都是不必要的，应将用户看到的内容范围限制为必需内容。

3.2 测试用例

某接口查询欠费金额，能否返回余额、账单等其他信息。

4 资源缺乏和频率限制

4.1 概述

API接口未对客户端/用户可以请求的资源大小或数量施加任何限制。这不仅会影响API服务器的性能，从而导致拒绝服务（DoS），而且还为诸如暴力破解之类的身份验证漏洞敞开了大门。

4.2 测试用例

当应用包含一个每页可以显示200个用户的列表界面时，我们可以使用/api/users?page=1&size=100查询从服务器中检索用户列表。攻击者可以将size参数篡改至2000000，从而导致数据库出现性能问题。同时，API将无法响应该客户端的其他请求，或其他客户端的请求，形成DoS。
攻击者通过向/api/v1/images发送POST请求来上传大尺寸的图像。在上传完成后，API将创建多个不同大小的缩略图。由于上传的图像过大，可用内存在创建缩略图时被耗尽，API将无法响应。

5 失效的功能级授权

5.1 概述

攻击者利用漏洞将合法的API调用发送给他们不应访问的API 端点。这些端点可能会暴露给匿名用户或常规的非特权用户。由于API更加结构化，并且更易于预测访问API的方式，因此更容易发现API中的这些缺陷（如，将HTTP方法从GET替换为PUT，或将URL中的 “用户”字符串更改为“管理员”）。

5.2 测试用例

在仅允许受邀用户加入的应用程序注册过程中，移动应用程序将触发对GET /api/invites/ {invite_guid}的API调用。响应包含一个JSON，其中包含有关邀请的详细信息，包括用户的角色和用户的电子邮件。攻击者复制了请求，并修改“role”值为admin，向/api/invites/new发出POST请求。管理员只能使用管理控制台访问该端点，
该控制台未实现功能级别的授权检查。攻击者利用此问题并向自己发送邀请以创建管理员帐户：
```
POST /api/invites/new
{“email”:”hugo@malicious.com”,”role”:”admin”}  
```

6 批量分配

6.1 概述

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

6.2 测试用例

一个乘车共享应用程序为用户提供了编辑个人资料基本信息的选项。用户可以更新“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}
```
攻击者无需支付即可篡改自己的信用值。

7 安全配置错误

7.1 概述

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

7.2 测试用例

未配置或错误配置CORS（跨域资源共享）策略;
错误提示泄漏了调用栈跟踪信息或其他敏感信息;
S3 bucket权限控制不当，包括非授权访问、下载和上传；
确定API只能被特定HTTP方法访问，其他的HTTP方法访问都应该被禁止（如， HEAD方法）；

8 注入

8.1 概述

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

8.2 测试用例

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

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Anything [
<!ENTITY entityex SYSTEM "file:///etc/passwd">
]>
<abc>&entityex;</abc>

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

9 资产管理不当

9.1 概述

资产管理存在问题，如暴露测试接口地址、未下线旧版本接口。

9.2 测试用例

旧版本或者存在漏洞版本的API接口未下线，在没有打补丁的情况下持续运行。如：api.someservice.com/v2，将URL中的v2替换为v1使攻击者能够利用旧版本的API接口发起攻击；
测试接口对公网开放；
非生产API接口而使用生产数据；

这篇关于API安全测试规范的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！