【ITニュース解説】10 Security Lessons from Building a Windows MCP Server

ニュース記事では、AIが自身のWindowsマシンを制御するための「MCPサーバー」を構築する中で得られた、10のセキュリティに関する重要な教訓が詳細に解説されている。既存のソリューションがセキュリティ面で不十分であったり、Windowsの特性に最適化されていなかったりしたため、筆者自らが構築するに至ったという。この経験から得られた教訓は、システム開発においてセキュリティをいかに考慮すべきかを示す貴重な指針となる。

まず最初の教訓は、「PowerShellのUnicodeスマートクォート」への注意だ。通常のシングルクォートやダブルクォートのエスケープだけでは不十分で、Microsoft Office製品などからコピー＆ペーストされる可能性のある「スマートクォート」と呼ばれる特殊なUnicode文字が、コマンドインジェクションの脆弱性を引き起こすことがある。これらを適切に処理しないと、攻撃者が入力検証を回避し、意図しないコマンドを実行できてしまう可能性がある。対策としては、これらのスマートクォートだけでなく、ヌルバイトやエスケープされていない改行文字も拒否し、さらに安全性を高めるためには、ユーザー入力を文字列補間ではなく環境変数としてコマンドに渡す方法が推奨される。

次に、「APIキーのサブプロセスへの漏洩」は多くの開発者が見落としがちな問題である。Node.jsのような環境で子プロセスを起動すると、親プロセスの環境変数（APIキーやトークンなどの機密情報を含む）が子プロセスにそのまま引き継がれてしまう。これにより、子プロセスが本来アクセスすべきではない機密情報を参照できるようになり、セキュリティリスクが増大する。この問題への対策は、子プロセスを起動する前に、環境変数から機密情報（例: _TOKEN, _SECRET, _KEY, _PASSWORD, AUTHといったキーワードを含む変数）を明示的に削除またはフィルタリングして渡すことである。

第三の教訓は、「パス・トラバーサルのUnicodeバイパス」に関するものだ。ファイルのパス検証において、多くの開発者は「../」のようなパターンをチェックするが、Windowsシステムでは全角のUnicode文字（例: 「Ｃ：＼Ｕｓｅｒｓ＼ａｄｍｉｎ」）が、半角ASCII文字として処理される特性がある。通常の正規表現による検証ではこれらの全角文字を捕捉できないため、攻撃者がこれを利用して制限されたディレクトリ外のファイルにアクセスする可能性がある。この脆弱性を防ぐには、パスを検証する前に、Unicodeの正規化（NFKC形式など）を行い、全角文字をASCII相当の文字に変換することが重要である。その後、正規化されたパスが許可されたディレクトリの範囲内にあるかを確認する。

第四に、「セッションの有効期限」の設計は極めて重要だ。操作があるたびに有効期限が延長される「スライディング有効期限」のみを設定すると、ユーザーがアクティブである限りセッションが永久に有効になってしまう可能性がある。これにより、もしセッションが侵害された場合、攻撃者がそのセッションを長期間にわたって悪用し続けるリスクが生じる。これを防ぐためには、スライディング有効期限に加えて、セッションが作成されてからの「絶対的な有効期限」を設定し、たとえユーザーがアクティブであっても、一定期間経過後はセッションを強制的に無効化する仕組みが必要である。

第五の教訓は、「ワンタイム交換トークン」の利用だ。認証用のマスターAPIキーなどの機密情報をURLのクエリパラメータとして直接渡すことは非常に危険である。これは、ブラウザの履歴、リバースプロキシのログ、リファラーヘッダなどに漏洩する可能性があり、さらにセッションごとに失効させることも困難である。この問題に対する安全なアプローチは、一度だけ使用できる「ワンタイム交換トークン」を発行することだ。ユーザーはこのトークンを使って認証を行い、その交換が成功した直後にトークンを無効化する。そして、代わりに短命でHttpOnly属性を持つセッションクッキーなどの一時的な認証情報を発行し、それ以降のリクエストに利用する。

