绪论

如果各位师傅觉得有用的话，可以给我点个关注~~ 如果师傅们有什么好的建议也欢迎联系我~~ 感谢各位师傅的支持~~

正文部分

题记：眼花缭乱的接口，始终如一的本质

本文是fkalis在早期在i春秋的投稿，由于文章是之前写的，可能存在一些不足，例如：GraphQL协议一些其他的测试方法，没有补充实战案例等，这些我后续都会出系列文章进行补充，请各位师傅见谅！

本篇文章作者fkalis，本文属i春秋原创奖励计划，未经许可禁止转载。 i春秋原文链接：https://bbs.ichunqiu.com/thread-63334-1-1.html

什么是api接口（前置知识）

让我们看看百度百科的说法

应用程序接口（英语：ApplicationProgrammingInterface，简称：API）
又称为应用编程接口，就是软件系统不同组成部分衔接的约定.由于近年来软件的规模日益庞大，常常需要把复杂的系统划分成小的组成部分，编程接口的设计十分重要。程序设计的实践中，编程接口的设计首先要使软件系统的职责得到合理划分。良好的接口设计可以降低系统各部分的相互依赖，提高组成单元的内聚性，降低组成单元间的耦合程度，从而提高系统的维护性和扩展性。

说人话

1. 接口: 简单来说就是后端封装好的一个函数，又叫接口函数,
         他就是一个由后端编写好的一个函数（也不一定是函数），
         可以用来实现特定的功能,在web前后端层面，
         api接口就是当前端通过特定的路由来访问时候，就可以调用后端的api接口，
         实现对数据的获取或者实现某种功能
2. 路由：简单来说就是你访问的url,打个比方：
         例如https://www.ichunqiu.com/home/
         这是一个网站https://www.ichunqiu.com/ 
         这表示的是他的网站，而/home就表示他对应的路由
如果有过开发经验的师傅应该可以理解
总的来说，接口一般指的是后端的，路由一般指的是前端的，我们访问的路径

2.api接口安全测试（正题）

接口调用方式：

1.HTTP请求：使用HTTP协议向接口发送请求，获取接口响应。

2.WebService：使用SOAP协议或RESTful接口来进行远程服务调用。

3.RPC（RemoteProcedureCall）：通过调用远程服务器提供的接口来实现分布式系统间的通信。

4.WebSocket：使用WebSocket协议进行双向通信，实现实时数据交互。

5.AJAX（AsynchronousJavaScriptand XML）：使用JavaScript在用户访问网页时进行异步请求数据并更新页面。

6.GraphQL:一种数据查询语言，通过GraphQL接口获取所需数据，具有灵活性好、性能高等特点。

7.MessageQueue：使用消息队列技术进行异步处理，实现系统解耦和分布式事务。

8.MQTT（MessageQueuingTelemetryTransport）：一种基于消息的轻量级协议，用于在低带宽和不稳定的网络中进行即时通讯。

注意：同一个网站可以有多种调用接口的方式，接口调用方式不是唯一的

api接口安全测试的核心：

1.任何接口调用方式产生漏洞的原因都是一致的，只是对接口调用的方式不同，
  使用的规则不同，使用的协议不同,导致数据的传递格式不同，但这些都不会影响
  接口漏洞产生的原因——————后端api接口过滤不严格，书写有错误。
   
2.由于漏洞产生的原因都是后端api接口书写不严格，所以面对不同的接口调用发送，其实测试思路都是一样的，按照目标网站的api接口调用方式去构造对应的测试代码，
  也就是按照目标网站数据传递的方式去构造payload去测试。

看完上面的测试核心，可能有的师傅还一知半解，让我用几个例子来让你更深入的理解

案例演示

GET http://api.example.com/widgets?size=largeAccept: application/jsonAuthorization:Basic aGVsbG86d29ybGQ=Content-Type: application/jsonCache-Control: max-age=60{  "widgets"[    {      "name""Widget A""size""large""color""blue"    },    {      "name""Widget B""size""large""color""red"    }  ]}

这时候我们的测试思路应该为：我们就需要在"name" "Widget A"这种地方，以json的格式去构造payload，例如测试sql注入，就可以构造"name" "Widget A ' and 1=1'"等等进行测试。

GET http://api.example.com/widgets?size=largeAccept: application/jsonAuthorization:Basic aGVsbG86d29ybGQ=Content-Type: application/jsonCache-Control: max-age=60xml version="1.0" encoding="UTF-8"<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"<soap:Body><m:methodname xmlns:m="http://www.example.org/"<m:param1>value1</m:param1><m:param2>value2</m:param2></m:methodname></soap:Body></soap:Envelope>

这时候我们的测试思路应该为：我们就需要在<m:param2>value2这种地方，以json的格式去构造payload，例如测试sql注入， 就可以构造<m:param2>value2’and 1= 1等等进行测试

对api接口安全测试的核心的补充

当然如果采用不同的方式调用api接口，虽然本质上漏洞产生的原因不变，但是也会出现不同的测试漏洞点

