はじめに：バックエンドの脆弱性が私たちに与える影響

こんにちは、フロントエンドエンジニアの皆さん。今回は、一見バックエンド寄りに見えるかもしれませんが、ファイルアップロード機能など、私たちがUIを実装する際に密接に関わるサーバーサイドの深刻な脆弱性「GHSA-p3h2-2j4p-p83g」について解説します。この脆弱性は、悪意あるユーザーによってサーバー上の重要なファイルが改ざん・破壊される可能性があり、緊急の対応が求められます。フロントエンドの視点からも、なぜこの問題が重要なのか、どのような影響がありうるのかを理解し、チーム全体でセキュアなシステム構築に取り組む意識を持つことが重要です。

脆弱性の概要：Path Traversal（パス・トラバーサル）攻撃とは

この脆弱性の根幹にあるのは、「Path Traversal（パス・トラバーサル）」、または「Directory Traversal（ディレクトリ・トラバーサル）」と呼ばれる攻撃手法です。これは、アプリケーションがユーザーからの入力によってファイルパスを構築する際に、その入力が適切に検証・サニタイズ（無害化）されていないことを悪用し、アプリケーションが意図しないディレクトリのファイルにアクセス（読み取り、書き込み、実行、削除など）できるようにするものです。

今回のGHSA-p3h2-2j4p-p83gのケースでは、具体的なシナリオは以下の通りです。

アプリケーションには、ユーザーが「MCPBファイル」（実体はZIP形式のアーカイブ）をアップロードできる機能があります。このMCPBファイルはサーバー側で展開され、その中にある `manifest.json` という設定ファイルが読み込まれます。問題となるのは、この `manifest.name` フィールドの値が、展開されるファイルの保存先ディレクトリ名を生成するために、**何の検証もなく直接利用されてしまう**点です。

悪用シナリオ：サーバーが乗っ取られる危険性

攻撃者は、悪意のあるMCPBファイルを細工し、`manifest.json` の `manifest.name` フィールドに `../../../etc/malicious` のような特殊な文字列を仕込みます。システムはこれを無害化せずにパス生成に利用するため、攻撃者はアプリケーションが想定する保存先ディレクトリから抜け出し、サーバー上の任意の場所にファイルを展開したり、既存の重要なシステムファイルを上書きしたりすることが可能になります。

例えば、サーバーの認証情報ファイルや設定ファイルを改ざんされることで、アプリケーションやシステム全体が乗っ取られる、サービスが停止させられる、機密情報が漏洩するといった重大な被害につながる可能性があります。また、脆弱性の詳細には、古いファイルを削除する `cleanupOldMcpbServer` 関数も同様に無害化されていない `name` フィールドを使用しており、意図しないディレクトリの削除につながる可能性も指摘されていますが、主なリスクはファイルの作成・移動によるものです。

緊急対策：セキュアなファイル処理の実装

この脆弱性の影響を避けるためには、以下の対策を速やかに実施する必要があります。これは主にバックエンドの処理ですが、フロントエンドエンジニアも、ファイルアップロード機能の設計や実装時に、このようなリスクを念頭に置くべきです。

`manifest.name` を使用してファイルパスを構築する前に、必ずそのパスがアプリケーションが意図したベースディレクトリ内に収まっているかを厳密に検証するロジックを追加してください。具体的には、生成されたパスを正規化（例: `path.normalize()` や `fs.realpathSync()` など）した後に、そのパスがベースディレクトリからの相対パスであり、外部に逸脱していないことを確認します。もし逸脱していれば、アップロードを拒否します。

`manifest.name` にディレクトリの区切り文字（`/` や `\`）が含まれていても、`path.basename()` のような関数を使って、純粋なファイル名部分（またはディレクトリ名として利用する最終要素）だけを抽出するように修正してください。これにより、パス・トラバーサル攻撃の起点となる `../` などの文字がファイルパスに挿入されるのを防ぎます。

さらに、ファイル名やディレクトリ名として許可される文字種（例：英数字、アンダースコア、ハイフン、ドットのみ）を厳しく制限するホワイトリスト方式を導入してください。それ以外の文字（特にパス区切り文字や特殊文字）が含まれる場合は、アップロードを拒否するべきです。フロントエンド側でも、ファイル名入力時にクライアントサイドバリデーションでこのような制限を補助的に実施できますが、最終的な検証は必ずサーバーサイドで行う必要があります。

上記の修正が正しく機能することを確認するため、悪意のあるパス文字列（例: `../`, `../../`, 絶対パスなど）を含むテストケースを自動テストに追加し、セキュリティ対策が機能していることを継続的に検証してください。

まとめ：セキュアコーディングは全員の責任

今回のGHSA-p3h2-2j4p-p83gの脆弱性は、ユーザーからの入力（特にファイル名やパスに関連するもの）を安易に信用することの危険性を示しています。フロントエンドエンジニアとしては、直接バックエンドのコードを書くことはなくても、ファイルアップロードなどの機能設計・実装時には、サーバーサイドでどのようなセキュリティ対策が必要かを理解し、バックエンドチームとの連携において積極的に意見を出し、セキュアな設計を推奨することが重要です。この機会に、ご自身のプロジェクトにおけるファイルアップロードやファイルパス生成に関わる処理を見直し、安全性の確保に努めましょう。