S3 presigned アップロードURLが key を無検証で受理

概要

共通サーバーアクション apps/user/actions/s3/get-upload-url.ts は、 認証チェック（action() ラッパー）は行うが、クライアントから渡される key を一切検証せず、そのまま presigned PUT URL を発行している。 このため認証済みユーザーであれば、バケット内の任意のオブジェクトキーに対する書き込み用URLを取得でき、 他組織・他ユーザーの画像を含む任意オブジェクトを上書きし得る。

対象

• apps/user/actions/s3/get-upload-url.ts（共通アクション）
• 利用箇所：.../solid-floor-plans/new/_components/solid-floor-plan-create-form、components/need-annotation-in-image-switch

補足：key は MD5(画像データ) によるコンテンツアドレスのため衝突は基本的に「同一内容＝同一キー」で実害は出にくいが、 任意キーを指定できること自体が問題（接頭辞外への書き込み・上書きが原理上可能）。

先送りとした理由

• 今回のセッションは直接アップロード化の機能実装が主目的で、既存パターン（need-annotation）を踏襲した範囲にとどめたため。
• 当面はクライアントがキー接頭辞を solid-floor-plans/ に固定しており、悪用には認証済みアカウントと意図的な改変が必要。
• 恒久対応としてサーバー側でのキー生成 / 接頭辞検証を別途設計したいため（→今後対応したい）。

想定する対応

• サーバー側でキーを生成する（用途別に getUploadUrl を分け、クライアントは mimeType とハッシュのみ渡す）か、
• 少なくとも許可された接頭辞のホワイトリスト検証を行い、範囲外は ErrorCode で失敗させる。
• 組織/ユーザー単位の接頭辞でスコープ分離する案も検討。

優先度

中。即時の実害は限定的だが、認証済みユーザーによる任意キー書き込みを許す設計であり、 アップロード経路を増やす前にサーバー側のキー管理・検証へ寄せておきたい。

関連

• 3D間取り 入力画像のクライアント直アップロード化（セッション）
• 開発規約 / 外部サービス（S3 直接アップロード）