平时使用burp进行简单的测试,遇到各种各样的问题,使用各种各样的方法,我们可以抓包、改包、重放、爆破,同时有很多BApp Store有很多开源的扩展工具,今天我想要分享的是巧用一个名为“Extractor”的扩展插件和Burpsuite Marco的结合用法,获取他在你解决某些场景下的anti-token的问题时候可以有所帮助。
用于在HTTP请求和响应中进行提取和重用数据的Burp扩展。
Extractor使用方法就是从一个请求的相应中提取数据,再另一个http请求中重用,诸如:CSRF token、 timestamps(时间戳)、Auth Bearer token等某些场景中,通过使用正则提取数据,并且在burp发送指定请求时将提取出的值替换掉请求中的正则匹配到的值。
burpsuite自带的功能,宏这个功能应该都不陌生,之前已经有相关文章介绍Marco,如:“Burpsuite中宏的使用”一文。文章中详细的介绍了一般宏的录制以及使用,本文的宏只是涉及到最基础的用法,重点是在实际使用中的思路。
之前在测试某个接口的时候,发现有这样一个请求
请求的返回中包含了如下信息:
这里传入的参数是一个规律递增的ID值,通过重放的方式,可以批量获取大量个人敏感的身份信息。问题不算太大,但绝不是可以忽略掉的问题。
修复方案是建议是防止重放攻击,并且模糊处理返回的敏感信息。几日后,收到复测的安排,遂进行复测。
修复后的接口请求如下,其添加了一个Token_Id值,用来防止重放攻击?
重放之后提示“系统异常请稍后重试”,通过修改cookie参数中的值、refrer参数等方法,均无法绕过token_Id的检验。
重新查看proxy中的请求记录,发现在每次请求之前,会先发送一个请求,该请求返回包中,只有一个参数,即tokenId。如下所示:
到此,脑子里首先想到的就是刚刚提到的“Burpsuite中宏的使用”,于是仔细阅读了该篇文章的用法,并仔细的对本地复测的情况录制了宏,遗憾的是最终并未能够成功,可能原因有二三:
自己配置/使用不正确(自认为概率很小,因为请教了不同的大佬,并进行了多次尝试);
文章中示例使用DVWA搭建,具体到请求和场景和真实情况有所出入;
自己写了等效的脚本,一个函数请求并获取tokenId,另一个替换tokenId后发送请求获取信息,均已失败告终,看来,此处的问题真的是修复了!!!
下面是我在Repeater中连续点击多次之后的返回。
之后可以Intruder可以进行爆破咯~,结果就是问题真的修复了,虽然解决了tokenId的问题,但是修复再其他位置也做了校验,所以突破了tokenId的限制,但是无法重放攻击做信息搜集之类的敏感操作。OK,到一段落。
整个过程中的逻辑流程,帮助理解整个绕过token校验的流程: