反CSRF爆破的三种姿势

2022-06-09

字数统计: 707字 | 阅读时长≈ 2分

暂无简介

姿势1:CSRF Token Tracker

CSRF Token Tracker是个插件,可以在BApp Store下载安装

这种方式可以说是最简单的,但是不适用姿势2和姿势3中的案例
现有一个请求参数是user_token

只需要在插件中添加

注意这里有个坑(搞了好久)
比如你想在repeater模块测试一下重新发送请求会不会修改密码

发现返回的结果仍然是302
这里是需要有一个有效的,没有使用过的user_token去请求的!
然后再去重放请求包就都会自动更新token了
总结一句就是你第一次用有效的token重放请求包就永远有效(自动更新token了)
你第一次用无效的token重放请求包就永远无效

姿势2:定义宏

在这个案例中使用CSRF Token Tracker无法成功自动更新token

开始定义宏

一路OK回到这里

不懂就选择1,在所有请求前都运行宏

来到repeater模块重新发送请求就不会说非法的csrftoken

来看日志发生了什么

我们使用repeater重放了登录的请求,也就是图中第71个请求
宏帮我们自动进行了了第70个请求获取了新的token让第71个带着新的token去登录

姿势3:宏+Extractor

在这个案例中前两种姿势均无效
下载安装插件

先看下两个请求包
第一个请求包就是获取token的

第二个就是带着token去访问

看过这两个请求包应该就明白了
这次token是在请求头中
而定义宏的时候会让你选择更新token的地方
这个地方却没有更新请求头的功能
所以姿势2在这里就失效了

首先定义宏获取token
这个宏只需要要确保在请求2之前会执行请求1
相比于姿势2的步骤简单一点

到这里宏就配置好了
在repeater重放请求2然后再logger+=里面查看
确保每次都会在请求2前自动执行请求1就是正常的

然后配置插件Extractor
把两个请求包都发送到Extractor

此时回到repeater模块重放发现token就有效了

再次回到logger++看发生了什么
看到第87个请求获取的token值为407667d008b147199d174681a655aea0

第88个请求包的accessToken值也是407667d008b147199d174681a655aea0

总结一下姿势3的思路
宏负责在请求2前发送请求1
Extractor插件负责匹配和替换token

本文作者： VVeaker
本文来源： 先知社区
原文链接： https://xz.aliyun.com/t/11419
版权声明： 除特别声明外，本文各项权利归原文作者和发表平台所有。转载请注明出处！

缺失模块。
1、请确保node版本大于6.2
2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
npm i hexo-generator-json-content --save

3、在根目录_config.yml里添加配置：

  jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

俗话说“好记性不如烂笔头”，各个安全社区各自为战，当我们想要搜索某一方面的文章的时候总是得在各个平台之间来回横跳，于是乎，一个平台文章聚合搜索的想法诞生了。
然后正好我想有一个自己的博客，于是乎两者融合在了一起。
下面简单介绍各个导航的区别：
个人文章：本人的笔记、复现、总结等或者本人参与的共同创作。
收集文章：手工从公众号收集保存的文章，更新频率看本人喜好所以比较慢。
聚合文章：从各大平台收集整理，由工具实现，每天更新。
很惭愧，只做了一点微小的工作。