#セッション管理

認証を突破して中身を盗む話かと思ったら、もっと地味でいやらしい手口だった。Claudeのセッションを盗んで、本人になりすまして使い切る。しかもパスワードや2FAを毎回突破する必要すらない、というのが妙に生々しい。 ここで引っかかったのは、被害が「情報漏えい」だけで終わらないことだ。AIサービスは従量課金や使用量制限があるぶん、ログインを奪われると、攻撃者はデータを抜くだけでなく、利用枠そのものを食い潰せる。つまり被害の形が、昔ながらの「盗む」から「浪費させる」に少し変わっている。これは利用者にとってかなり嫌な変化だと思う。 もうひとつ、Anthropicが「Claudeが原因ではない」と強く釘を刺しているのも印象に残った。たぶん誤解されやすいんだろう。実際には、怪しいゲームのダウンロードや悪性アプリ経由で入った infostealer が、ブラウザに残った cookie やログイン状態を根こそぎ集めて、その中にClaudeのセッションも混じっていた、という筋書きらしい。AIの問題に見えて、根はかなり古典的なマルウェア被害だ。 だから対処も派手さはない。サインアウトさせるだけでは足りず、

この記事を読んでまず思ったのは、「これ、地味だけど本番ではかなり嫌なやつだな」ということだった。 MCP server 自体のロジックが壊れているわけではなく、replica を増やした瞬間にだけ「session not found」が出る。こういう不具合は、単体テストやローカル環境ではまず見えない。だからこそ厄介だし、運用している側からすると一番気持ち悪いタイプの障害だと思う。 特に引っかかったのは、原因がかなり素朴だという点だった。session を local memory に置いているのに、load balancer は毎回どの replica に振るかを気にしない。言われてみれば当然なのに、実際にはその「当然」を見落としてしまう。しかも SSE のように接続が長生きする transport だと、session はクライアントと server の間にある抽象的なものではなく、かなり物理的に「この replica にぶら下がっている状態」になる。そこを別 replica に投げられたら、そりゃ見つからない。 もう一つ面白かったのは、解決策がわりと王道で、だからこそ納得感があった

MCP server を load balancer の後ろに置いた瞬間、なぜか「さっきの続き」が消える。この記事は、その地味だけど厄介な事故をかなり実践的にほどいています。しかも面白いのは、壊れ方が派手なエラーではなく、静かに間違うところです。これ、運用している側からするとかなり嫌なタイプの不具合だと思います。 MCP はもともと「同じセッションが続く」前提で動きやすい でも load balancer は、基本的に「各 request は独立」と見なして振り分ける そのせいで、別の server instance に飛んだ request が session を見失う 典型的な対策は 3 つある - sticky sessions で同じ instance に固定する - Redis などの shared store に session state を逃がす - そもそも state を持たない設計に寄せ、resumable streams を使う どれが正解かは、可用性をどこまで求めるかで変わる MCP は、AI agent や tool 実行の文脈で出てくることが多い仕