1. 前置基础

API是应用程序编程接口（Application Programming Interface）的缩写，是软件系统中不同组件之间进行通信和交互的接口。它是一组定义、规范和协议，用于编写应用程序的软件接口，允许不同应用程序之间进行相互通信和交互。API通常由一系列的函数、协议、工具和标准组成，它们提供了一组约定的方法和规则，允许应用程序之间相互通信、共享数据和服务。API常用于访问网络服务、操作操作系统、访问数据库等，因此它是现代软件开发中非常重要和常用的技术之一。

常见的API面临的安全问题包括：

API面临的安全风险包括：
1.认证和授权问题：API需要进行有效的身份验证和授权以防止未经授权的访问和使用。

2.SQL注入攻击：攻击者利用API中的漏洞发送恶意代码来获取敏感数据。

3.信息泄露：API可能会泄露敏感数据，如用户个人信息或业务机密信息。

4.拒绝服务攻击：攻击者可能会发送大量请求来占用API的资源，导致服务不可用。

5.恶意软件：恶意软件可以使用API来传输和分发恶意代码，包括病毒、间谍软件和木马。

6.未加密的数据传输：未加密的数据传输可能会导致信息泄露和数据被窃取。

7.CSRF攻击：攻击者可以通过跨站请求伪造攻击来利用API执行未经授权的操作。

8.DoS攻击：API可能会受到分布式拒绝服务攻击，导致服务不可用。

9.JSON注入：攻击者可以通过篡改JSON消息来进行恶意操作。

10.代码注入：攻击者可以通过篡改API的代码来执行恶意代码。

1.1 认识crAPI

crAPI是一个针对API安全的学习和研究平台，在该工具的帮助下，广大研究人员可以轻松学习和了解排名前十的关键API安全风险。因此，crAPI在设计上故意遗留了大量安全漏洞，我们可以通过 crAPI学习和研究API安全。

crAPI采用了现代编程架构，该工具基于微服务架构构建，只需建立一个账号，即可开启我们的API安全研究之旅。

crAPI的挑战是让您尽可能多地发现和利用这些漏洞，破解crAPI有两种方法-第一种是将其视为一个完整的黑盒测试，在那里你不知道方向，只是尝试从头开始理解应用程序并进行破解。第二种方法是先了解crAPI提供的漏洞，然后自己动手尝试去利用它们。

当然，本着学习的态度，我们在本文中将参考其他几篇文章对API所面临的安全风险进行一个系统的学习，以供后续的安全学习。

1.2 环境搭建

首先，附上 crAPI 项目的 Giithub 地址：
https://github.com/OWASP/crAPI

还有 OWASP API Security Project 可以参考：
https://owasp.org/www-project-api-security

安装靶场的话，可以使用多种方式，本文直接使用 docker 搭建（需要先安装 docker 以及 docker-compose） ，docker 启动命令如下：

#1.curl命令直接获取docker编排文件，也可以直接下载git源码，进入对应路径下进行操作
curl -o docker-compose.yml https://raw.githubusercontent.com/OWASP/crAPI/main/deploy/docker/docker-compose.yml

#2.拉取镜像文件
docker-compose pull

#3.运行对应的环境
docker-compose -f docker-compose.yml --compatibility up -d

排错中用到的命令：

#停止docker中所有运行容器
docker stop $(docker ps -q)

#关闭所有已经停止了的容器
docker rm $(docker ps -aq)

#删除docker的所有数据卷
docker volume rm $(docker volume ls -q)

#删除所有镜像
docker image rm $(docker image ls -a -q)

由于最终的部署环境为在kali linux上运行docker，在本地进行测试。则需要对原有的compose文件进行修改。可以使用vim中的全局变量修改功能：

#1.编辑对应文件
┌──(root💀kali)-[~/APILAB/crAPI]
└─# vim docker-compose.yml

#2.全局替换 --- 输入":"进入末行模式，并输入命令进行替换
:1,250 s/127.0.0.1/192.168.2.159(本地测试机可以访问到的IP)/g

1.3 API的分类与鉴别

API可以按照不同的分类方式进行划分，以下是几种常见的分类方式：

1.按照功能分类：

• Web API：主要用于通过网络交互的应用程序，如HTTP API、RESTful API等。
• 数据库 API：用于访问数据库系统的API，如JDBC、ODBC等。
• 图形界面 API：用于创建图形界面的API，如Java Swing、Windows API等。

2.按照接口类型分类：

• 开放 API：对外公开的接口，可以通过网络访问。
• 内部 API：仅在企业内部使用的接口，如微服务API。

3.按照数据格式分类：

• JSON API：使用JSON格式的API。
• XML API：使用XML格式的API。

4.按照托管方式分类：

• 内部 API：在本地服务器上托管的API。
• 云 API：在云平台上托管的API，如AWS API Gateway、Google Cloud Endpoints等。

以上分类方式只是一种常见的分类方式，具体根据不同的需求和应用场景可以进行灵活的分类和组合。

RESTful API (Representational State Transfer API) 是一种 Web API 设计风格和体系结构，它基于 HTTP 协议，建立在客户端和服务器之间的无状态连接上。RESTful API 的核心理念是将所有的 Web 资源看作是一个唯一的 URI (Uniform Resource Identifier)，并通过 HTTP 方法（GET、POST、PUT、PATCH、DELETE）来对这些资源进行操作。RESTful API 可以使用不同的数据格式（如 JSON、XML）进行通信，具有简单、灵活、可扩展等优点，因此越来越受到广泛的应用。

要发现网页内的API请求，可以按照以下步骤：

1. 打开浏览器的开发者工具，通常可以通过快捷键 F12 打开。
2. 切换到Network（网络）标签页，重新加载页面。
3. 查看请求列表，其中可能包含网页内的API请求。这些请求通常是XHR（XMLHttpRequest）类型的请求。
4. 点击请求列表中的请求，查看请求详情，可以查看请求的URL、请求方式、请求头信息和请求体信息。
5. 根据请求的URL和请求方式可以确定该请求是API请求，还是页面自身的请求。
6. 通过这些信息，可以分析API请求的参数和数据，进而实现API的调用和数据提取。

需要注意的是，有些网站可能会使用加密或者防抓取措施来隐藏API请求，此时需要先进行网页解密或者反爬虫技术破解，才能发现API请求。

2. 漏洞验证

2.1 失效的对象级别授权

Broken Object Level Authorization

当API失效后，对象级别授权指的是在API调用中受到影响的特定对象的授权。这可能会影响用户或应用程序对某些对象的访问权限，从而导致无法执行需要该对象的操作。例如，在一个CRM系统中，如果API失效导致用户无法访问客户联系人列表，则他们将无法查看或编辑客户联系人信息。因此，当API失效时，重要的是要检查哪些对象的授权已受到影响，并根据需要重新授权来恢复受影响的操作。

挑战1：访问其它用户车辆的详细信息

1.获取车架ID信息

我们在评论区域进行点击对象时的抓包分析可以看到：

正常用户看到的：

使用burp抓包后看到的：返回的json数据明显多于当前页面需要显示的数据信息。

我们尝试在别的页面跳转到评论区时可以看到：

当然，这类问题我们在火狐浏览器内部也可以通过network界面的返回json数据对比显示类型，就可以发现端倪：

目前收集到的车架ID信息有：

Robot --- ec9c90c0-8647-47f7-960e-4d0012cec600
Pogba --- 8104792f-a7a2-44ae-ba99-d8a5de8ae8f6
Adam --- 887eb746-2d93-4373-8b93-56f1cd7dbd51

2.测试车辆定位功能，寻找定位API调用信息

注意：对于这里的车辆，我们如果是新注册的用户则需要到8025端口上的maillog服务上去查看车架号邮件，进行绑定即可。车辆随机分配。

进行抓包分析：

3.尝试越权查询他人车辆的ID信息

结合上一步获取到的车架信息，我们尝试获取其他用户的车辆定位信息：

挑战2：访问其它用户的机械报告

1.发送维护请求

2.抓包分析请求

我们发现，服务器返回了报告的访问URL位置，在界面内我并未找到看维修报告的地方。估计是需要登陆维修工程师的账号才行。

3.尝试直接访问报告url提示我们必须携带JWT TOKEN

直接将请求资源地址嫁接到先前的GET请求内部，则可以请求成功，此时我们在尝试修改参数，直接获取到其他用户的维修报告信息。

