API 接口简单来说就是两个不同的 APP 或不同的平台对接会使用到的，例如一个网站为何能够使用 QQ 或微信一键登陆，这里就是采用了 API 接口对接，当你搭建一个网站后想要让网站能够使用 QQ 或微信一键登陆，那么就需要找对方申请一个 API 接口，然后网站利用对方给予的 API 接口信息实现一键登陆。关于 API 接口安全方面的渗透测试，在网上资料是比较少的，所以如果有错误，还请提出。节选《API 安全技术与实战》书籍中，更详细的内容可以参考该书籍，网上有电子书能够查询到，这里不方便发出来。

1.1. 常用的 API 接口类

这里关于理论方面我也无法解释的太清除，所以主要侧重的可能就是实战操作，至于理论方面可以参考 API 方面的书籍或文章，这里只提一下常见的 API 接口。

1.1.1. API 接口分类

这里可能也是之前的分类，仅作参考。

1.1.1.1. 类库型 API

类库型 API 通常是一个类库，它的使用依赖于特定的编程语言，开发者通过接口调用，访问 API 的内置行为，从而处理所需要的信息。例如，应用程序调用微软基础类库(MFC)。

1.1.1.2. 操作系统型 API

操作系统型 API 通常是操作系统层对外部提供的接口，开发者通过接口调用，完成对操作系统行为的操作。例如，应用程序调用 Windows APl 或 Linux 标准库。

1.1.1.3. 远程应用型 API

远程应用型 API 是开发者通过标准协议的方式，将不同的技术结合在一起，不用关心所涉及的编程语言或平台，来操纵远程资源。例如，Java 通过 JDBC 连接操作不同类型的数据库。

1.1.1.4. WEB 应用型 API

Web 应用型 API 通常使用 HTTP 协议，在企业与企业、企业内部不同的应用程序之间，通过 Web 开发过程中架构设计的方法，以一组服务的形式对外提供调用接口，以满足不同类型、不同服务消费者的需求。例如，社交应用新浪微博的用户登录。

1.1.1.5. 总结

从上述介绍的 4 种 API 类型可以看出，API 并非新生事物，很早就存在着，只是随着技术的发展，这个专有名词的含义已经从当初单一的类库型 API 或操作系统型 API 扩展到如今的 Web 应用型 API 接口，区是商业反展和业务多样化驱动技术不断改进的必然结果。同时，API 的存在对业务的意义也已经从单纯的应用程序接口所定义的用于构建和集成应用程序软件的一组定义和协议，变成了业务交互所在的双方之间的技术约定。使用 API 技术的业务双方，其产品或服务与另一方产品和服务在通信过程中，不必知道对方是如何实现的就像在生活中需要使用电，只要按照要求接上电源就会有电流，而不必知道电流的产生原理自己来发电。不同的行业应用可以独立去构建自己的 API 能力再对外部提供服务，这样做的好处是大大地节约了社会化服务能力的成本，简化了应用程序开发的难度，节省了时间，为业务能力的快速迭代提供了可操作的机会。

1.1.2. API 接口类型

这里就是介绍简单的一些常见的接口，可以扩展看书上的。

1.1.2.1. HTTP 类接口

基于 HTTP 协议的开发接口，这个并不能排除没有使用其他的协议。

1.1.2.2. RPC 类接口

Remote Procedure Calls 远程过程调用 (RPC) 是一种协议，程序可使用这种协议向网络中的另一台计算机上的程序请求服务。由于使用 RPC 的程序不必了解支持通信的网络协议的情况，因此 RPC 提高了程序的互操作性。在 RPC 中，发出请求的程序是客户程序，而提供服务的程序是服务器。 RPC（远程过程调用）是一项广泛用于支持分布式应用程序（不同组件分布在不同计算机上的应用程序）的技术。RPC 的主要目的是为组件提供一种相互通信的方式，使这些组件之间能够相互发出请求并传递这些请求的结果。没有语言限制。

1.1.2.3. web service 类接口

Web service 是系统对外的接口，比如你要从别的网站或服务器上获取资源或信息，别人肯定不会把数据库共享给你，他只能给你提供一个他们写好的方法来获取数据，你引用他提供的接口就能使用他写好的方法，从而达到数据共享的目的。

1.1.2.4. http service 与 web service 区别

