因为搜不到该靶机的解题过程记录,有些wp需要花钱,所以我自己做了一个我自己解题过程的记录方便我自己复盘。每关的答案都统一放到最后了。
初级篇:
level 1:基础爆破——学习使用Intruder。
解题:测试出已存在的用户名,如admin,通过Intruder爆破获取账户密码,如123456789。
level 2:响应过滤——学习使用过滤器。
解题:过滤器有两种方法使用,第一种在攻击前进行过滤,第二种在攻击后进行过滤。
攻击前过滤:通过settings中的Grep-Match进行参数配置,并勾选Flag responses matching these expressions,对结果进行关键词匹配
攻击后过滤:在Results选项卡中,点击View filter:Matching expression success,在Filter by search term中进行关键词查找。
level 3:用户名枚举——用户名爆破。
解题:通过Intruder对用户名进行爆破,并对username error进行筛选快速获取正确用户名,使用正确的用户名对密码进行爆破获取
level 4:高级过滤——用户名爆破+响应长度一致。
解题:先获取已存在的用户名,在获取密码,流程与level 3是相同的,我的靶机是在获取用户名是返回结果长度一致,需要添加匹配规则,在获取密码时没有出现返回结果长度一致现象。
中级篇:
level 5:POST攻击。
解题:首先了解GET与POST是什么,GET是把数据放在URL中,用于向服务器要数据;POST是把数据放在请求体中,用于向服务器提交数据。获取结果的流程与之前一致,我这里使用repeater让大家更直观的感受。
| 对比维度 | GET | POST |
|---|---|---|
| 数据位置 | URL 尾部(请求行)。 例如: GET /login?user=admin | HTTP 请求体(Body)。 例如: user=admin在空行下方的区域。 |
| 长度限制方 | 客户端/浏览器限制(RFC 规范无限制,但浏览器和服务器通常限制 2KB~8KB)。 | 服务器端限制(通常由php.ini或nginx的client_max_body_size决定,默认可达 2GB)。 |
| 编码类型 (Content-Type) | 仅支持application/x-www-form-urlencoded(只能传 ASCII 文本,特殊字符必须 URL 编码,如空格变%20)。 | 支持多种格式: 1. x-www-form-urlencoded(表单)2. multipart/form-data(文件上传)3. application/json(API 接口)4. text/xml等。 |
| TCP 数据包发送机制(经典) | 一个包发送。 请求头和请求体(空)在一个 TCP 数据包中一次性发出。 | 可能分两个包发送(HTTP/1.1 经典行为)。 先发 Header(服务器响应 100 Continue),再发 Body。这使得 POST 在小数据时略慢,但大数据时更灵活。 |
| 浏览器后退/刷新行为 | 无害(幂等)。 点击刷新或后退,浏览器不会弹窗警告,直接重新加载页面。 | 有副作用(非幂等)。 点击刷新或后退,浏览器会弹窗提示“确认重新提交表单”,防止重复下单或重复发帖。 |
| 浏览器历史记录 | 完整保存。 URL 中的参数(如 ?password=123)会被明文保存在浏览器历史文件夹中。 | 仅保存 URL 路径。 请求体(Body)里的敏感数据不会被保存在浏览器历史中。 |
| 服务器日志记录 | 完全记录。 参数会原封不动地出现在 Nginx/Apache 的 access.log日志文件中,管理员可直接看到密码。 | 不记录 Body。 绝大多数 Web 服务器的默认访问日志只记录 URL 路径,不记录 POST 的 Body 内容(除非开启 Debug 级别),相对隐蔽。 |
| 缓存机制 (Cache) | 强缓存。 浏览器和 CDN 会默认缓存 GET 请求的静态结果,用于加速。 | 禁止缓存。 除非特殊配置,浏览器和代理服务器默认不会缓存 POST 请求的响应。 |
| 书签收藏 | 可以。 可以把带参数的搜索页存为书签。 | 不可以。 无法将“提交订单”或“登录”这个过程存为书签。 |
| 幂等性 (Idempotent) | 是(幂等)。 发送 1 次和发送 10 次的效果完全相同,服务器状态不变(仅查询)。 | 否(非幂等)。 发送 1 次创建 1 条数据,发送 10 次创建 10 条数据(会产生副作用)。 |
| 安全性(明文场景) | 极不安全。 参数暴露在地址栏、浏览器标题栏、Referer 头(来源页)中。 | 较安全(但不绝对)。 数据在 Body 中,不显示在地址栏,但若未使用HTTPS,抓包工具(如 Wireshark)依然能看到明文。 |
| 主要应用场景 | 获取数据。 搜索引擎查询、查看文章详情、翻页、获取静态资源(图片/CSS/JS)。 | 提交/修改数据。 用户登录、注册账号、发布帖子、上传文件、在线支付。 |
level 6:中文响应。
解题:response结果返回的是中文,由于pretty中无法识别非英文响应,所以可以通过响应长度进行快速查找。
level 7:重定向处理。
解题:对密码进行爆破处理,错误密码的状态码都为200,3xx则极大概率为正确密码。
重定向:本质是告诉浏览器要找的东西不在这里,去另一个URL中查找。
重定向完整的交互流程:客户端(浏览器)发送请求——>服务器返回响应,状态码为3xx,并在响应头中包含Location: URL.example,响应体通常为空或者一段提示文字——>浏览器收到后会立即自动发起第二次请求去访问Location指定的新地址——>浏览器显示第二次请求返回的最终页面内容。在bp中一次重定向会产生两条或多条HTTP请求记录(原始请求+跳转后的请求)。
| 状态码 | 名称 | 是否永久 | 是否允许改变请求方法(GET/POST) | 典型使用场景 |
|---|---|---|---|---|
| 301 | Moved Permanently(永久移动) | 永久 | 允许改变(POST 可能变成 GET) | 网站更换域名,旧网址全部指向新域名。浏览器会永久缓存该跳转,下次直接访问新地址。 |
| 302 | Found(临时移动) | 临时 | 允许改变(POST 可能变成 GET) | 最常用!登录成功后跳转到首页、支付完成后跳转到订单页。浏览器不会缓存,每次都会先访问旧地址再跳转。 |
| 303 | See Other(查看其他) | 临时 | 强制改为 GET | 专门用于POST 请求后,防止刷新页面导致重复提交(PRG 模式)。例如:提交表单后,服务器返回 303,强制浏览器用 GET 去访问结果页。 |
| 307 | Temporary Redirect(临时重定向) | 临时 | 严格保持原方法(POST 仍是 POST) | 当需要临时跳转,但又不允许丢失 POST 数据时使用(如支付扣款接口)。规范要求浏览器必须沿用原请求方法。 |
| 308 | Permanent Redirect(永久重定向) | 永久 | 严格保持原方法(POST 仍是 POST) | 301 的升级版,专用于需要保持请求方法不变的永久迁移。 |
level 8:Base64编码——客户端编码绕过。
解题:抓包后会发现我们测试的密码被某种方式加密,将其交给ai分析是哪种加密,这题使用的是base64加密,在payload processing中add Enabled Base64-encode规则,并勾选启用该规则,然后进行密码爆破,由于响应体是非英文,可以根据响应体长度快速获取正确密码,并对其进行base64解码。
level 9:md5加密。
解题:和level 8的流程是一致的,只需要将base64的规则改成添加 add Hash MD5即可,由于MD5是一种单向哈希算法,所以大家需要在获取正确结果后返回文件中根据Results选项卡中对应的行数进行结果查询。
高级篇:
bp中Intruder的四种攻击模式:
1.Sniper attack(狙击手模式):使用一个有效载荷集,将每个有效载荷依次插入到每一个标记位置上。
解析:假设你有一个字典,并且有多个标记位,它会将字典依次替换第一个标记点,其他标记位不变,当第一个标记点遍历完字典后会改回到标记时的值,字典开始依次替换第二个标记点,以此类推,直到最后一个标记位遍历完字典。
请求总数 = 字典大小 * 标记位置数。
2.Battering ram attack(攻城锤模式):使用一个有效载荷集,将同一个有效载荷同时填入到所有标记位置上。
解析:假设你有一个字典,它会将字典的内容将所有标记点同时替换,如第一个字典为1,第一次请求攻击时所有的标记位会全部变成1。
请求总数 = 字典大小
3.Pitchfork attack(音叉模式):为每一个标记位置分配一个独立的有效载荷集,Intruder会并行的遍历每个集合。
解析:假设你有两个标记点,那你就需要准备两个字典(字典A和字典B),攻击时,第一个请求就会取字典A[0]和字典B[0],第二个请求就会取字典A[1]和字典B[1],然后一一对应知道遍历结束。需要注意的是,假设字典大小不一致,短的字典会用空值进行补全,确保所有字典大小一致。
请求总数 = 所有字典中最大的那个大小
4.Cluster bomb attack(集束炸弹):为每一个标记位置分配一个独立的有效载荷集。Intruder会遍历这些集合之间所有可能的组合。
解析:假设你有两个标记位,字典A有三个词,字典B有四个词。攻击时会生成3 * 4 = 12种组合,将这些组合全部遍历完才会结束。
请求总数 = 所有字典大小的乘积
我整理的可能比较笼统,表达可能不是很好,最好的理解方式就是大家可以自己动手尝试一下,很快就能理解一下。
level 10:双参数攻击。
解题:使用Pitchfork attack模式,对密码的两个参数添加标记,并为这两个标记位加载同一个字典,并对第二个标记位的字典添加md5加密规则。
level 11:前缀处理。
解题:我使用的是标记整个参数并添加前缀规则,大家也可以标记动态字符位置,我刚开始攻击时没有进行筛选,发现响应体长度都是一致的,所以我在第二遍时增加了error关键词筛选,才获取到答案。
面对前缀的处理方法:服务器要求传递的密码必须是前缀+字典、参数名有动态前缀或想要保留部分静态字符、前缀+双参数+加密。
解决方法:在Intruder的payload Processing区域,添加Add prefix规则,如添加该关卡中的godxing%40,如果还需要添加别的规则,需确保规则的顺序正确,如前缀包含特殊字符,需添加URL-encode规则,如果不确定是不是包含特殊字符也可以添加URL-encode规则。
level12:时间戳。
时间戳处理方法:
由于ai推荐的解决时间戳的两个插件扩展(Magic Variables、Timestamp Injector)比较古老不适配我现在使用的25.10.3专业版,所以这几天我自己借助ai制作和调试了一个Python插件用于解决常见的时间戳。插件有需要的可以私聊。
解题:根据burp中的数据流可以看到POST参数加入了时间戳的识别,并且时间戳的时间是服务器时间,而不是本地时间,根据我摸索的时间戳边界大概为2s左右就行,时间戳超出2s后就会出现部分302状态码,2s边界也有概率出现302状态码响应体,所以大家在尝试时需要注意筛选一下Status code。
level 13:JSON格式。
解题:获取数据流,可以看到请求体中的数据是JSON格式,JSON是一种键值对,服务器会对键值对值提取匹配数据库的数据,我们直接对密码进行爆破即可。
level14:Base64 + JSON。
解题:从获取的信息可以看到请求体被加密,交给ai获取加密模式,该关卡使用的是Base64加密,并使用JSON格式传递数据,通过加密的方式就不方便按照之前那样的对密码值进行爆破,我们需要构造整个请求体进行加密爆破,构造请求体的方式就是把我们测试的请求体使用前缀规则和后缀规则将被爆破的参数包裹起来,这样我们不管写什么值都是可以被加密传递的。注意有些时候burp会默认勾选URL-encode these characters,大家可以根据抓包的数据中是否进行编码决定勾不勾选。
level15:JSON + MD5。
解题:根据题意直接按照levek14的解题方法解决。
level16:复杂编码。
解题:根据题目提醒直线减低了题目的难度,按照正常操作再额外加一层MD5加密规则即可。
level17:频率限制。
解题:
level1:答案:admin ; 123456789。
level2:答案:admin ; password。
level3:答案:test ; 123456789。
level4:答案:test ; 123456789。
level5:答案:admin ; 123456789。
level6:答案:admin ; 777777。
level7:答案:admin ; admin@123。
level8:答案:admin ;LOVE5201314。
level9:答案: admin ; 11111111。
level10:答案:admin ; abc123456。
level11:答案:admin ; 123456。
level12:答案:admin ; 789632145。
level13:答案:admin ; 1314521521。
level14:答案:admin ; 1234568。
level15:答案:admin ; qaz123qaz。
level16:答案:admin ; qq520520。