第六に、「origin: "*"とcredentials: trueをCORSで同時に設定しない」という点がある。クロスオリジンリソース共有（CORS）の設定において、Access-Control-Allow-Origin: *（全てのオリジンからのアクセスを許可）とAccess-Control-Allow-Credentials: true（認証情報を含むリクエストを許可）を同時に指定すると、Webブラウザはセキュリティ上の理由からそのレスポンスを拒否する仕様になっている。そのため、クッキーなどの認証情報を使用するAPIでは、全てのオリジンを許可することはできない。この問題への対応策としては、リクエスト元のOriginヘッダの値を動的にAccess-Control-Allow-Originに反映させる「動的オリジンリフレクション」を用いる。しかし、この方法を採用する場合は、反射するオリジンを厳密に検証しないと、クロスサイトリクエストフォージェリ（CSRF）の脆弱性を生む可能性があるため、注意が必要である。

第七の教訓は、「TypeScriptにおけるnullとundefinedの違い」だ。JavaScriptやTypeScriptのNullish Coalescing演算子（??）は、nullとundefinedを両方とも「値がない」ものとして扱う。この挙動が原因で、例えばオプションとして{ authToken: null }を渡して「明示的に認証なし」を意図しても、システムがデフォルトの設定値（config.authToken）を適用してしまうという意図しない動作が発生することがある。これを避けるためには、options.authToken !== undefined ? options.authToken : config.authTokenのように、明示的にundefinedのみをチェックする比較を行うことで、nullが「明確に値が存在し、認証なしを意味する」と扱われるようにする必要がある。

第八に、「デフォルトでのフェイルクローズ」だけでは不十分で、「起動ゲート」が必要だ。単に「許可されたディレクトリがない場合はファイルシステムアクセスをブロックする」といったフェイルクローズの原則だけでは、システム全体のセキュリティを担保できない。例えば、認証トークンが設定されていないにも関わらず、サーバーが0.0.0.0（すべてのネットワークインターフェース）でリッスンするように設定されてしまうと、意図せず外部に公開されてしまうリスクがある。このような状況を防ぐためには、サービスが起動する前に特定のセキュリティ条件（例: 認証トークンがない場合は非ローカルホストへのバインドを許可しない）を満たしているかをチェックし、満たさない場合は起動を拒否し、致命的なエラーとしてログに出力してプロセスを終了させる「起動ゲート」を設けるべきである。

第九の教訓は、「監査ログにセッションIDをSHA-256ハッシュ化して記録する」ことの重要性だ。監査ログはシステムの動作状況を追跡するために不可欠だが、そこにセッションIDをプレーンテキストで記録してしまうと、万が一ログが漏洩した場合に、そのセッションIDを使ってユーザーセッションを乗っ取られるリスクが生じる。これを回避するには、ログに記録する前にセッションIDをSHA-256のような強力なハッシュ関数でハッシュ化することである。これにより、ログから元のセッションIDを推測することは困難になるが、ハッシュ化されたIDを使って同じセッション内の複数のリクエストを関連付けて追跡することは引き続き可能となる。

そして最後の第十の教訓は、「バッファ上限とプロセスツリーのクリーンアップ」だ。長期間稼働するMCPサーバーのようなシステムでは、子プロセスから大量の標準出力や標準エラー出力が生成され、それがメモリを肥大化させてシステム障害を引き起こす可能性がある。また、親プロセスが終了した後も子プロセスが「ゾンビプロセス」として残り続け、システムリソースを消費し続ける問題も発生しうる。これらの問題への対策として、子プロセスの出力バッファに厳格な上限（例: 1MB）を設定し、上限を超えた場合には子プロセスを強制的に終了させる仕組みが必要である。さらに、Windows環境では、親プロセスだけでなく、その子プロセスや孫プロセスを含むプロセスツリー全体を確実に終了させるために、taskkill /PID <PID> /T /Fのようなコマンドを利用することが推奨される。

これらの教訓は、MCPサーバーに限らず、あらゆるシステムを構築する上でセキュリティを考慮する際の重要な指針となる。開発の初期段階から脅威モデリングを行い、セキュリティテストを優先し、第三者によるレビューを受けることで、より堅牢なシステムを構築することが可能になる。どんなシステムも完全に安全にすることはできないが、これらの対策を講じることで、攻撃者がシステムを侵害する難易度を大幅に上げることができるだろう。