那些年，接口测试踩过的坑~

lsekfe

前言
　　最近在做一个接口测试的项目，虽然难度不大，但是 路漫漫心累~
　　在乙方做安全服务的，平常的Web、App的渗透测试可以说是家常便饭了，但是好像很少会碰到接口测试的，但说不定哪天就会碰到了2333~，所以这里分享一下做接口测试的简单步骤和测试过程中踩过的坑吧，希望老表们在遇到同类问题时可以一把梭，不要再一步一卡，步步踩坑了。
　　什么是接口测试
　　首先在你拿到一个接口测试项目的时候，只有一个黑人问号脸肯定是不行的。
　　所以我们先来看一下，什么是接口测试？
　　百度百科解释一波：接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
　　Are you kidding me？我们测试的重点当然是安全，所以个人理解，接口安全测试就是检测外部系统与系统之间以及内部各个子系统之间交互点中可能发生的安全问题。如：
　　· 检测数据交换过程中是否可以在数据输入过程中向系统之中插入一些脏数据，在数据输出的时候得以达到攻击者想要的结果，常见漏洞有：SQL注入、XSS跨站脚本漏洞、溢出漏洞、文件上传漏洞等。
　　· 检测重要数据如身份证号、银行卡号、电话号码、邮箱等在传递和存储的过程中是否进行了加密，敏感数据在前端输出时，若非业务需求，还需要进行脱敏处理。常见漏洞有：账号密码明文传输、用户个人信息明文泄露等。
　　· 检测系统中各子系统及各功能的逻辑依赖关系是否存在安全问题，比如打乱具有前后顺序的业务是否依然能达成原有效果、重放某一业务的数据包是否能多次执行该业务功能、遍历数据包中的某些有规律的字段是否能得到更多信息，常见漏洞有：密码重置漏洞、批量提交订单漏洞、越权漏洞、未授权访问等。
　　前期准备
　　实际上，接口安全测试与我们常见的Web安全测试、App安全测试大同小异，所以对于有web和app测试经验的工程师来说，测试过程并不会有太大难度，前提是前期的准备足够充足。
　　接口测试的前期准备主要是测试环境、测试文档和测试工具的准备。首先是测试环境，通常程序员们在开发这些接口的时候，需要进行一系列的功能性测试，所以也会有相应的测试系统，我们需要的就是这个测试系统的URL和测试Demo，同时需要保证我们的网络环境能够访问到这个URL（因为通常测试系统都部署在内网系统，由于内网的一些网络限制，如果不事先准备问清楚，很容易一脸懵逼）。对于测试Demo，要求不高，只要能够让我们可以正常的发送报文，得到正常响应即可，但是有些特殊的接口在传输过程中可能还涉及到加解密的步骤，最好在Demo中也有响应的功能。比如下图的测试Demo，不需要有多好看的UI，能用就行：

　　当测试环境准备好了以后，我们还需要开发提供接口文档，接口文档中需要包含的内容有各功能接口的功能描述、应用场景、请求方、应答方以及报文样例等，接口文档的作用是为了让我们能够清楚每个接口的功能以及它的应用场景，只有了解了这些接口具体是做什么的，我们才能够更好的分析出在这个接口被调用的过程中可能发生的安全问题，然后根据报文样例构造请求，进行我们的常规测试，不过这里需要提一下的是，报文样例中的测试数据一定要是可以用的！！！不然心累肯定是在所难免的。下图是之前乌云上某大佬挖洞过程中挖到接口文档，借图参考：

　　最后是测试工具的准备，常见的接口测试工具有SOAP UI、POSTMAN、BurpSuite等，工具的选择主要还是要看接口使用的协议是什么，比如使用soap协议的接口我们就可以使用SOAP UI进行测试，使用SOCKET协议的接口我们需要使用TCP助手等能发送socket请求的工具，而使用HTTP协议的接口，能用的工具就更多了，对于工具的选择当然是怎么顺手怎么选。
　　接口测试的步骤肯定是因人而异的，大佬们的骚姿势更是层出不穷~此处仅以简单的HTTP接口测试为例，供和我一样的菜鸟们参考使用。
　　假设我们拿到一个基于HTTP协议的接口，没有测试Demo，能用的东西只有接口文档（纯属虚构，仅作讲解）如下：
　　接口描述：
　　序号项目说明：
　　1.接口名称余额查询
　　2.功能描述查询余额
　　3.应用场景目前应用于xxx的余额查询
　　4.请求方XX用户
　　5.应答方xxx系统输入接口
　　序号中文名称英文名称类型长度必填备注：
　　1.客户IDCUST_IDINT10Y
　　2.产品类别PRD_TYPEString10Y
　　3.产品代码PRD_CODEString10Y公有字段
　　4.支付密码PASSWORDString10Y
　　输出接口：
　　序号中文名称英文名称类型长度必须备注：
　　1.客户IDCUST_IDINT10Y
　　2.产品类别PRD_TYPEString10Y
　　3.产品代码PRD_CODEString10Y公有字段
　　4.客户姓名NAMEString10N
　　5.余额BALANCEString10N
　　输入报文样例：

