はじめに：バックエンドの脆弱性がフロントエンドに与える影響

フロントエンドエンジニアの皆さんは、主にユーザーインターフェースや体験の向上に注力されているかと思います。しかし、Webアプリケーション全体のセキュリティを考える上で、バックエンドの脆弱性に対する理解は非常に重要です。特にAPIを介してデータがやり取りされる現代のアーキテクチャでは、バックエンドの脆弱性が直接的・間接的にフロントエンドのセキュリティや信頼性にも影響を及ぼす可能性があります。

今回は、Node.jsベースのアプリケーション「CloudTAK」で発見された深刻度HighのSSRF (Server-Side Request Forgery) 脆弱性 (CVE-2026-55177) について、その技術的な詳細、攻撃手法、そしてこの事例からフロントエンドエンジニアが学ぶべき対策と教訓を解説します。

SSRF (Server-Side Request Forgery) とは何か？

SSRF、日本語では「サーバーサイド・リクエストフォージェリ」とは、攻撃者がWebサーバーに任意のURLへのリクエストを強制する攻撃です。つまり、攻撃者は自身が直接アクセスできない内部ネットワーク上のリソースや、サーバーが実行されているクラウド環境のメタデータサービスなどへ、脆弱なサーバーを経由してアクセスできてしまいます。

この脆弱性が存在すると、サーバーは攻撃者の意図しないリクエストを実行し、機密情報の漏洩、内部サービスの操作、ネットワークスキャンなど、多岐にわたる深刻な被害につながる可能性があります。

CloudTAKのSSRF脆弱性 (GHSA-r95q-fp26-h3hc / CVE-2026-55177) の詳細

CloudTAKの`/api/esri*`系のAPIエンドポイントが、ユーザーが指定したURLをそのまま取得し、バックエンドで`fetch`（`@tak-ps/etl`ライブラリの`fetch`関数）を使ってリクエストを実行していました。問題は、この際に以下のセキュリティ対策が欠如していたことです。

この脆弱性は「フルリード」SSRFと呼ばれており、攻撃者がリクエストを送信できるだけでなく、その応答ボディ（JSONやエラーメッセージなど）を完全に読み取ることができてしまいます。これにより、以下のような深刻な影響が発生します。

CloudTAKプロジェクトには、SSRFを防ぐための`isSafeUrl`というユーティリティ（`@tak-ps/node-safeurl`）が既に存在し、一部の機能（ベースマップ、タスク、ビデオサービスなど）では利用されていました。しかし、今回の`/api/esri*`ルートと関連するESRIライブラリでは、このガードの適用が「不完全に移行」されており、セキュリティ対策が置き去りにされていました。

具体的な攻撃シナリオ (Proof of Concept)

以下のPoCは、いずれも認証済みのユーザーが有効なトークン（`Authorization: Bearer <any-valid-user-token>`）を用いて実行します。

`POST /api/esri`エンドポイントに対し、攻撃者は`url`パラメータにIMDSv1のエンドポイントを指定します。サーバーはこれをフェッチし、AWSの一時的なIAMクレデンシャルを含む応答を攻撃者に返します。

リクエスト例:

```http POST /api/esri HTTP/1.1 Host: cloudtak.example.org Authorization: Bearer <any-valid-user-token> Content-Type: application/json { "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/arcgis/rest" } ```

`GET /api/esri/server`エンドポイントに対し、攻撃者は`server`クエリパラメータにサーバーのループバックアドレスやVPC内のプライベートIPアドレスとポートを指定します。例えば、`http://127.0.0.1:8500/rest`のような内部で稼働している管理ポートなどにリクエストを送信し、その応答を読み取ることができます。

リクエスト例:

```http GET /api/esri/server?server=http://127.0.0.1:8500/rest HTTP/1.1 Host: cloudtak.example.org Authorization: Bearer <any-valid-user-token> ```

対策とフロントエンドエンジニアへの教訓

ユーザーが指定したURLをサーバー側で扱う場合、必ずホワイトリスト方式で許可されるスキーム、ホスト名、IPアドレス、ポートなどを厳格に検証する必要があります。今回のCloudTAKの修正では、既存の`isSafeUrl`ガードをESRIライブラリの中心に適用し、すべての関連パスでURLの安全性を確認するようにしています。

SSRFガードのようなセキュリティ機能は、アプリケーション全体で一貫して適用されるべきです。一部のコードパスで適用漏れがあると、それが脆弱性の温床となります。開発プロセスにおいて、新しい機能やモジュールを追加する際に、既存のセキュリティ対策が正しく組み込まれているかを確認するレビュー体制が重要です。

AWSのIMDSv1はSSRF攻撃に脆弱であるため、インスタンスメタデータサービスバージョン2 (IMDSv2) を積極的に採用し、インスタンスロールの一時クレデンシャル窃盗のリスクを低減することが強く推奨されます。IMDSv2は、メタデータにアクセスするためにセッショントークンを必要とするため、SSRFからの直接的なクレデンシャル取得が難しくなります。

フロントエンドエンジニアは、APIを設計・利用する際に、ユーザーが任意のデータを直接サーバーに渡せるような設計（特にURLやファイルパスなど）がないか意識すべきです。もしそのようなAPIの設計が見られる場合は、バックエンドチームと連携し、リスクについて議論し、適切なバリデーションやサニタイズが実装されているかを確認する役割も担えます。

まとめ

今回のCloudTAKのSSRF脆弱性は、サーバーサイドの入力検証の不備と、既存のセキュリティ対策の適用漏れが複合的に発生した結果です。フロントエンドエンジニアの皆さんにとって、直接バックエンドのコードを書く機会は少ないかもしれませんが、Webアプリケーション全体のセキュリティ、特にユーザー入力がどのように処理されるかを知ることは、安全なアプリケーションを開発する上で不可欠な知識です。

自身の担当領域だけでなく、Webアプリケーション全体を見渡す広い視野を持つことで、より堅牢なシステム構築に貢献できるでしょう。この事例を教訓として、日々の開発業務にセキュリティ意識を取り入れていきましょう。