总结：

在本例中，我们的思路是通过过量的信息暴露获取其他用户车架号，结合车辆定位功能调用的API我们直接通过车架号遍历可以实时定位到用户的车辆位置。如果这是真实的部署环境，则对于掌握这一操作的人来说，其危害十分巨大。我们还通过对维修报告提交接口的返回信息进行测试，修改其传递的url参数，以此实现了查看其他用户维修报告的操作。

归根结底，失效的对象授权个人理解就是针对认证后的API请求未进行权限的鉴别，因为不同的业务逻辑需要鉴权的程度不一样，不同的业务逻辑需要返回的处理数据也不一样。如果不对这些API业务逻辑进行深度分析，做出来的简单的入口式鉴权，其实还是形同虚设。同时这又对开发者来说又是一个相对较大大工作量。

2.2 失效的用户身份验证

Broken User Authentication

API失效的用户身份验证是指在使用API时，用户的身份验证信息已经过期、被撤销、或者与API访问权限不符合，导致API无法正常访问和使用的情况。这种情况下，用户需要重新进行身份验证，并获取新的API访问权限，才能够正常使用API。API失效的用户身份验证通常会在API文档中有相关的说明和处理方式。

挑战3：重置其它用户的密码

1.分析重置密码的执行逻辑

可以看到大致的逻辑和我们当前的主流重置是一样的，输入邮箱，邮箱发送验证码即可，我们输对了验证码即可进行修改。

抓包分析：

2.敏感信息获取

还是刚才我们获取敏感信息的位置，我们可以进行邮箱信息的收集

nickname: "Robot", email: "robot001@example.com", vehicleid: "ec9c90c0-8647-47f7-960e-4d0012cec600"
nickname: "Pogba", email: "pogba006@example.com", vehicleid: "8104792f-a7a2-44ae-ba99-d8a5de8ae8f6"
nickname: "Adam", email: "adam007@example.com", vehicleid: "887eb746-2d93-4373-8b93-56f1cd7dbd51"

3.验证码爆破

我们发现尝试爆破后服务器会进行限频操作：

将这里的v3改为v2在此进行爆破尝试：

我们尝试修改adam007@example.com的密码。

本例中针对爆破行为做了限制的版本轻易的被通过修改版本绕过，这也是开发工作中的疏忽，对于已经下线了的API应当予以封禁处置，而不是自以为不再使用就不会有人发现它。

2.3 过多的数据暴露

Excessive Data Exposure

API的过多的数据暴露可能会导致数据泄露、安全漏洞、性能问题等问题。具体来说，过多的数据暴露可能会导致以下问题：

1. 数据泄露：如果API暴露了敏感数据，攻击者可能利用这些数据进行欺诈、钓鱼、身份盗窃等攻击。
   
2. 安全漏洞：暴露的数据可能包含敏感信息，攻击者可以利用这些信息发现安全漏洞，从而进一步攻击系统。
   
3. 性能问题：如果API暴露了过多的数据，可能会导致网络带宽和系统资源的过度使用，从而导致性能下降。

因此，API设计人员应该合理地暴露数据，仅暴露必要的信息并采取必要的安全措施，以保护用户数据的安全性和隐私性。

挑战4：找到泄露其它用户敏感信息的API接口

/community/api/v2/community/posts/recent

挑战5：找到泄露视频内部属性的API接口

1.找到上传视屏的模块，抓包后并看不到任何API请求的出现。我们在这里测试修改名字的模块

可以看到详细的视屏内部编码信息

2.4 资源缺乏和速率限制

Lack of Resources & Rate Limiting

API资源缺乏和速率限制是API服务提供者可能会实施的两个策略，用于保护其API服务并确保可靠性和可用性。这些策略可以帮助控制API的访问，防止滥用和DOS攻击等问题。

API资源缺乏通常是指API服务提供者限制API资源的可用数量，例如API调用次数、数据传输量或其他资源。这可以防止API的滥用和意外超载，并保证API的可靠性和性能。

速率限制是一种限制API调用速率的策略，即在一定时间内限制API调用次数。这可以防止恶意攻击和过度使用API，从而保护API服务的可靠性和可用性。

