目录

1. API 安全风险

2. 细说TOP10

1. Broken Object Level Authorization

2. Broken User Authentication

3 Excessive Data Exposure

4 Lack of Resources & Rate Limiting

5 Broken Function Level Authorization 

6 Mass Assignment

7 security misconfiguration

8 injection

9 Improper Assets Management

10 Insufficient Logging & Monitoring

1. API 安全风险

api 安全风险从几个方面综合评估，包括可利用行，技术影响，业务硬，发现可能性。。。

2. 细说TOP10

1. Broken Object Level Authorization

简单来说，就是用户只能访问被授权的对象，否则呢。。就是这个漏洞了。。

例子：

1. /shops/{shopName}/revenue_data.json.- 如果没有正确实施访问控制机制 如果user替换了shopname，试图访问别的shop，甚至可能访问成千上万个shop的数据

2. 一个可穿戴设备，head中有 HTTP request header X-User-Id: 54796.， 如果攻击者可以更改id并且成功访问，那就iu可以访问更改别人的数据了。 X-User-Id value with 54795

如何预防呢？

• 基于用户政策实施正确的授权机制

• 使用鉴权机制来检查login的用户是否有权限来执行请求中的action

• 对于record id 使用随机数GUID

• 测试

2. Broken User Authentication

对于认证，忘记密码，重置密码实施合理的认证，保护。否则就有这个问题了

• 允许攻击者对同一个用户暴力破解，没有lockout机制

• 允许弱密码

• 在url中发送认证细节，例如 token，key，密码

• 没有验证token的真实性

• 使用明文，弱哈希密码

• 弱加密key

就是说如果认证需要sms的六位验证码，攻击者大量重放，遍历，暴力之后成功认证了，就是这么个情况。

如何预防呢：

1 了解认证机制如何工作如何使用

2 不要重造轮子，自己去搞认证，token生成，密码存储。使用标准的东西

3 忘记密码，重置密码跟认证是一样的，要防止暴力破解，实施lockout 机制

4 MFA

5 实现反暴力破解机制，以减少凭据填充、字典攻击和暴力破解对身份验证端点的攻击。这个机制应该比常规更严格API上的限制机制。

6  实施账户lockout /captcha 

3 Excessive Data Exposure

说明 ：The API returns sensitive data to the client by design. This data is usually filtered on the client side before being presented to the user. An attacker can easily sniff the traffic and see the sensitive data.

简单来说就是：返回了过多的信息，

例如 /api/articles/{articleId}/comments/{commentId} 返回了评论者的敏感信息，这个就是PII ，

如何预防

• 不要依赖client端来过滤敏感信息

• review response 确保只含有必须的信息

• 避免使用 generic methods such as to_json() and to_string(). Instead, cherry-pick specific properties you really want to return.

• 识别敏感信息PII， review所有返回，看是否存在问题

• 4 Lack of Resources & Rate Limiting

没有实施rate limit限制可能导致dos攻击，导致没反应，影响可用性。

以下item不加限制均可导致此类漏洞

1. 执行超时

2. 最大可分配内存

3. 进程数量

4. payload size

5. 每个client的请求数

6. 每个request 每页的最大record数量

例子：

1. 攻击者通过向/api/v1/images发出POST请求上传大图片。当上传是完成后，API会创建多个不同大小的缩略图。由于上传图片的大小，可用的内存在创建缩略图期间耗尽，API变得无响应。

2. 我们有一个应用程序，它在每个页面限制200个用户的UI上包含用户列表。用户列表为

3. 使用以下查询从服务器检索:/api/users?page=1&size=200。攻击者将size参数更改为200000，导致数据库出现性能问题。同时，API变得无响应，无法处理来自此或任何其他客户端(也称为DoS)的进一步请求。同样的场景也可能引发Integer Overflow或Buffer Overflow错误。

预防

1. docker 容易限制 memory，CPU，重启数量，

2. 实施client在固定时间内访问的次数限制

3. 访问超过limit的时候通知用户，

4. server端validation 查询字符串和请求body参数，尤其是控制record数量的参数

5. 定义并强制所有传入参数和有效负载(如maximum)上的数据的最大值，字符串的长度和数组中元素的最大数量

5 Broken Function Level Authorization 

deny by default

admin的功能实施鉴权

6 Mass Assignment

api endpoint 自动把client输入转为内部object属性，么有考虑敏感信息泄露的情况，所以攻击者可以利用来update目标属性

说人话就是把不该暴露的给暴露出去了

Examples for sensitive properties:

• Permission-related properties: user.is_admin, user.is_vip should only be set by admins.

• Process-dependent properties: user.cash should only be set internally after payment verification.

• Internal properties: article.created_time should only be set internally by the application.

例子： credit balance不该暴露的，攻击者可以重放并且篡改。。。

A ride sharing application provides a user the option to edit basic information for their profile. During this

process, an API call is sent to PUT /api/v1/users/me with the following legitimate JSON object:

{"user_name":"inons","age":24}

The request GET /api/v1/users/me includes an additional credit_balance property:

{"user_name":"inons","age":24,"credit_balance":10}

The attacker replays the first request with the following payload:

{"user_name":"attacker","age":60,"credit_balance":99999}

Since the endpoint is vulnerable to mass assignment, the attacker receives credits without paying.

预防

• 避免使用自动的绑定用户输入

• 属性白名单，只接受应该接受的

• 明确定义payload

• 7 security misconfiguration

说明： 包括 unpatched flaws，未加密的文件，未授权的访问。

原因

• 没有加固，没有正确实施加固

• 没有升级patch

• enable没用的feature

• tls missing

• cors policy

• error message 包换stack track

例子：history文件中有运维的api

预防

• hardening process
• review configuration， orchestration files，api组件，cloud services
• 自动化流程持续评估配置有效性
• 定义api response apyload schemas，包括error response

$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F
'appid=$(/etc/pod/power_down.sh)'

• api 清单，在哪个环境，什么网络，什么版本。。。
• 全面清晰的文档。。。
• 文档自动化
• 新的api，执行风险分析，

10 Insufficient Logging & Monitoring

• log 所有的认证失败，拒绝访问，输入验证失败
• 格式化的log信息，能够给到log 管理平台来识别恶意的攻击者
• log也是敏感信息
• SEIM系统来管理，lo
• 配置看板，alert，有可疑活动可以报警。。。