JSONウェブ署名デコード：重大な検証脆弱性への入り口

を知らない人のために説明しよう。 JSONウェブ署名デコード トークン内のクレームを表示するための単純なBase64URLデコード作業である。しかし、セキュリティ・エンジニア、侵入テスト担当者、AIセキュリティ研究者にとって、「デコード」はより複雑な戦場の偵察段階に過ぎない。

開発者は認証フローのデバッグにデコードを使用するが、攻撃者は署名ロジックのリバース・エンジニアリングにデコードを使用する。このギャップは デコーディング トークンと 検証 その完全性は、現代のAPIの歴史において最も危険な認証バイパスの脆弱性が存在する場所である。

この記事では、JWSを解剖し、影響力の大きいCVEを含む重大な検証の失敗を分析し、JWSを動かすエンジンのようなAI主導のセキュリティがどのように機能するかを探る。 寡黙-は、こうした暗号メカニズムの監査方法を変えようとしている。

JWSの解剖：Base64だけではない

エクスプロイトを分析する前に、次のように定義された構造を確認する必要がある。 RFC 7515.JSONウェブ署名（JWS）は、デジタル署名またはメッセージ認証コード（MAC）で保護されたコンテンツを表します。

コンパクトなJWS文字列は、ドット(.):

ヘッダー.ペイロード.シグネチャー

解読ロジック

を実行する。 jsonウェブ署名デコードつまり、最初の2つのセグメントをBase64URLフォーマットからJSONに変換していることになる。

ここでは、機密トークンを記録するかもしれないウェブベースのツールよりもCLIを好むセキュリティ研究者のために、生のPython実装を紹介します：

パイソン

インポート sys インポート json インポート base64

def padding_fix(data): missing_padding = len(data) % 4 if missing_padding: data += '=' * (4 - missing_padding) return data

def decode_jws(token): try: header_b64, payload_b64, signature_b64 = token.split('.')。

    header = json.loads(base64.urlsafe_b64decode(padding_fix(header_b64)))
    ペイロード = json.loads(base64.urlsafe_b64decode(padding_fix(payload_b64)))
    
    return header, payload
except ValueError：
    print("[-] 無効なトークン形式")
    sys.exit(1)

使用状況

ヘッダ、ペイロード = decode_jws(sys.argv[1])