本质上其实 http service 与 web service 差不多，但是 httpservice 通过 post 和 get 得到你想要的东西，而 webservice 就是使用 soap 协议得到你想要的东西，相比 httpservice 能处理些更加复杂的数据类型。同时 http 协议传输的都是字符串了，webservice 则是包装成了更复杂的对象。

1.2. API 常见技术

这里只是指常见，同时侧重于实战教程中能够参考的，至于更多的技术可能需要参考其它文章结合，这里无法将所有内容都涉及到，还请谅解。

1.2.1. SOAP

SOAP（Simple Object Access Protocol）简单对象访问协议是交换数据的一种协议规范，是一种轻量的、简单的、基于 XML（标准通用标记语言下的一个子集）的协议，它被设计成在 WEB 上交换结构化的和固化的信息。SOAP 不是 Web Service 的专有协议。SOAP 使用 HTTP 来发送 XML 格式的数据，可以简单理解为：SOAP = HTTP +XML。

1.2.2. REST

REST（Representational State Transfer）即表述性状态传递，在三种主流的 Web 服务实现方案中，因为 REST 模式的 Web 服务与复杂的 SOAP 和 XML-RPC 对比来讲明显的更加简洁，越来越多的 Web 服务开始采用 REST 风格设计和实现。例如，Amazon.com 提供接近 REST 风格的 Web 服务进行图书查找；雅虎提供的 Web 服务也是 REST 风格的。

1.2.3. WSDL

WSDL（Web Services Description Language）即网络服务描述语言，用于描述 Web 服务的公共接口。这是一个基于 XML 的关于如何与 Web 服务通讯和使用的服务描述；也就是描述与目录中列出的 Web 服务进行交互时需要绑定的协议和信息格式。通常采用抽象语言描述该服务支持的操作和信息，使用的时候再将实际的网络协议和信息格式绑定给该服务。

1.3. API 常见的安全漏洞类型

根据安全漏洞发生的机理和原因，对 API 安全漏洞做归类分析，常见的类型如下。

未受保护 API: 在现行的 Open API 开放平台中，一般需要对第三方厂商的 API 接入身份进行监管和审核，通过准入审核机制来保护 API。当某个 API 因未受保护而被攻破后，会直接导致对内部应用程序或内部 API 的攻击。比如因 REST、SOAP 保护机制不全使攻击者透明地访问后端系统即属于此类。
弱身份鉴别: 当 API 暴露给公众调用时，为了保障用户的可信性，必须对调用用户进行身份认证。因设计缺陷导致对用户身份的鉴别和保护机制不全而被攻击，比如弱密码、硬编码、暴力破解等。
中间人劫持: 因 API 的通信链路安全机制不全，攻击者通过攻击手段将自己成为 API 链中的某个受信任链，从而拦截数据以进行数据篡改或加密卸载。此类攻击，通常发生在网络链路层。
传统 Web 攻击: 在这里主要是指传统 Web 攻击类型，通过攻击 HTTP 协议中不同的参数，来达到攻击目的，比如 SQL 注入、LDAP 注入、XXE 等。而攻击者在进一步攻击中，会利用权限控制缺失、CSRF 进行横向移动，从而获取更大的战果。
弱会话控制: 有时 API 身份鉴别没有问题，但对会话过程安全保护不足，比如会话令牌(Cookie 次性 URL、SAML 令牌和 OAuth 令牌）的保护。会话令牌是使 API 服务器知道谁在调用它的主要（通常是唯一的)方法，如果令牌遭到破坏、重放或被欺骗，API 服务器很难区分是否是恶意攻击行为。
反向控制: 与传统的交互技术不同，API 通常连接着两端。传统的应用中大多数安全协议都认为信任服务器端是可信的，而在 API 中，服务器端和客户端都不可信。如果服务器端被控制，则反向导致调用 API 的客户端出现安全问题，这是此类安全问题出现的原因。
框架攻击: 在 API 安全威胁中，有一些符殊行 D 在不同版本，导致攻击者攻击低版本 API 漏洞;同一题，这类威胁统称为框架攻击。最常见的比如同一 API 存在不同版本，导致攻击者攻击低版本 API 漏洞;同一 API 的不同客户端调用，可能 PC 端没有安全问题而移动端存在安全问题等。

1.4. OWASP API 安全漏洞类型

