业务接口调用模块

1，接口调用重放测试

测试方法：接口调用重放测试可以理解成重放测试，接口也就是数据请求，功能很多，例如发布文章，发布评论，下订单，也可以理解成只要请求有新的数据生成，能重复请求并成功，都可以算请求重放，也就是接口重放测试。

修复方法：对生成订单缓解可以使用验证码，防止生成数据的业务被恶意调用。或是每一个请求有唯一的一个 token，请求提交后，token 失效这样。也可以参考微信的做法，在参数中添加 timestamp 和 nonce，并对其进行签名加密。

2，接口调用遍历测试

测试方法：例如有一个功能，是浏览商品的历史记录。把其用户的浏览历史记录 url 发送到 intruder，遍历其用户的 id，看返回 response 信息中是否有正常返回的，且是其他用户的，则证明存在接口遍历问题。

修复方法：在 session 中存储当前用户的凭证或者 id，只有传入凭证或者 id 参数值与 session 中的一致再返回数据内容。

3，接口调用参数篡改测试

测试方法：例如在一些短信验证码、邮件验证码等功能业务中，比如修改其他用户密码，发送后，再次点击重新发送，拦截其请求，修改为自己的账号，如果自己收到了验证码，则存在此问题。

修复方法：会话 session 中存储重要的凭证，在忘记密码、重新发送验证码等业务中，从 session 获取用户凭证而不是从客户请求的参数中获取。从客户端处获取手机号、邮箱等账号信息，要与 session 中的凭证进行对比，验证通过后才允许进行业务操作。

4，接口未授权访问

测试方法：只要是登录后才可以返回相关信息的接口，在未登录状态下也可以返回的，就是未授权访问。在一般的网站测试中，可以 http history 中选择网站的根目录地址，然后右键 spider from here 进行爬去相关的 url，然后在 target 栏下的 site map 中利用 mime type 进行筛选，主要关注一下 json、script、xml 等这些类型，然后把 url 贴到浏览器中看是否能访问来验证。

经验之谈：或者在测试的时候，相关数据包发送到 repeater 后，删除 cookie 进行 go，如果成功返回信息，则是存在此问题的。但把 url 贴到浏览器中时会跳到登录页，这时为了验证可以使用 firefox 的 backfar 插件再试。

修复方法：利用 token 校验的方式，在 url 中添加一个 token 参数，只有 token 验证通过才返回接口数据且 token 使用一次后失效。在接口被调用时，后端对会话状态进行验证，如果已经登录，便返回接口数据，如果未登录，则返回自定义的错误信息。

5，callback 自定义测试

测试方法：因为同源策略，很多网站都会使用 JSONP，而 JSONP 一般会使用 callback 回掉函数，如果这个函数没有做相关的措施，可以随意传入 js 代码并执行则存在此问题。

可以使用 burp 的爬虫功能，先爬去目标网站，然后筛选一下包含有 callback 关键词的 url，看 response 返回的 mime 类型，如果是 text/html 的，则可以输入 js 代码确认下是否存在这个问题。

修复方法：首先可以定义下 content-type 为 json 格式，content=application/json。其次建立 callback 函数白名单，如果传入的函数不是白名单内的，则组织并转到异常页。最后可以对 callback 参数进行 html 实体编码来过滤掉一些特殊字符。

6，webservice 测试

这个测试我目前没有具体的实操过，之前有一次是接口测试就是 webservice 的。回头有测试用例的话，再单独记录一篇博客。