关于接口测试的小总结分享

本文由掌控安全学院 -

  Track

 投稿

来Track安全社区投稿~  

千元稿费！还有保底奖励~（https://bbs.zkaq.cn）

就我自己的理解来说，接口其实就可以理解为功能点，例如你有一个/print接口，它的功能是返回一个字符串hello world，请求方法是GET，拼接到URL上访问http://xxx.com/print ，返回给你一个hello world这个字符串数据，这个就是一个名字叫做print返回hello world字符串的接口。（实际上接口的概念与之大有差异，这里仅为方便理解而做此解释。）

比如/web/ ,/web/auth/，可以从历史包中获取接口信息，然后再将获取到的接口信息通过删除、拼接操作来fuzz接口，从而访问到正确的接口：

例如接口/app/selcourse/queryCourseInfo ,拼接访问/web/app/selcourse/queryCourseInfo提示404，/web/edu/app/selcourse/queryCourseInfo 则有内容回显。

可以将请求方法换成OPTIONS，来看该接口支持哪些方法：

也可以各种请求方法挨个尝试，观察是否有报错或者数据返回：例如Request method ‘GET’ not supported，或者响应500等等

此处接口为Access_token鉴权：

删除后：500

如果删除后回显内容正常，则此处存在未授权。

如图，带参数返回数据正常：

不带参数则返回错误信息或者异常或无数据返回，这些情况都有可能，因此需要多做尝试。

前面说到接口访问需要参数，后面说到可尝试删除操作，其实这两点并不冲突，将参数删除后可能会返回所有数据内容。

参数置空操作则应该是数据库模糊查询的利用，模糊查询后返回所有数据内容：

如图，deptid为213时，只返回两条内容

deptid置空或者直接传入{}后，返回数据内容大于两条

传入空值，例如{}，{[]}，[]

可以通过接口以接口名字为基础进行猜测处理：

例如接口：/web/authmanage/api/common/findUserByDeptIdA，根据英文释义进行猜测，By是通过，findUser是查询用户，ByDetpIdA 通过DetpIdA，则这个接口的功能是：通过DetpIdA来查询用户相关的内容。detp一般是“部门”，这个是个人经验，通过部门IDA来查询用户相关的内容，猜测之后，就可以进行尝试，此处还需注意，传参类型，我是在URL上直接 ?name=1拼接参数呢，还是放到POST中，以JSON或者表单格式如name=1&pass=2这种进行传参呢？还是那两个字：尝试。

例如：

GET /web/edu/stuManager/stuByMasterAndNumber/230xxxxxx7 HTTP/2
该接口的参数不好猜测，一方面，参数是直接拼接到URL上，这个之后也可以进行尝试，那么按照这个规则，stu学生，by通过，master导师，and逻辑条件，number数字这里则猜测是学号，或者导师的名字或者导师的工号

/web/edu/stuManager/stuByMasterAndNumber/学号

/web/edu/stuManager/stuByMasterAndNumber/工号

/web/edu/stuManager/stuByMasterAndNumber/url_encode(导师名字)

或者基于对方是什么系统进行猜测：

如对方是学生管理系统，那参数可能是stuNumber, stuno,studentNumber,number,stuName等等等等。

字典fuzz:

这个没什么好说的，如果你有一个强大的参数字典，可尝试直接爆破之。

其他接口收集参数：

如果你在一个接口上没有得到对应的参数，而此时系统还有其他功能点，可以点一点其他功能点，其他功能点也会发起请求请求数据，此时可以从其他接口处采集来参数，然后用采集来的参数名去fuzz，感觉这样准确度会高一些。

一般访问一个接口的顺序应该是：

1，得到正确的路径

2，获取正确的请求方式

3，区分是否需要权限才能访问

4，使用正确的传参。

原文始发于微信公众号（掌控安全EDU）：关于接口测试的小总结分享