版权声明：本文为CSDN博主「发哥微课堂」的原创文章，遵循CC 4.0 by-sa版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/fageweiketang/article/details/81668329
0x00：前言
上周做渗透，有一个 sql 注入，负责安全审核的人给开发说你们的程序既然还有 sql 注入，我一年也看不见几个。这句话让我又再次深刻的认识到，渗透测试常规的一些注入跨站漏洞不如以前那么盛了，有点经验的开发写东西都会去考虑到了，再加上修复方法也在逐渐的完善，逻辑类的东西也应该并重的去测。
0x01：分类
我把逻辑类的问题大概总结了一下，大概可以分为十个模块，分别是登录认证模块测试、业务办理模块测试、业务授权访问模块测试、输入 / 输出模块测试、回退模块测试、验证码机制测试、业务数据安全测试、业务流程乱序测试、密码找回模块测试、业务接口调用模块测试。
这次记录的是第十个也就是最后一个模块业务接口调用模块测试。
0x02：业务接口调用模块
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 实体编码来过滤掉一些特殊字符。
1216
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
