はじめに
店舗は用意されたカタログから商品画像を取り込みます。ブラウザーがアプリに画像の取得を依頼すると、アプリは買い物客にはないネットワークアクセス権を使います。実際のリクエストを追跡し、無害な内部ステータスを調べて、サーバーサイドリクエストフォージェリ（SSRF）を理解します。
提供されたトレーニング URL だけを使ってください。組織と内部データは合成です。基本的なターミナル操作ができれば十分です。HTTP、URL のフィールド、ネットワークの役割、リダイレクトはここで説明します。コンテナは個別のネットワーク名前空間を持ち、インスタンスのカーネルを共有します。
通常の商品画像を取り込む
このステップでは、実際の画像を取り込み、取得したサーバーを特定します。Image Importer タブに切り替えてください。フォームは画像機能を実行するサーバー App に URL を送ります。URL はアドレスです。http はプロトコル（スキーム）、catalog.test はホスト名、8000 は待ち受けポート、/leaf.png はリソースのパスです。
このステップを始めるには、ラボ画面の Image Importer タブを選択してください。
Image URL は http://catalog.test:8000/leaf.png、Import slot は normal のままにし、Import image をクリックします。Import result ページには実際の HTTP ステータスと、名前付きフィールドを持つ応答である JSON オブジェクトが表示されます。content_type: image/png と、取得バイト列の指紋であるハッシュを探します。body フィールドには符号化した画像バイト列が入ります。このフィールドを編集したりデコードしたりする必要はありません。
同じタブ内の Back to Image Importer（またはブラウザーの戻るボタン）を選択し、ページを更新します。Imported responses に緑の画像が表示されるはずです。表示されなければ URL とスロットの綴りを確認して再送信してください。
クライアントコンテナのターミナル Workstation タブに切り替えます。用意された imagectl.py は App にリクエストを送るプログラムで、python3 が実行します。show normal は再取得せずに既存の取り込みを読みます。
次のコマンドを実行する前に、Workstation タブに切り替えてください。
python3 imagectl.py show normal
HTTP 200、session: learner-c08、PNG image content に注目します。HTTP はリクエストとレスポンスのプロトコルで、200 は成功です。次に Catalog の実際のリクエスト記録を読みます。
python3 imagectl.py requests
各記録には client アドレスと要求した path が含まれます。Catalog が見たのはカタログネットワーク上の App のアドレスであり、Workstation やブラウザーではありません。外向きのリクエストを送ったのは App です。アドレスは変わるため、暗記せずサービスの証拠として読みます。Topology タブに切り替え、設定されたネットワーク接続と、内部サービス利用側のライブ正常性プローブを比較します。
クライアントとサーバーの到達可能性を比較する
このステップでは、用意された内部在庫ステータスだけを App 経由で取得します。内部サービスはアプリの構成要素用ネットワークにあります。Workstation はフロントネットワークに属し、App は内部ネットワークにも属します。localhost は常にコマンドを実行する環境を指します。Workstation のループバックは App のループバックではありません。
このステップを始めるには、ラボ画面の Workstation タブを選択してください。
Workstation から直接リクエストします。補助プログラムは予想される失敗を表示し、シェルは終了しません。
次のコマンドを実行する前に、Workstation タブに切り替えてください。
python3 imagectl.py direct http://internal.test:8000/status
UNREACHABLE from Workstation が表示されます。このコンテナではそのホスト名を利用できません。ネットワークは実アドレスも隔離しているため、名前がないだけではありません。次に App に同じリソースの取得を依頼します。fetch は取り込みを行い、最後の引数はレスポンスの保存スロットです。
python3 imagectl.py fetch http://internal.test:8000/status internal
HTTP 200 と、service: inventory、status: synthetic-ready、変動する training_id を持つ JSON 本文が表示されます。保存したレスポンスを再度読みます。
python3 imagectl.py show internal
記録は learner-c08 に属します。これが SSRF です。クライアントが制御する入力により、サーバーが自分のネットワークアクセス権を使います。Workstation に新しい接続が追加されたわけではありません。no import が出たら internal スロットで再取得します。対象は現在の VM の合成記録だけです。
カタログのリダイレクトをたどる
このステップでは、最初の宛先を確認するだけでは不十分な理由を学びます。リダイレクトは、別の URL を要求するようクライアントに伝える HTTP レスポンスです。Catalog の /redirect は 302 を返し、Location は同じ合成在庫サービスを指します。脆弱な App は自動的にたどります。
このステップを始めるには、ラボ画面の Workstation タブを選択してください。
Workstation から、そのルートを別のスロットに取り込みます。
次のコマンドを実行する前に、Workstation タブに切り替えてください。
python3 imagectl.py fetch http://catalog.test:8000/redirect redirect
レスポンスの url は Catalog、final_url は Internal を示します。本文は画像ではなく現在の合成在庫ステータスです。保存レスポンスと Catalog のログを調べます。
python3 imagectl.py show redirect
python3 imagectl.py requests
Catalog は /redirect を記録し、App は別のネットワークを使って Internal を取得しました。最初のホストが信頼できても、次の宛先まで信頼できるとは限りません。次のラボは独立して開始し、宛先の選択とリダイレクト追従の 2 つの判断を修正します。この管理下の演習は、悪意ある DNS 変更、任意のインターネット画像ソース、別のアドレスエンコードをテストしません。
まとめ
実際の画像を取り込み、クライアントとサーバーの到達可能性を比較し、実際のリダイレクトレスポンスを調べました。内部データは合成で、ネットワークリクエストは実際に行われました。