在 OWASP API 安全 Top 10 中，OWASP 延续了 Web 安全的传统，收集了公开的与 API 安全事件有关的数据和漏洞猎人赏金平台的数据，由安全专家组进行分类，最终挑选出了十大 API 安全漏洞的类型，以警示业界提高对 API 安全问题的关注。这十大 API 安全漏洞类型的含义分别如下。

API1-失效的对象级授权: 攻击者通过破坏对象级别授权的 API，来获得未经授权的或敏感的数据，比如通过可预测订单 ID 值来查询所有订单信息。
API2-失效的用户认证: 开发者对 API 身份认证机制设计存在缺陷或无保护设计，导致身份认证机制无效，比如弱密码、无锁定机制而被暴露破解、Token 未校验或 Token 泄露导致认证机制失效等。
API3-过度的数据暴露: 在 API 响应报文中，未对应答数据做适当的过滤，返回过多的、不必要的敏感信息。比如查询用户信息接口时却返回了身份证号、密码信息;查询订单信息时也返回了付款银行卡号、付款人地址信息等。
API4-缺乏资源和速率控制: 在 API 设计中，未对 API 做资源和速率限制或保护不足，导致被攻击。比如用户信息接口未做频次限制导致所有用户数据被盗;文本翻译接口没有速率限制导致大量文件上传耗尽翻译服务器资源。
API5-失效的功能级授权: 与 API1 类似，只不过此处主要指功能级的控制，比如修改 HTTP 方法，从 GET 改成 DELETE 便能访问一些非授权的 API;普通用户可以访问 api/userinfo 的调用，直接修改为 api/admininfo，即可调用管理类 API。
API6-批量分配: 在 API 的业务对象或数据结构中，通常存在多个属性，攻击者通过篡改属性值的方式，达到攻击目的。比如通过设置 user.is_admin 和 user.is_manager 的值提升用户权限等级;假设某 API 的默认接口调用参数为{"user_name":"user", "is_admin":0}，而恶意攻击者修改请求参数，提交值为{"user_name":"attacker", "is_admin":1}，通过修改参数 is_admin 的值来提升为管理员权限。
API7-安全性配置错误: 系统配置错误导致 API 的不安全，比如传输层没有使用 TLS 导致中间人劫持;异常堆栈信息未处理直接抛给调用端导致敏感信息泄露。
API8-注入: 与 OWASP Web 安全注入类型相似，主要指 SQL 注入、NoSQL 注入、命令行注入、XML 注入等。
API9-资产管理不当: 对于 API 资产的管理不清，比如测试环境的、已过期的、低版本的、未升级补丁的、影子 API 等接口暴露，从管理上没有梳理清楚，导致被黑客攻击。
API10-日志记录和监控不足: 对 API 缺失有效的监控和日志审计手段，导致被黑客攻击时缺少告警、提醒，未能及时阻断。比如没有统一的 API 网关、没有 SEIM 平台、没有接入 Web 应用防火墙等。

1.5. 接口数据包中常见问题

Method: 请求方法攻击方式: OPTIONS, PUT, MOVE, DELETE 效果: 上传恶意文件，修改页面等
URL: 唯一资源定位符攻击方式: 猜测，遍历，跳转效果: 未授权访问等
Params: 请求参数攻击方式: 构造参数，修改参数，遍历，重发效果: 爆破，越权，未授权访问，突破业务逻辑等
Authorization: 认证方式攻击方式: 身份伪造，身份篡改效果: 越权，未授权访问等
Headers: 请求消息头攻击方式: 拦截数据包，改 Hosts，改 Referer，改 Content-Type 等效果: 绕过身份认证，绕过 Referer 验证，绕过类型验证，DDOS 等
Body: 消息体攻击方式: SQL 注入，XML 注入，反序列化等效果: 提权，突破业务逻辑，未授权访问等

2. WEB service 类—wsdl 测试

关于这个接口的测试，若不是很熟，不要轻易的测试，同时若全是英文的情况下，无法理解更不要随便的尝试，可能会导致数据删除等情况的发生。同时由于这方面的环境不好搭建，只能在网上寻找相关的内容进行测试，不能保障测试过程中都会一定会遇到存在问题的接口，这里主要是了解测试手段即可。

2.1. 寻找接口页面

关于寻找这个接口页面，可以在前期对网站就是目录扫描等方式进行获取，例如这里使用 Google 查询，这里不一定能百分比搜寻到哦！

