官网：http://securitytech.cc/
Bug Bounty Hunting: JWT 漏洞深度解析（现场逐步实践）
我知道我已经好几个月没上传文章了。我知道我还没完成之前提到的 IDOR 系列，但好消息是我回来了——而且带着一些宝贵的经验和知识回来了，这肯定会对我们大家的 Bug Bounty 旅程有所帮助。
今天我们将以一种简单且实用的方式，在一个真实目标上深入探讨这个最热门、最受关注、也最令人困惑的漏洞。没错，你猜对了——就是关于 JWT (JSON Web Token)。
这是目前公司和开发者们在 Web 应用程序中使用的最新技术，你现在会发现 JWT 随处可见——比如“某某人通过 JWT 令牌漏洞获得了赏金”或者“JWT 令牌弱点”。它很流行，而且很容易理解。
所以我在这里，在这篇文章中，我将通过一个现场实战例子来解释如何找到和利用这个漏洞。请记住，JWT 漏洞有很多类型。今天我们将介绍其中一种，未来会有更多。我不是开玩笑——接下来几天真的会持续发布文章，一个完整的 JWT 系列将涵盖所有 JWT 漏洞。不需要任何课程，我在这里，你准备好了，这就足够了。明白了吗？
那么……你……你……准备好了吗？
好了，回到正题——JWT 到底是什么？它是一种主要用于身份验证的令牌。你可能遇到过 JWT，但不知道如何处理它，或者根本不知道这到底是个什么鬼东西。
JWT 主要用于身份验证 (Authentication) 和授权 (Authorization)。我假设你已经了解它们之间的区别，所以让我们从第一步开始——JWT 长什么样？看……
按 Enter 或点击查看完整图片
当然，这并不意味着 JWT 令牌只能存在于 Authorization: Bearer 头部。它们可以是任何形式——比如在 cookies 中，或者作为简单的 jwt 参数。这完全取决于开发者，但大多数情况下它们都在 Authorization 头部。
JWT 令牌是 Base64 编码的字符串，由三部分组成：头部 (header)、载荷 (payload) 和签名 (signature)，它们之间用一个句点 "." 连接。每个部分都有其各自的漏洞，但本文我们只关注头部和载荷。关于基于签名的漏洞，我们会在未来的文章中讨论。
按 Enter 或点击查看完整图片
现在，我需要你全身心投入地阅读这部分——这是最关键的部分。
你可以看到有三部分：头部、载荷和签名。在头部，你可以注意到两件事——一个是 算法 (algorithm)，另一个是 类型 (type)。算法是指用于创建此令牌的算法，类型则是令牌的类型，它通常是 JWT。算法可以不同——可以是 SHA-256、RSA 或其他任何算法。
然后是载荷 (payload) 部分。这是最重要的一块。在载荷部分，会包含主要数据——例如，用户名、用户 ID、角色——任何用于验证用户的信息都会在这里。我们主要通过操纵载荷部分来寻找漏洞。
现在看下面的图片。在下面的图片中，你可以看到某个应用程序的载荷部分，并且你可以清楚地看到参数 username 和 admin。
你可能会想：“哦，让我把用户名改成其他用户，然后重新生成 JWT 令牌，或者直接把 admin 的值从 0 改成 1，然后再次提交——我们就能获得访问权限了。”
如果你这么想，那你就太天真了——事情没那么简单。
让我们通过流程来理解。
JWT 有三部分 → 头部.载荷.签名
在头部，我们有类似这样的内容：
{
"alg": "HS256",
"typ": "JWT"
}