（1）soap协议是需要wsdl文件（规定格式的作用）才可以进行接口调用的，
    这里就是soap协议特有的测试漏洞点. 因为wsdl文件会包含网站的全部接口，
    如果我们通过数据包发现网站的接口调用形式为soap的话，就可以尝试寻找wsdl文件，
    直接将wsdl文件解析（解析wsdl的方法有很多，suapui，burp suite的wsdler插件 等等），
    就可以得到全部的接口，就可以通过这样就不需要我们在去费工夫的寻找接口，
    就可以通过解析得到的接口直接发包测试，或者通过readyapi直接对wsdl解析后
    测试安全性。

（2）resultful协议，虽然不需要wsdl文件来规定他的格式，
    但是他有用来测试resultful的工具，例如swagger，他同样会包含网站的全部接口，
    如果网站管理人员在使用swagger时候没有对访问的人做出限制,让谁都可以
    自由访问swagger页面，就会导致和soap一样的后果，让攻击者可以直接得到全部的
    接口，直接通过swagger进行接口测试即可
     （可以通过swagger测试的python脚本进行自动化测试）

（3）同时，网站接口调用的方式也决定了某些漏洞会不会产生的原因：例如xxe漏洞，
    如果网站使用的是soap协议进行接口调用,由于他使用的是一种soap协议的xml，
    所以他是有可能产生xxe漏洞的，resultful也是同理,他的参数传递也有可能使用xml，
    所以出现xxe漏洞也是有可能的，但是如果是其他的，可能不会存在xxe漏洞

四.不同接口产生的安全问题

（这里只对三种较为主流的进行分析，其他的师傅可以自行了解，本质上理解我说的那三个核心，面对任何api接口的测试都可以手到擒来）

GET http://api.example.com/widgets?size=largeAccept: application/jsonAuthorization:Basic aGVsbG86d29ybGQ=Content-Type: application/jsonCache-Control: max-age=60id=1//注入代码：id=1’ and 1=1

I.什么样的接口调用为HTTP请求调用：
   HTTP请求调用接口这是最基本的接口调用，也就是完全没有限制，
   有前端自由构造请求的数据，然后后端书写接口函数来处理数据，
   他们数据在传递的时候没有一定的格式，都由前后端人员自己制定

II.产生的安全问题：sql注入，越权等

GET http://api.example.com/widgets?size=largeAccept: application/jsonAuthorization:Basic aGVsbG86d29ybGQ=Content-Type: application/jsonCache-Control: max-age=60xml version="1.0" encoding="UTF-8"<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"<soap:Body><m:methodname xmlns:m="http://www.example.org/"<m:param1>value1</m:param1><m:param2>value2</m:param2></m:methodname></soap:Body></soap:Envelope>

Envelope:用于把xml信息标记为soap
header：包含请求信息Body:包含了请求和相应信息Fault：包含了发生的错误信息
这里重点关注Body，Body处包含了请求和相应信息，当Body内有存在数据可控时，
就有可能存在注入,所以这里的注入代码应该为 
<m:param1>value1’ and 1=1 </m:param1>
<m:param2>value2’ and 1=1</m:param2>
（2）RESTful协议：

GET http://api.example.com/widgets?size=largeAccept: application/jsonAuthorization:Basic aGVsbG86d29ybGQ=Content-Type: application/jsonCache-Control: max-age=60{"widgets":"test" //注入代码"widgets":"test’and 1=1"}

3.GraphQL协议:
什么是GraphQL协议：他和大部分协议都不一样，一般的协议需要多个路由
（前面解释过），但是对于GraphQL协议协议来说，它只需要一个路由，各种
功能的实现都是通过这个路由来进行的，他的实现类似于类，可以将各种对路由
的访问都集成到一个路由上

GET http://api.example.com/widgets?size=largeAccept: application/jsonAuthorization: Basic aGVsbG86d29ybGQ=Content-Type: application/jsonCache-Control: max-age=60{  "query" "query getUser($id: ID!) { user(id: $id) { id name email } }"  "variables" {    "id" 12345  }}-----------------------------------------------------------------------------------------//攻击代码{  "query" "query getUser($id: ID！’and 1=1) { user(id: $id) { id name email } }"  "variables" {    "id" 12345  }}或者{  "query" "query getUser($id: ID!) { user(id: $id’ and 1=1) { id name email } }"  "variables" {    "id" 12345  }}//也就是在括号内进行修改

I. GraphQL协议只有一个接口，他和resultful等有很大的不同
一般有这些路径
/graphql/
/graphql/console/
/graphql.php
/graphiql/
/graphiql.php

II.可能出现的漏洞：信息泄露，sql注入等

3.总结


接口的实现有各种方法，他们适用于不同的场景，但是去理解他们的共同点（只是传入数据的格式不同，注入方式一样），在进行不同接口测试时候只需要做出少量变化即可（不同格式特有的漏洞），学会观察和总结才可以走的更远。

知识星球


原文始发于微信公众号（fkalis）：API接口渗透测试指南 -- 眼花缭乱的接口，始终如一的本质