{ 　　NAME：“xiaoming”， 　　AGE：“18” 　　}

　　看到这样的一段接口文档，因为我们知道它是基于HTTP协议进行数据传输的，所以我们可以通过POSTMAN来发送请求报文，从接口文档的描述中可以知道这是一个查询余额的接口，请求报文中必须要填的字段有：CUST_ID、PRD_TYPE、PRD_CODE、PASSWORD，其中PRD_CODE是一个公共字段，因此我们可以构造如下请求报文：

{ 　　CUST_ID："anquanzushiye"， 　　PRD_TYPE："yuebaobao", 　　PRD_CODE:"666", 　　PASSWORD:"123456", 　　}

　　将上面的这段报文复制到POSTMAN中如图：

　　点击Send后，在POSTMAN中就能看到返回的响应报文如图：

　　我们通过构造的报文成功用这个接口查到“安全祖师爷”的余额。到这里我们已经能够正常的使用这个接口进行余额查询了。
　　通过IE浏览器做了系统代理后，就可以使用BurpSuite抓包如图：

　　经验总结
　　那些年踩过的坑，表哥们别再踩了~
　　最后写一下我在做接口测试的时候踩的坑和总结的经验吧，希望对还没有进行过接口测试的表哥们有所帮助。
　　· 首先最好是能够拿到开发在做功能性测试的时候使用的测试Demo，这样后期会省下大量时间，否则需要自己去摸清楚他的接口调用原理，再去写测试Demo会花去大量的项目时间。
　　· 接口文档和报文样例是一定要有的，而且是越详细越好，否则自己探索报文格式，构造报文或者去了解接口功能和应用场景都需要花费大把的时间，尤其是我们在进行逻辑关系的安全测试时，很多情况是必须要结合业务的应用场景来判断是否存在安全问题。
　　· 拿到的接口文档一定要是最新的，需要与开发一再确认，因为前期项目准备的时候，开发提供的接口文档可能已经是几年前的了，这样你在测试过程中，运气好点的可能碰到测试数据过期了，运气不好的可能会碰到，报文格式正确，请求怎么构造都无法请求成功，然后最后得知该接口是几年前的，如今已经删除，不再使用。
　　· 提前与开发沟通好，尽量保障测试样例里的数据都提前埋好，保障测试数据的可用性，不然这个在后面的测试中可能是测试进度的最大拦路虎，比如一个查询接口，接口文档中给出的数据根本无法查询到任何信息，无任何回显，这样你就很难测试SQL注入、XSS漏洞等问题。如果条件允许测试样例中所有数据都最好是开发新埋的数据，并且由开发将所有文档中的接口都调通一遍，因为开发对系统给的熟悉程度肯定远胜于刚拿到接口文档的我们。
　　· 接口的测试顺序很重要，很多接口之间会有依赖关系，可能要按一定顺序去测试，所以需要搞清楚系统的功能逻辑。比如要测试一个账户的余额查询接口，首先要通过创建账户接口创建一个用户然后才能去查询。
　　· 报文结构一定要吃透、各字段含义要注意记忆，这样对于测试的时候需要修改报文中的哪个字段就更清楚了，测试的时候也会更加的得心应手。
　　· 所测试接口的功能可能与其他系统的接口会有交互，这时候就需要及时地去跟开发沟通并索要相应系统接口的接口文档。比如一个申请接口，发送请求后可能需要其他系统的审批接口进行审批，这时候就需要审批接口的接口文档了。
　　· 看到文档的右下角乌云的水印，感触颇多，在的时候没什么感觉，甚至反感，因为提交漏洞因为各种原因给几十元RMB，当时戏称打发要饭的，离开后却再也没有一个社区的更新内容及氛围能及乌云一半。