JWTの「alg: none」攻撃とは - 仕組みと対策

jwt none attack（alg: none 攻撃）は、署名アルゴリズムを示すJWTヘッダーを 悪用して署名検証を回避する攻撃です。JWTの危険性や認証の脆弱性として有名ですが、原因はJWTそのものではなく、 検証側がトークン内の指定を無条件に信用する実装にあります。

The JWT "alg: none" attack replaces the token's declared signing algorithm withnone and removes its signature. It succeeds only when a vulnerable verifier trusts that untrusted header and skips signature verification.

TL;DR

• JWTのheaderには必須の alg があり、RFC 7518は署名なしを表す none も定義している
• 検証側が alg: none を見て署名検証を省略すると、攻撃者が任意のpayloadを偽装できる
• 許可アルゴリズムはサーバー設定のホワイトリストで固定し、headerだけで決定しない
• 主要ライブラリは対策済みだが、自前実装・古いバージョン・危険な設定には注意する

1. alg: noneとは / What RFC 7518 defines

JWSとして表現されるJWTのheaderには、署名またはMACに使うアルゴリズムを示す alg フィールドがあります。 RFC 7518はアルゴリズム識別子の一つとして none を定義しており、これはデジタル署名もMACも持たない 「Unsecured JWS」を表します。仕様に存在することは、認証用途のサーバーが受け入れるべきという意味ではありません。

2. jwt none attackの仕組み / Attack flow

1. 攻撃者が正規のJWTを取得し、headerの alg を none に書き換える
2. payloadを {"role":"admin"} など任意の内容に変更する
3. signature部分を空にし、header.payload. の3部分形式でサーバーへ送る
4. 脆弱な実装が「algがnoneなので検証不要」と判断すると、偽造payloadが認証済みとして通る

// 攻撃の概念例（実際の値はBase64URLエンコードされる）
base64url('{"alg":"none","typ":"JWT"}')
  + "."
  + base64url('{"sub":"victim","role":"admin"}')
  + "." // signatureは空

3. 対策 / Pin an algorithm allow-list

検証側は期待するアルゴリズムをサーバー設定から明示的に指定します。クライアントが送った alg は 検証処理への入力の一つにすぎず、それだけを根拠に検証方法や検証省略を決めてはいけません。

Node.js (jsonwebtoken)

import jwt from "jsonwebtoken";
const payload = jwt.verify(token, secret, {
  algorithms: ["HS256"], // サーバー側のallow-list
  issuer: "https://example.com",
  audience: "api.example.com",
});

Python (PyJWT)

import jwt
payload = jwt.decode(
    token, secret,
    algorithms=["HS256"],  # headerから自動選択しない
    issuer="https://example.com",
    audience="api.example.com",
)

jsonwebtoken など主要なJWTライブラリは現在、署名鍵なしで none を暗黙に受理しない対策を 備えています。それでも、古いライブラリ、自前のJWT実装、署名検証を無効化するオプション、広すぎる許可設定は危険です。 依存関係を更新し、alg: none のトークンが必ず拒否されるテストを追加してください。

4. JWT Decoderと署名検証の違い / Decode vs verify

当サイトの JWT Decoder は、JWTをデコードしてheaderとpayloadの中身を見るための ツールです。通常のデコード表示は署名検証を行わない設計なので、表示できても安全性や真正性は確認できません。 実際の認証では、当サイトのHS256対応の署名検証機能、または信頼できるサーバーサイドライブラリを使ってください。

5. JWTを使うべきでない場面 / When not to use JWT

「JWTは使うな」「JWTを使ってはいけない」という主張は、用途を分けて考える必要があります。JWTのpayloadは暗号化ではなく Base64URLエンコードされるだけなので、パスワードや個人情報など機密性の高いデータを入れてはいけません。また、漏えいした トークンの即時失効が必須なら、サーバー側で状態を管理するセッション方式の方が単純で安全な場合があります。

一方、分散したAPI間で短寿命のclaimsを受け渡す用途ではJWTが適することがあります。短い有効期限、安全な保存、 署名とclaimsの厳格な検証を組み合わせることがJWTの安全性を支えます。正しく実装すればJWTは安全に利用できます。

6. 似た攻撃:アルゴリズム混同攻撃(RS256→HS256) / A related attack: algorithm confusion

alg: none攻撃と並んでよく知られるのが、RS256(非対称鍵)からHS256(共通鍵)への アルゴリズム混同攻撃です。RS256は「秘密鍵で署名し、公開鍵で検証する」方式ですが、 検証側がheaderのalgをそのまま信用して検証方式を切り替える実装だと、 公開鍵(しばしば公開されている、またはJWKSエンドポイントから取得可能)をHMACの 共通鍵として悪用され、攻撃者が任意のpayloadに有効な署名を付けられてしまいます。

1. 攻撃者がサーバーの公開鍵(RSA公開鍵)を入手する(JWKSエンドポイントやクライアントコードに埋め込まれていることが多い)
2. headerを{"alg":"HS256"}に書き換え、payloadを改ざんする
3. 公開鍵の文字列をHMACの共通鍵として使い、HS256で署名する
4. 検証側がalgヘッダーに従ってHMAC検証を行うと、公開鍵を知っている攻撃者が 正しい署名を作れてしまうため、改ざんされたトークンが正当と判定される

対策はalg: none攻撃と同じです。検証側でalgorithms: ["RS256"]のように 許可アルゴリズムを固定し、トークンのheaderに書かれたalgだけで検証方式を 決めないようにします。

7. 自分のAPIが脆弱でないか確認する方法 / Testing your own API for this vulnerability

自分が管理するAPIで、この種の脆弱性が無いか手元で確認する手順です(自分のシステム以外には 絶対に行わないでください)。

1. 正規のJWTを1つ取得し、JWT Decoderでheaderとpayloadを確認する
2. headerのalgをnoneに書き換え、signature部分を空にしたトークンを作る (header.payload.の形式、末尾はピリオドのみ)
3. そのトークンを自分のAPIへ送り、拒否されることを確認する(通ってしまう場合は脆弱)
4. RS256を使っている場合は、公開鍵をHMAC secretとして使ったHS256トークンでも同様に試す

どちらのテストも、検証側のライブラリ設定でalgorithmsオプションを明示していれば 確実に拒否されるはずです。CIにこの2種類の不正トークンを拒否するテストケースを常設しておくと、 将来の実装変更でも回帰を防げます。

8. English summary

RFC 7518 defines none for an Unsecured JWS: a token with no digital signature or MAC. The attack changes the JWT header to {"alg":"none"}, modifies claims such as role: admin, and leaves the signature segment empty. It works only if a flawed verifier trusts the token's algorithm and skips verification. Pin an explicit server-side algorithm allow-list, keep JWT libraries current, and test that unsecured tokens are rejected. Decoding is not verification. JWT can be safe when implemented correctly, but do not put secrets in its readable payload; consider server-side sessions when immediate revocation is required.

よくある質問 / FAQ

JWTのalg: none攻撃とは何ですか?

攻撃者がJWTヘッダーのalgをnoneに変更し、署名部分を空にしたトークンを送る攻撃です。検証側がalg=noneを理由に署名検証を省略すると、改ざんしたpayloadが受理されます。

JWTは危険なので使ってはいけないのですか?

JWT自体が危険なのではありません。許可アルゴリズムを検証側で固定し、署名・issuer・audience・有効期限を正しく検証すれば安全に利用できます。ただし即時失効が重要な用途ではサーバーセッションが適する場合があります。

JWT Decoderは署名を検証しますか?

JWT Decoderはheaderとpayloadをデコードして表示するツールで、デコードだけでは署名の正当性を保証しません。署名検証機能または信頼できるサーバーサイドライブラリを使用してください。

関連ツール / Related tools

• JWT Decoder（デコード・HS256署名検証）

関連ガイド / Related guides

• JWTの署名検証に失敗する原因と対処
• JWTのHS256とRS256の違い
• JWT claimsの意味と検証方法