这些策略通常作为API服务提供者的服务条款的一部分公开通知给API使用者。API使用者应该仔细阅读这些策略，并遵守它们，以确保仍然有权访问API服务。

挑战6：使用 “contact mechanic” 功能完成第7层DoS

1.我们还是先找到功能实现的位置，对其进行抓包分析

数据包分析，分析请求体是否可以进行参数调整

从英文的字面意思上来看:

#是否打开请求失败重复功能
"repeat_request_if_failed":false,
#请求失败后重复的次数
"number_of_repeats":1

2.看到这里就一目了然了，我们尝试打开这个功能，制造一次失败的请求，然后在修改重放次数为一个很大的数字，即可发起资源耗尽的攻击。

2.5 失效的功能级别授权

Broken Function Level Authorization

API的失效的功能级别授权是一种安全机制，用于控制API的访问权限。它通常指的是当用户的访问权限被更改或收回时，API会失效相应的功能级别授权。这意味着用户只能访问其授权范围内的资源和功能。

例如，假设一个用户被授予了访问一个特定API的读取权限。如果管理员撤销了该用户的读取权限，则该API会自动失效，该用户将无法再访问该API。同样地，如果该用户被授予了写权限，但管理员仅撤销了该用户的读取权限，则该用户将只能访问该API的读取功能，但无法进行写操作。

这种机制可以有效地保护API的安全性和保密性，避免未经授权的用户访问API的敏感信息。

挑战7：删除另一个用户的视频

1.找到先前对video进行信息收集的地方，我们尝试将请求方法修改为DELETE，测试接口对方法的支持情况：

2.根据以往的经验，推测此处的user为权限控制路径，我们将user修改为admin进行尝试：

登陆回之前的页面，查看视屏是否还在：

可以看到视屏已经丢失(如果还在很有可能是缓存，换一个浏览器护着重新进入浏览器进行访问即可)

3.此处通过修改ID尝试对其他用户的视频信息进行修改

这里可以通过ID对其他用户已经上传的video进行删除操作

2.6 批量分配 / 大量赋值 / 自动绑定漏洞

Mass Assignment

API Mass Assignment是一种接口安全问题，指客户端可以通过API一次性提交多个参数，包含敏感数据，导致意外或未经授权的数据修改操作。例如，一个用户更新其个人信息时，可以通过API提交很多参数，并且不小心包含了一个“isAdmin”的参数，将其设置为true，从而使用户成为管理员，这将导致安全问题。

为了防止API Mass Assignment攻击，可以采用以下措施：

1. 后端应用程序应该定义可更新的属性列表，严格限制可以由客户端更新的属性。
   
2. 对于敏感数据，如密码或激活状态等，应该使用单独的接口进行更新，而不是使用同一个API。
   
3. 应该对所有输入进行验证和过滤，确保请求的参数是合法的。
   
4. 应该限制用户的访问权限，只允许他们执行其权限范围内的操作。
   
5. 使用安全框架或库来帮助防止API Mass Assignment攻击，如Spring Security。

挑战8：免费获得一件物品

1.先买一件东西尝试进行数据报文的分析

2.尝试修改请求方法为GET，并对参数进行修改，修改为刚测试的订单id 6

3.修改请求参数为PUT，测试是否可以对已经生效的订单进行数量修改

回到系统内我们发现，我们的座椅已经有了十分可观的数量修改。

之前只是十块钱买了一个，现在直接白嫖19个椅子。

挑战9：将您的结余增加1000元或以上

还记得上一个挑战中我们对订单的数量修改嘛，同理，如果对状态和数量动些手脚会怎么样呢？

根据回显，我们需要祭出许久未用的网易词典逐一翻译：

'delivered'          已交付
'return pending'     返销
'returned'               已归还

查看余额：+3000￥

挑战10：更新内部视频属性

修改视屏名称的时候进行操作，发现可以修改 conversion_params的属性值。

2.7 SSRF

API的SSRF指Server-Side Request Forgery，是指攻击者利用存在漏洞的API接口发送恶意请求，以获取未授权的数据或攻击其他内部系统。攻击者通过篡改请求的URL或参数等方式向公共API发送请求，利用API服务器从指定的URL下载图片、文件等资源，实现攻击。