语法：edu.cn inurl: asmx?wsdl  ##asmx是语言，但是我尝试切换了一下语言，我发现反而内容更少了。

2.1.1. 查看页面

一般来说看到这个界面，多数都是接口类的页面。

2.1.2. 查看所有

这里如果想要一次性查看所有内容，可以在后面输入?wsdl 即可查看 xml 语言，就会显示所有内容。

?wsdl  ##查看xml语言

2.2. 安全测试

这里可以使用手动测试，也可以使用工具测试，手动测试走效率上来说肯定是没有工具测试那么快的，当然我们也要先介绍一下如果使用手动测试。

2.2.1. 手动测试

所谓的手动测试就是在获取页面的信息后，点击进去，然后手动输入一些信息进行测试，这方面可能需要掌握一定的 API 接口技术能够，否则很多测试都是在盲猜或盲测，有时候可能测半天都测错了，自然就不会出现数据。

2.2.1.1. 选在测试内容

例如这里点击登陆账号验证，我们在界面中的输入框中输入 admin 来进行测试，然后点击下面的 invoke，点击完会自动跳转出现相关的提示信息。

2.2.1.2. 查看回显

这里显示数据处理异常，那么就证明没有 admin 相关的数据，那么就是测试失败了，那这个整个手动测试流程就是这样的，admin 不行可以换成其它的，或者进入其它的输入框中进行测试，均行。

2.2.2. SoapUI 工具测试

这个工具下载需要输入联系方式，这里直接给安装包吧，如果确实需要下载最新的那么就去官网下载吧，安装教程我就不说了，别一个软件都不会安装…..这个工具确实本质上也是手动测试，只是相比较于在网页上测试，更为方便点。

2.2.2.1. 工具下载地址

SOapUI 官网下载地址[1]

2.2.2.2. 添加内容

下载好工具后，点击工具栏 empty，弹出的内容关闭即可，然后再左侧边栏会出现一个 project1 即可。

2.2.2.3. 选在 wsdl

然后右击 project1，选择 add WSDL 即可。

2.2.2.4. 复制地址

在弹出的窗口中，将刚刚的地址复制进行即可，但是要注意一定要复制的是 xml 的链接，也就是在地址后面添加?wsdl 的 xml 状态的结果。

2.2.2.5. 测试内容

然后再看左侧边栏就会出现相关的内容了，然后双击点进去，修改相关的内容，即可看到相关的结果，这个就是工具测试，当然这个工具有点类似于手工测试。

2.2.3. Ready API 工具测试

这个工具由于没找到新版的破解版，都是老版的，同时虽然可以试用，但是在时间操作中，发现需要发送邮箱，但是不知道为何一直发送失败。属于这里也就不提供了，我这里大概截图看一下如何使用吧，同时由于我这个找到的地址是国内了，也就不使用这个工具扫描了，毕竟有影响。这个工具会自动去分析是否存在一些安全漏洞，属于全自动的，只需要将地址复制上去即可。

2.2.3.1. 创建安全测试

这里点击工具栏选择下方的创建安全测试。

2.2.3.2. 选择类型

这里我们再选择需要创建的类型，根据我们刚刚获取到的是 wdsl，那么我们就选择左边这个。

2.2.3.3. 输入地址

将刚刚获取的地址输入进去即可。

2.2.3.4. 安全漏洞

这里就是选择你需要测试的安全漏洞，这里可以直接点击默认。

2.2.3.5. 自动进行测试

添加完毕后，就会进行自动测试，这里只需要工具测试完毕即可，该工具会自动生成一个报告。

2.2.3.6. 查看报告

报告会在当前了下生成。

3. SOAP 类—Swagger 测试

关于 Swagger，其实是 java 中经常使用到的第三方软件，类似于数据库管理系统 phpMyadmin 一样。专业的解释就是 Swagger 是一款 RESTFUL 接口的文档在线自动生成+功能测试功能软件。Swagger 是一个规范和完整的框架,用于生成、描述、调用和可视化 RESTful 风格的 Web 服务。目标是使客户端和文件系统作为服务器以同样的速度来更新文件的方法,参数和模型紧密集成到服务器。这个解释简单点来讲就是说，Swagger 是一款可以根据 resutful 风格生成的生成的接口开发文档，并且支持做测试的一款中间软件。