print(json.dumps(ヘッダー, インデント=2))`。

デコード操作の出力は、通常、検証の方法を指示するメタデータを明らかにする。 べきである が起こる。このメタデータが攻撃者の主なターゲットである。

デコードとベリファイ "のギャップ：脆弱性の居場所

核心的な問題は、多くのライブラリやカスタム実装が デコード からのステップ ベリファイ ステップを参照。アプリケーションは、ヘッダーをデコードして アルグ フィールドに入力し、そのユーザー制御入力を使って署名の検証方法を決定する。

1.なし」アルゴリズムのバイパス

これはJWSの悪用における「ハロー・ワールド」であるが、レガシー・システムでは根強く残っている。バックエンドの実装が アルグ ヘッダをデコードしたトークンから検証ロジックを決定すると、攻撃者はトークンを変更することができます：

1. デコード ヘッダー
2. 変更 アルグ への なし (または なし, なし).
3. 署名を消す。

もしライブラリが なし (デバッグ用)で、アルゴリズムをホワイトリストに登録していない場合、署名チェックは完全にスキップされる。

2.アルゴリズムの混乱（キーの混乱）

これはより巧妙な攻撃である。サーバーが対称（HMAC）署名と非対称（RSA/ECDSA）署名の両方をサポートしているにもかかわらず、特定の鍵にどちらが使われているかを検証できない場合に発生する。

• シナリオ サーバーはRS256トークン（秘密鍵で署名され、公開鍵で検証されたもの）を期待する。
• 攻撃だ： 攻撃者は jsonウェブ署名デコード変更点 アルグ への HS256 (HMAC）を使ってトークンに署名し、サーバーの 公開鍵 をHMACシークレットとする。
• 結果 公開鍵は多くの場合クライアントが利用できる（あるいは簡単にアクセスできる）ので、攻撃者はサーバーが自身の公開鍵を使って検証する有効な署名を偽造することができる（HMAC秘密鍵として扱う）。

ケーススタディCVE-2022-21449 ("Psychic Paper")

アルゴリズムの混乱はロジックの欠陥だが、暗号の実装自体の奥深くに存在する脆弱性もある。

CVE-2022-21449 (CVSS 7.5)は、"Psychic Paper "と呼ばれ、JavaのECDSA署名の実装に影響を与えた。これは、単に「署名が存在する」ことを検証するだけでは不十分であることを示す典型的な例である。

メカニズム

ECDSAでは、検証には数学的方程式が関係する：$v = R'$（簡略化）。脆弱性はJavaの イーシーディーエスエー この実装では、シグネチャーの$r$と$s$がともに 0検証ロジックは誤って 真の にとって いずれも ペイロード。

攻撃者は可能だ：

1. デコード 正当なJWSである。
2. ペイロードを修正する（例． {"admin": true}).
3. $r=0$、$s=0$のシグネチャを作成する。
4. Javaベースのバックエンド（Java 15、16、17、18を実行している）に送る。

サーバーはその署名を有効なものとして検証し、完全な認証バイパスを可能にする。これは、標準的で広く使われているライブラリでさえ、致命的な失敗を免れないことを浮き彫りにしている。

AIによるJWS監査：懺悔的アプローチ

JWSトークンを手動で分析することは、個々のエクスプロイトには効果的だが、最新のマイクロサービス・アーキテクチャでは、数百の異なるキー、ローテーション・ポリシー、アルゴリズム構成が採用されていることが多い。人間のエンジニアが手作業で jsonウェブ署名デコード そして、ヘッダーインジェクション、キーの混乱、ライブラリ固有のバイパスなど、攻撃対象領域全体にわたるあらゆる順列をテストする。

そこで、AIによる自動侵入テストが不可欠となる。

寡黙 は、高度な大規模言語モデル(LLM)と強化学習を活用し、このような深いテストを自動化します。Penligentのエンジンは、静的な正規表現を使って既知の悪い文字列を探す従来のスキャナーとは異なります：

1. 文脈解読： トラフィックをインターセプトし、JWSトークンをデコードし、コンテキストを理解する（例えば、「このトークンはログインだけでなく、ペイメントゲートウェイに使用される」）。
2. 適応的なペイロード生成： それは、ただ努力するだけではない。 alg: なし.バックエンドライブラリを推測するために、サーバーのエラー応答を分析する。Java環境を検出すると、CVE-2022-21449のバリエーションを試すかもしれない。もし キッド パラメータを使用して、キーIDを介したSQLインジェクションやコマンド・インジェクションをプローブする。
3. ロジックフロー分析： Penligentは、あるエンドポイントでトークンが正しく検証されていても、単に デコード済み セカンダリ・マイクロサービスでの検証なしに信頼されることは、一般的なアーキテクチャの欠陥である。

インテリジェントなJWS分析を統合することで、Penligentは単純な脆弱性スキャンの域を超え、次のような領域へと進んでいます。 自律的レッドチームこれは、暗号実装が既知のCVEとゼロデイ論理欠陥の両方に対して堅牢であることを保証するものである。

エンジニアのためのハードニング・ガイドライン

JWS攻撃からアプリケーションを守るためには、"暗黙の信頼 "から "明示的な検証 "に移行しなければならない。

1.アルゴリズム・ホワイトリストの実施

に頼ってはならない。 アルグ ヘッダをデコードして検証方法を決定します。期待されるアルゴリズムをベリファイアにハードコードする。

ジャバスクリプト

// 安全なアプローチ (Node.js の jose ライブラリ) const verified = await jose.jwtVerify(token, secretKey, { algorithms: ['RS256'], // 明示的に RS256 のみをホワイトリストに登録 })；

2.を検証する。 キッド (キーID）STRICTLY

セットアップで複数のキー（JWKS）を使用する場合は、必ず キッド ヘッダがホワイトリストのキーにマッチする。ヘッダーに キッド 値をデータベースクエリやファイルシステム呼び出しに直接渡すことができます。

3.近代的な図書館を利用する

独自の暗号ラッパーを書くのは避けよう。以下のような、十分にテストされたライブラリを使おう。 ホセ (Node.js）、 PyJWT (Python)、または jjwt (Java）。ただし、これらのライブラリのセキュリティ情報を購読していることを確認してください。

4.デコードとベリファイを分ける（論理的に）

それを理解する jsonウェブ署名デコード は 表示 目的（UI、ロギング）。 ベリファイ は 認定.検証ステップが戻る前に、デコードされたデータをビジネス・ロジックに使用しないでください。 真の.

結論

能力 jsonウェブ署名デコード は基本的なスキルであるが、それは単に表面のスクラッチに過ぎない。セキュリティエンジニアにとって、生のJSONは潜在的な誤設定の地図である。古典的な「None」アルゴリズムから、CVE-2022-21449のような数学的バイパスまで、ウェブの完全性は、単にデコードに成功するだけでなく、厳密な検証に依存しています。

アプリケーションの複雑さが増すにつれて、次のようなAI搭載ツールを活用する必要があります。 寡黙 このような微妙な暗号の欠陥の検出を自動化することは、企業の強固なセキュリティ体制のために必要になってきている。

参考文献

• RFC 7515 - JSONウェブ署名（JWS）
• NIST 特別刊行物 800-63B - デジタル ID ガイドライン
• CVE-2022-21449 詳細 - NVD
• OWASP JSON Webトークンチートシート