乐趣区

关于api:API安全测试规范

jiezi

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 接口而应用生产数据；
退出移动版