# DockerでOWASP Juice Shopを構築し、JWTを解析する 今日は、Ubuntu ServerにDockerを導入し、OWASP Juice ShopをContainerとして起動した。その後、Kali LinuxからJuice Shopへアクセスし、テスト用アカウントを作成・ログインして、Firefox Developer Toolsから認証CookieとJWTを確認した。JWTをHeader・Payload・Signatureの3要素に分解し、HeaderとPayloadをKali上でBase64URLからデコードして内容を確認・保存した。あわせて、APTとDockerの違い、Docker ImageとContainer、ポート公開、localhost、Cookie、Token、Base64、Python、nanoの基本操作も確認した。
## フェーズ1：Dockerがインストールされているか確認 Ubuntu ServerでDockerの有無を確認した。 docker --version 結果、Dockerはまだインストールされておらず、Ubuntu側から `docker.io` パッケージのインストール候補が表示された。 Dockerは、アプリケーションとその実行環境をContainerという単位で分離して動かすための仕組み。今回の目的は、OWASP Juice ShopをUbuntu Serverへ直接インストールするのではなく、Docker Containerとして動かすことだった。
## フェーズ2：APTとDockerの役割を整理 APTとDockerは役割が異なる。 APT：UbuntuやKaliへソフトウェアをインストール・更新・削除するためのPackage Manager。 Docker：アプリケーションをContainerとして分離して実行するための仕組み。 今回の関係は以下。 APT ↓ DockerをUbuntu Serverへインストール ↓ Docker ↓ OWASP Juice ShopをContainerとして実行 つまり、Juice ShopをAPTで直接インストールするのではなく、APTでDockerを入れ、そのDocker上でJuice Shopを動かした。 APTでJuice Shopを検索することも確認した。 apt search juice 結果、`droid-juicer` や `sound-juicer` など別のソフトしか表示されず、OWASP Juice ShopはAPT Repositoryには存在しなかった。 ここから「すべてのソフトウェアがAPTで入るわけではない」ことを確認した。
## フェーズ3：DockerをUbuntu Serverへインストール Ubuntu Serverで以下を実行した。 sudo apt install docker.io 意味： `sudo`：管理者権限で実行する。 `apt`：APT Package Managerを使用する。 `install`：パッケージをインストールする。 `docker.io`：Ubuntu Repositoryで提供されているDockerパッケージ名。 Docker本体に加えて、Container実行に必要な `containerd`、`runc`、ネットワーク関連の `bridge-utils` なども依存関係としてインストールされた。
## フェーズ4：Dockerサービスの動作確認 Dockerはバックグラウンドで動作するServiceとして起動する。 以下で状態を確認した。 sudo systemctl status docker `systemctl`：systemdでServiceを管理するコマンド。 `status`：現在の状態を確認する。 `docker`：確認対象のService。 結果、Dockerは `active (running)` で動作しており、自動起動も有効になっていた。 ここで「Dockerコマンドは、バックグラウンドで動作しているDocker Engineへ命令を送る」という構造を確認した。
## フェーズ5：hello-worldでDockerの基本動作確認 Dockerが正常に使えるか確認するため、公式の小さなテスト用Imageを実行した。 sudo docker run hello-world 意味： `docker`：Dockerを操作する。 `run`：ImageからContainerを作成して起動する。 `hello-world`：使用するImage名。 実行すると、DockerがImageを取得し、一時的なContainerを起動して `Hello from Docker!` と表示した。 これによって、Docker Engine、Image取得、Container作成、Container実行まで正常に動作することを確認した。
## フェーズ6：Docker Containerの状態確認 現在動いているContainerを確認した。 sudo docker ps `ps`：現在実行中のContainerを一覧表示する。 hello-worldは処理終了後すぐ停止するため、`docker ps` では表示されなかった。 停止済みContainerも含めて確認した。 sudo docker ps -a `-a`：all。停止済みを含むすべてのContainerを表示する。 結果、hello-world Containerは `Exited (0)` になっていた。 `Exited (0)` は、エラーではなく正常終了を意味する。 Dockerが自動で付けたContainer名も確認したが、公開時は特に必要のない情報なので省略する。
## フェーズ7：Docker ImageとContainerの違いを確認 DockerではImageとContainerは別物。 Image：アプリを起動するための設計図・テンプレート。 Container：Imageを元に実際に起動した実体。 イメージとしては以下。 Image ↓ docker run Container Juice Shopでも、まずImageを取得し、そのImageからContainerを作成して起動する流れになる。
## フェーズ8：Juice ShopのDocker Imageを検索 Docker Hub上のImageを検索した。 sudo docker search juice-shop 結果、複数のImageが表示され、その中に以下があった。 bkimminich/juice-shop Description： OWASP Juice Shop... Stars： 複数の評価が付いていた。 `docker search` はDocker Hub上に公開されているImageを検索する。 `bkimminich/juice-shop` はOWASP Juice Shopプロジェクトで利用されるImage。 Docker検索結果の `OFFICIAL` 欄が空欄でも、それだけで偽物とは限らない。Docker Hubの `Official Image` 認定と、各プロジェクトが公式に配布しているImageは別概念。 Image名、説明、Starsなどは参考になるが、実際にはプロジェクト公式ドキュメントなどでImage名を確認するのが安全。
## フェーズ9：Juice Shop Imageを取得 以下を実行した。 sudo docker pull bkimminich/juice-shop 意味： `pull`：Docker RegistryからImageを取得する。 `bkimminich/juice-shop`：取得するImage名。 取得後、Image一覧を確認した。 sudo docker images 結果、以下のImageが存在した。 bkimminich/juice-shop:latest hello-world:latest `latest` は使用しているImage Tag。Tagを指定しない場合、多くのImageでは `latest` が使用される。
## フェーズ10：Juice Shop Containerを起動 Juice ShopをContainerとして起動した。 sudo docker run -d -p 3000:3000 --name juice-shop bkimminich/juice-shop 意味： `docker run`：ImageからContainerを作成して起動する。 `-d`：detached。バックグラウンドで実行する。 `-p`：ContainerのPortをHost側へ公開する。 `3000:3000`：Ubuntu ServerのPort 3000をContainer内部のPort 3000へ接続する。 `--name juice-shop`：Containerへ `juice-shop` という名前を付ける。 `bkimminich/juice-shop`：使用するImage。 構造： Kali / Browser ↓ Ubuntu Server :3000 ↓ Docker ↓ Juice Shop Container :3000 起動時にはContainer IDも表示されるが、公開時には不要なので省略する。
## フェーズ11：Juice Shop Containerの起動状態を確認 以下を実行した。 sudo docker ps 結果、`juice-shop` Containerが `Up` 状態で動いていた。 Port表示： 0.0.0.0:3000->3000/tcp [::]:3000->3000/tcp これは、Ubuntu ServerのIPv4およびIPv6の各InterfaceでPort 3000を待ち受け、Container内部のPort 3000へ転送していることを示す。 `0.0.0.0` は特定の1つのIPだけではなく、そのHostが持つIPv4 Interface全体を意味する。 今回の学習環境ではLAN内からJuice Shopへ到達できる状態になった。
## フェーズ12：Ubuntu Server自身からJuice Shopへアクセス Ubuntu Server上で以下を実行した。 curl http://127.0.0.1:3000 `curl`：HTTPなどを使ってServerへRequestを送り、Responseを確認するコマンド。 `127.0.0.1`：localhost。自分自身を示すLoopback Address。 `:3000`：Port 3000へ接続する。 結果、Juice ShopのHTMLが返り、`OWASP Juice Shop` のTitleなどが確認できた。 これにより、 Docker Containerが起動している ↓ Ubuntu ServerのPort 3000からContainerへ到達できる ↓ Juice ShopがHTTP Responseを返している という流れを確認した。
## フェーズ13：Kali LinuxからJuice Shopへアクセス Kali LinuxのFirefoxからUbuntu ServerのLAN内IP AddressとPort 3000を指定してアクセスした。 http://192.168.x.x:3000 ここでは公開用にLAN内IP Addressを一部伏せている。 `:3000` はJuice Shopを公開しているPort。 Juice Shopの商品一覧画面が表示され、KaliからUbuntu Server上のDocker Containerへ正常にアクセスできることを確認した。 現在の構成： Ubuntu Server ├── Apache HTTP Server :80 └── Docker └── OWASP Juice Shop :3000 同じUbuntu Server上で、ApacheとJuice Shopは異なるPortを使用して同時に動作している。
## フェーズ14：Web ServerとWeb Applicationの違いを確認 ApacheはWeb Server。 Juice ShopはWeb Application。 Web ServerはHTTP Requestを受け取りHTTP Responseを返す役割を持つSoftware。 Web ApplicationはWeb Browserから利用するApplicationで、画面、Backend処理、Authentication、Authorization、API、Databaseなどを組み合わせて機能する。 Juice ShopにはFrontendだけでなく、Login処理やユーザー管理などのBackend機能もある。 APIはFrontendとBackendなど、システム同士が情報をやり取りするInterface・ルール。
## フェーズ15：Juice Shopの画面構成を確認 Juice ShopのHamburger Menuを開き、以下のような機能を確認した。 Login Customer Feedback AI Chat About Us Photo Wall Help GitHub Login画面では以下を確認した。 Email Password Forgot your password? Login Remember me Not yet a customer? ここでAuthenticationの意味を確認した。 Authentication＝認証。 「あなたは本当にそのユーザー本人か」を確認する処理。 一方、Authorization＝認可。 「そのユーザーが何をしてよいか」を決める処理。 Loginは主にAuthenticationの処理に関係する。
## フェーズ16：テスト用ユーザーを登録 Juice ShopのUser Registration画面を開いた。 登録画面には以下の項目があった。 Email Password Repeat Password Security Question Answer Register 学習用のダミーアカウントを作成し、Juice ShopへLoginした。 公開用のため、実際に使用したEmail、Passwordなどの認証情報は記載しない。 Login後はMenuにAccount情報、Orders & Payment、Privacy & Security、Logoutなどが追加された。 正常なLoginの流れ： 登録済みUser ↓ Email / Password送信 ↓ Backendが照合 ↓ Authentication成功 ↓ Login状態を維持する情報がBrowserへ渡される
## フェーズ17：CookieとTokenを確認 Firefox Developer Toolsを開き、StorageからCookieを確認した。 確認されたCookie： cookieconsent_status language token welcomebanner_status CookieはBrowserが保存し、必要に応じてServerとの通信で送信するデータ。 TokenはAuthentication後に「このユーザーはLogin済みである」という情報をServerへ示すために使われる認証情報。 CookieとTokenは同じものではない。 Cookie：Browser側の保存・送信の仕組み。 Token：AuthenticationやAuthorizationに使う情報。 今回のJuice ShopではTokenがCookieに保存されていた。 Login後、毎回Passwordを送信する代わりにTokenを使ってLogin状態を維持できる。 実際のCookie値やToken全文は認証情報に当たるため、公開時には記載しない。
## フェーズ18：JWTの構造を確認 Cookieの `token` をFirefoxのParsed Valueで確認すると、3つに分かれていた。 0: "eyJ..." 1: "eyJ..." 2: "..." これは1つのTokenが3個存在するという意味ではなく、1つのJWTが3つの部分に分かれている。 JWTの典型的な署名形式： Header.Payload.Signature 0 = Header 1 = Payload 2 = Signature Header：JWTの種類や署名方式などの情報。 Payload：ユーザー情報や権限、発行日時などのClaims。 Signature：HeaderやPayloadが改ざんされていないことを確認するための署名。 JWTはJSON Web Tokenの略。 今回確認した形式は、3つのPartを `.` で区切る典型的な署名付きJWTだった。 実際のJWT全文は認証情報として使用できる可能性があるため、公開しない。
## フェーズ19：Base64とデコードの基礎を確認 JWTを解析する前提として、Base64とDecodeの意味を確認した。 例： Hello ↓ Base64 Encode SGVsbG8= ↓ Base64 Decode Hello Encode（エンコード）：データを別の表現形式へ変換する。 Decode（デコード）：変換されたデータを元の意味が分かる形式へ戻す。 Base64は暗号化ではない。秘密にする目的ではなく、Binary Dataなどを文字列として扱いやすくするための表現方式。 Base64らしい特徴： A-Z a-z 0-9 + / 末尾に `=` や `==` が付く場合がある。 ただし、長い英数字だからといって必ずBase64ではない。Hash、API Key、UUID、Tokenなども似た見た目になる。 実際には「Base64かもしれない」と判断してDecodeし、意味のあるデータになるか確認する。 JWTでは通常のBase64ではなくBase64URLが使われる。 Base64URLでは `+` や `/` の代わりに `-` や `_` が使われることがある。 また末尾の `=` Paddingが省略される場合がある。
## フェーズ20：Juice Shop専用の作業ディレクトリを確認 KaliではUbuntu Server本体の調査用ディレクトリとJuice Shop調査用ディレクトリを分けた。 既存： ~/pentest/ubuntu-server Juice Shop： ~/pentest/juice-shop 操作： cd .. pwd ls cd ~/pentest/juice-shop pwd 確認結果： /home/kali/pentest ├── juice-shop └── ubuntu-server 現在の作業場所： /home/kali/pentest/juice-shop 重要コマンド： cd .. 1つ上のDirectoryへ移動。 cd ~/pentest/juice-shop 指定Directoryへ移動。 `~` は現在UserのHome Directory。Kaliでは `/home/kali`。 pwd Print Working Directory。現在のDirectoryを確認。 ls 現在のDirectoryにあるFileやDirectoryを一覧表示。 調査対象ごとにDirectoryを分けることで、後から証拠、結果、メモを整理しやすくなる。
## フェーズ21：JWT Payloadをファイルへ保存 FirefoxでJWTの2番目の部分であるPayloadをコピーした。 Kaliで以下を実行。 nano jwt-payload.txt `nano` はTerminal上で使用するText Editor。 nanoで使用した操作： Ctrl + Shift + V TerminalのClipboardからPaste。 Ctrl + A 現在行の先頭へ移動。 Ctrl + E 現在行の末尾へ移動。 Ctrl + K 現在行をCut。行削除としても使用できる。 Ctrl + U Cutした内容を貼り戻す。 Ctrl + O 保存。 Enter File名を確定。 Ctrl + X nano終了。 保存後： ls ls -lah `ls -lah`： `-l`＝詳細表示。 `-a`＝隠しFileを含める。 `-h`＝File Sizeを人間が読みやすい単位で表示。 結果： jwt-payload.txt 公開時には実際のPayload文字列そのものは掲載しない。
## フェーズ22：Pythonを使ってPayloadを解析 JWTはBase64URL形式なので、Pythonを使ってDecodeした。 APT、Docker、Pythonの役割： APT：SoftwareのInstall・管理。 Docker：ApplicationをContainerとして実行。 Python：Data加工、文字列変換、解析などに利用するProgramming Language。 今回PythonはJWT解析用の道具として使用した。 Python起動： python3 起動すると以下が表示される。 >>> `>>>` 以降はLinux CommandではなくPythonの命令を入力する。 必要なModuleを読み込んだ。 import base64, json `base64`：Base64/Base64URLを扱うPython標準Library。 `json`：JSON Dataを扱うLibrary。 保存済みPayloadを読み込んだ。 p = open("jwt-payload.txt").read().strip() 意味： `open("jwt-payload.txt")`：Fileを開く。 `.read()`：内容を読み込む。 `.strip()`：前後の空白や改行を除去。 `p =`：読み込んだ内容をVariable `p` に保存。
## フェーズ23：Base64URL Decode Errorを調査 最初に以下を実行した。 decoded = base64.urlsafe_b64decode(p + "=" * (-len(p) % 4)) しかしErrorが発生した。 binascii.Error: Invalid base64-encoded string まずJWT全体を誤って保存していないか確認した。 p.count(".") 結果： 0 JWT全体なら通常、 Header.Payload.Signature となり、`.` が2個存在する。 結果が0だったため、JWT全体ではなくPayload単体であることを確認した。 次にPayloadの先頭部分を確認した。 print(repr(p[:20])) Firefoxの表示からコピーした時に、Parsed Valueの番号や引用符まで含めて保存していたことが判明した。 この余計な文字がBase64URLとして不正だったためDecodeに失敗していた。 Python終了： exit() nanoで修正： nano jwt-payload.txt 先頭のParsed Value表示部分と、末尾に存在する余分な引用符を削除し、Base64URL文字列のみ残した。 この作業によって、Error Messageを確認し、入力Dataの形式を調べ、原因を特定して修正する基本的なTroubleshootingも行った。
## フェーズ24：PayloadのDecodeに成功 Pythonを再度起動。 python3 Module読み込み： import base64, json Payload読み込み： p = open("jwt-payload.txt").read().strip() Base64URL Decode： decoded = base64.urlsafe_b64decode(p + "=" * (-len(p) % 4)) `"=" * (-len(p) % 4)` は、JWTのBase64URLで省略されることがある `=` Paddingを必要数補う処理。 結果を文字として表示： print(decoded.decode()) `.decode()` はBase64 Decodeとは別。 Base64URLをDecodeした結果はPython上ではbytes型なので、それを人間が読める文字列として扱える形へ変換する。 Payloadには以下の種類のFieldが存在した。 id username email password role deluxeToken lastLoginIp profileImage totpSecret isActive createdAt updatedAt deletedAt bid iat 重要項目： role: customer 現在のUserが一般Customer権限であることを示していた。 iat Issued At。JWTが発行された時刻を示すClaim。 Payload内には `password` Fieldも存在したが、平文Passwordではなく固定長の16進文字列だった。 公開用には、Email、Password相当値、User ID、Token固有値など具体的なPayload内容は掲載しない。 JWTのPayloadは暗号化されているわけではないため、Base64URLをDecodeすれば内容を読むことができる。 ただし、Payloadを書き換えただけでは正常なSignature検証を通過できない。
## フェーズ25：Payload Decode結果を保存 解析結果を保存した。 open("jwt-payload-decoded.txt", "w").write(decoded.decode()) 意味： `open(..., "w")`：書き込みModeでFileを開く。 `.write(...)`：Dataを書き込む。 `decoded.decode()`：読める文字列へ変換済みのPayload。 Python終了： exit() 確認： ls -lah この時点： jwt-payload.txt jwt-payload-decoded.txt 元DataとDecode後Dataを別Fileとして保存した。 実際の保存内容は公開せず、File名と解析手順のみ記録する。
## フェーズ26：JWT Headerを取得 JWTの最初の部分を確認した。 Header.Payload.Signature ↑ 今回確認 Firefox Parsed Valueでは `0:` の部分。 HeaderのBase64URL文字列だけをコピーし保存した。 nano jwt-header.txt 保存後： ls -lah 確認： jwt-header.txt jwt-payload.txt jwt-payload-decoded.txt
## フェーズ27：JWT HeaderをDecode Python起動： python3 Module： import base64, json Header読み込み： h = open("jwt-header.txt").read().strip() Base64URL Decode： decoded_h = base64.urlsafe_b64decode(h + "=" * (-len(h) % 4)) 表示： print(decoded_h.decode()) 結果： {"typ":"JWT","alg":"RS256"} `typ`：Token Type。今回 `JWT`。 `alg`：Algorithm。JWT Signatureに使用されている署名Algorithm。 今回： RS256 RS256はRSAとSHA-256を使用するDigital Signature方式。 基本構造： Private Key → JWTへ署名する Public Key → Signatureを検証する RS256では署名用のPrivate Keyと検証用のPublic Keyが異なる。 Payloadにある `role` を別の権限へ単純に変更するとHeader/PayloadとSignatureの整合性が崩れる。 正常にSignatureを検証するServerであれば、そのJWTは拒否される。
## フェーズ28：Header Decode結果を保存 Headerの解析結果も保存。 open("jwt-header-decoded.txt", "w").write(decoded_h.decode()) Python終了： exit() 保存状態： jwt-header.txt jwt-header-decoded.txt jwt-payload.txt jwt-payload-decoded.txt 元DataとDecode結果をそれぞれ保存した。
## フェーズ29：JWT Signatureを保存 JWT最後の要素であるSignatureをFirefoxから取得した。 Header.Payload.Signature ↑ 今回保存 Firefox Parsed Valueでは `2:` の部分。 Signature文字列だけをコピー。 Kaliで以下を実行。 nano jwt-signature.txt 保存後： ls -laa 最終的に以下のFileが揃った。 jwt-header-decoded.txt jwt-header.txt jwt-payload-decoded.txt jwt-payload.txt jwt-signature.txt `ls -laa` でも一覧確認できるが、File Sizeを読みやすく確認する場合は以下を使用。 ls -lah 実際のSignature値は認証Tokenの一部なので公開しない。
## フェーズ30：今日確認したJWT全体の仕組み 今回のJWT： Header.Payload.Signature Header： {"typ":"JWT","alg":"RS256"} JWTの種類と署名方式を示す。 Payload： User ID Email role Login関連情報 作成日時 JWT発行日時 その他User情報 Tokenに含まれるClaimsを保持する。 Signature： HeaderとPayloadが改ざんされていないことをServer側で検証するためのDigital Signature。 HeaderとPayloadはBase64URLで表現されているため、誰でもDecodeして読むことができる。 Signatureは内容を隠すための暗号化ではなく、改ざん検知と真正性確認に使われる。 したがって、 JWTが読める ≠ JWTを自由に書き換えて使用できる という違いがある。 公開時はJWT全文、Signature、Cookie値、Email、Password、Hash相当値などは掲載しない。
## フェーズ31：今日使用したDocker関連の重要コマンド docker --version DockerのVersionとインストール状況を確認。 sudo apt install docker.io APTを使ってUbuntuへDockerをインストール。 sudo systemctl status docker Docker Serviceの起動状態を確認。 sudo docker run hello-world Test ImageからContainerを起動しDockerの正常動作を確認。 sudo docker ps 実行中のContainerを一覧表示。 sudo docker ps -a 停止済みを含むすべてのContainerを表示。 sudo docker search juice-shop Docker HubからJuice Shop関連Imageを検索。 sudo docker pull bkimminich/juice-shop Juice Shop Imageを取得。 sudo docker images 取得済みDocker Imageを一覧表示。 sudo docker run -d -p 3000:3000 --name juice-shop bkimminich/juice-shop Juice Shop Containerをバックグラウンドで起動し、UbuntuのPort 3000をContainerのPort 3000へ接続。 curl http://127.0.0.1:3000 Ubuntu Server自身からJuice ShopへHTTP Requestを送り、正常に応答することを確認。
## フェーズ32：今日使用したLinux・Python関連の重要コマンド cd .. 1つ上のDirectoryへ移動。 cd ~/pentest/juice-shop Juice Shop専用作業Directoryへ移動。 pwd 現在地を表示。 ls File・Directory一覧を表示。 ls -lah 詳細、隠しFile、読みやすいSize表示で一覧確認。 nano ファイル名 Terminal上でFileを作成・編集。 python3 Python対話環境を起動。 import base64, json Base64とJSONを扱うModuleを読み込む。 open("ファイル名").read().strip() Fileを読み込み、前後の空白や改行を除去。 base64.urlsafe_b64decode(...) Base64URLをDecode。 print(...) 内容をTerminalへ表示。 .decode() bytesを文字列として読める形へ変換。 open("ファイル名", "w").write(...) 解析結果をFileへ保存。 exit() Python対話環境を終了。
## フェーズ33：nanoで使用した基本操作 Ctrl + Shift + V TerminalからPaste。 Ctrl + A 現在行の先頭へ移動。 Ctrl + E 現在行の末尾へ移動。 Ctrl + K 現在行をCut。 Ctrl + U Cutした内容を貼り戻す。 Ctrl + O 保存。 Enter File名を確定。 Ctrl + X nanoを終了。
## フェーズ34：現在のLab構成 Kali Linux ↓ HTTP Ubuntu Server ├── Apache HTTP Server :80 └── Docker └── OWASP Juice Shop :3000 Kaliは攻撃・調査側。 Ubuntu ServerはTarget。 ApacheはPort 80。 Juice ShopはDocker ContainerとしてPort 3000で動作。 Juice Shopは意図的に脆弱なWeb Applicationであり、今回の許可された自宅Lab内で学習対象として使用している。 公開用では、LAN内IP Addressの具体値やTailscale Addressなど、構成上不要な識別情報は省略する。
## フェーズ35：現在のJuice Shop作業ディレクトリ /home/kali/pentest/juice-shop/ ├── jwt-header.txt ├── jwt-header-decoded.txt ├── jwt-payload.txt ├── jwt-payload-decoded.txt └── jwt-signature.txt ここまでで、Ubuntu ServerへDockerを導入し、Dockerの基本動作をhello-worldで確認、OWASP Juice Shop Imageを取得、ContainerをPort 3000で起動、Ubuntu自身とKali双方からアクセスできることを確認した。その後、Juice Shopでテストユーザーを登録・Loginし、Firefox Developer ToolsでCookieとJWTを確認、JWTをHeader・Payload・Signatureへ分解、HeaderとPayloadをBase64URLからDecode、PayloadのUser情報とrole、HeaderのRS256署名方式を確認し、元Dataと解析結果をKali上へ保存するところまで完了した。