認証なし、完全な制御: 公開された Claude Code Web UI のリスク

英語からの翻訳です。原文は English.

AI Web UI の台頭

Claude Code は CLI ですが、ブラウザで使いたいという人は多く、siteboon/claudecodeui や clawdbot/clawdbot のように、CLI を Web インターフェースで包むオープンソースプロジェクトが GitHub にいくつもあります。

便利ではありますが、CLI が自分のマシン上で何をできるのかを思い出すと話が変わります。私はこれらのいくつかをローカルで試しましたが、ほとんどが同じパターン、つまりクライアントを信用するという作りになっていました。

注: これは特定の開発者を叩く記事ではありません。これらはコミュニティ製のプロジェクトで、実験的なものも多いです。ここで伝えたいのは、特に強力な AI エージェントをネットワークに公開する場合、「動く」ことと「安全である」ことは別だという点です。

見つけたもの

構成は単純です。フロントエンドがバックエンドと通信し、バックエンドが claude プロセスを起動します。私が試したバージョンでは、この 2 つの層の間にほとんど検証がありませんでした。

公開状況 (FOFA 検索)

コードを読む前に、これほど危険なアプリを実際に公開インターネットで動かしている人がいるのかを確認したいと思いました。

これらの Web UI に固有のシグネチャを使って FOFA で検索しました。

公開されている Claude Code Web UI のインスタンスを探す FOFA.info の検索クエリ

83 個の公開インスタンスが見つかりました。つまり、認証なしでリモートシェルに入れるマシンが 83 台、公開インターネット上に置かれているということです。

83 個の公開インスタンスを示す FOFA の検索結果

1. 任意パスでの実行 (/projects の上書き)

最もひどかったのは、バックエンドが Claude をどこで実行するかを決める部分でした。/projects エンドポイントへのリクエストを傍受すると、対象ディレクトリを好きな場所に設定できました。

サーバー側には、パスが許可されたディレクトリの中にあるかを確認する処理がありませんでした。ファイルシステムのルートでインスタンスを起動でき、エージェントは好きなものを読み書きできる状態になります。

2. AI をソーシャルエンジニアリングして認証情報を引き出す

Web UI はチャット履歴を保持し、セッションも管理しています。この後者だけで、エージェント自身に認証情報を読み上げさせるには十分でした。エージェントは環境変数や設定ファイルにアクセスでき、システムプロンプトにも禁止する指示がないため、「auth token を表示して」という単純な質問でもたいてい通りました。

3. AI 経由のリモートコード実行 (RCE)

これが最も重要です。Claude Code は設計上、ターミナルコマンドを実行します。それを認証なしの Web UI の裏に置けば、認証なしの Web シェルを公開したことになります。

次のことを確認できました。

  • チャットにコマンドを注入する。
  • AI にホスト上でそれを実行させる。
  • 出力を取得する。
  • 偽のチャット履歴を注入して、AI のコンテキストを操作することまでできる。

4. クライアント側の認証バイパス

あるプロジェクトは、PIN でインターフェースを保護しようとしていました。しかしそのチェックは完全にブラウザ内で行われていました。

DevTools を開くと、localStorage に「認証済み」を意味する boolean が見つかりました。それを true にしてページを更新すると、中に入れました。サーバーは次のリクエストでセッショントークンを確認しておらず、人を止める役目をフロントエンドに任せきっていたのです。

「自分のバグじゃない」症候群

これはすべて一つの誤解から来ています。LLM ラッパーを普通の Web アプリと同じように扱ってしまうことです。ラッパーの向こう側にあるものがシェルを持っているなら、作ったのは前面にチャットボックスが付いたリモート管理ツールです。

必要なものは 3 つあります。

  1. サーバー側の認証。 ブラウザで一度だけ確認するのではなく、すべてのリクエストで JWT またはセッション cookie を検証する。
  2. サンドボックス。 エージェントを、本当に必要な権限だけを持つコンテナで動かす。
  3. 許可リスト。 パスとコマンドを、リクエストが届く前に自分で書いたリストと照合する。

このうち一つでも欠けると、設定ミスが一つあるだけで完全に侵害されます。

開発者とユーザーへ

こうしたツールを作っている場合

  • クライアントを決して信用しない。
  • リクエストを送ってくる相手は侵入したがっていると考える。
  • README にセキュリティリスクの節を設け、VPN やリバースプロキシなしで 0.0.0.0 にバインドしないよう明記する。

使っている場合

  • インターネットにポートフォワードしない。
  • 可能なら VM かコンテナで動かす。
  • デスクトップですでに開いているターミナルウィンドウと同じものとして扱う。

LLM は警備員としては頼りになりません。インターネットとあなたのシェルの間にある唯一の防御にしないでください。