攻击者通过构造恶意的请求，将请求发送给API服务器，服务器会将请求转发到指定的URL上，如果攻击者能够成功篡改请求链接或参数，就可以控制服务器访问其它的内部系统或者第三方资源，导致安全问题。通过API的SSRF攻击，攻击者可以访问与服务器隔离的内部网络，获取私密数据或实施其他攻击。

挑战11：让crAPI发送一个HTTP调用到“www.baidu.com”并返回HTTP响应

1.找到联系维修工程师的API接口

2.修改链接为http://www.baidu.com

2.8 NoSQl Injection

NoSQL注入是指攻击者利用NoSQL数据库系统的特殊性质进行注入攻击的一种安全漏洞。与关系型数据库的SQL注入攻击类似，NoSQL注入攻击也利用应用程序对用户输入不进行充分验证和过滤的漏洞，向数据库系统发送恶意的查询语句，从而获取不应该被访问的数据或绕过身份验证等安全限制，导致系统被攻陷。不同于SQL注入，NoSQL注入使用的是特定的查询语言和数据存储方式来执行攻击，其攻击方式不同于传统的SQL注入攻击。

挑战12：想办法在不知道优惠券代码的情况下获得免费优惠券

1.找到验证优惠卷的接口 ，进行nosql注入的语句尝试

请求抓包：

修改内容：“$ne"是MongoDB的查询操作符之一，其含义为"不等于”，用于查询某个属性不等于指定值的文档。

2.获取到一张优惠券：TRAC075

3. 总结

结合靶场内容和AI给出的结论可以大致得出API可能会受到以下安全风险的威胁：

1. 认证和授权问题：未授权的用户可能会使用API，在没有经过充分身份验证的情况下访问敏感数据或执行敏感操作。

2. 注入攻击：黑客可能会利用API中的漏洞，将恶意代码注入到应用程序中，以窃取敏感数据或执行恶意操作。

3. 僵尸网络攻击：攻击者可能会使用API来构建僵尸网络，这些网络可以被用来进行DDoS攻击。

4. 数据泄露：攻击者可能会利用API的漏洞来获取未授权的访问权限，从而窃取敏感数据。

5. DOS和DDoS攻击：攻击者可能会使用API来发送大量请求，从而使API停止响应或变得缓慢，导致拒绝服务攻击。

6. 恶意软件：攻击者可能会使用API来分发恶意软件，例如通过API传播病毒或恶意软件。

7. 社交工程攻击：攻击者可能会利用用户的信任来获取API访问权限，从而窃取敏感信息或执行恶意操作。

8. API漏洞：API可能存在未知漏洞，这些漏洞可能会被黑客利用来攻击API系统。

我们重新梳理API的处理流程，首先我们向服务器某些API路径发起特定方法的请求，在请求体中携带上对应的JSON或者XML格式的数据用于参数传递。之后服务器根据我们给到的参数返回给客户端结果，经过客户端解析后显示在客户端的页面上。

这其中概括的说一个处理流程就是 “谁，用了什么方法，提交了多少个什么样的参数，发起了多少次请求，访问了那个路径。服务器又返回了什么数据。” 只有把这些流程或者说访问的行为弄清楚了，才能更好的解决API面临的安全风险。

给API鉴权是为了解决谁用什么方法访问那个路径的问题，当然这其中还涉及到参数的范围控制，作为正常用户不应该传递不属于自己职责范围的参数以获取返回数据。

参数的控制就需要我们尽量的将API敏感控制类参数放到服务端，不允许用户控制。参数的数量，数据类型，正负都需要进行安全限制过滤，切不可以为这些东西用户无法控制就觉得安全了。只要在数据包层面能进行修改的，都是存在安全风险的。

从服务器返回内容来看，数据的类别是否超过所需类别，敏感的个人信息是否进行对应的脱敏，无一不关乎着API场景下的数据安全。在返回数据中，我们做好返回数据的匹配性是十分重要的，如此才能确保数据安全在API场景中坚如磐石。

---

参考文章：
https://www.freebuf.com/articles/web/348982.html
https://www.freebuf.com/articles/security-management/343273.html
https://www.freebuf.com/vuls/332312.html
自动化AP漏洞I挖掘
https://zhuanlan.zhihu.com/p/561094111