ファイルアップロードの脆弱性と対策

ファイル名を変更しても、内容が別の形式へ変換されるわけではありません。送信時のContent-Typeも送信側が付ける情報です。ブラウザの選択欄で種類を絞るaccept属性は選択を助けるヒントであり、サーバー側の検査の代わりにはなりません。[T01・T04・T05]

PNGの先頭8バイトのような目印は、形式を見分ける手掛かりです。ただし、先頭の値だけ一致しても、残りのデータがPNGの構造を満たすとは限りません。信頼できる処理ライブラリで形式・構造を確認し、扱う用途に必要な条件を満たすか調べます。[T01・T03]

目印だけのデータ：画像ファイルの成功例ではありません。

ファイルpartのヘッダー例

Content-Disposition: form-data; name="file"; filename="photo.png"
Content-Type: image/png

これは要求全体のContent-Typeではありません。multipartはメッセージ形式であり、安全性検査そのものではありません。[T04]

利用者が送った名前を、そのままサーバーの保存先にしないようにします。アプリ側で保存名を生成し、保存先を限定し、同名ファイルの上書きや対象外への書き込みを防ぎます。元の名前を表示する必要があれば、保存用の識別子とは分けて扱います。[T01・T02・T04]

受信名 photo.png → アプリが付ける識別子 → 限定した登録用保存先

アップロード用の保存先は、可能なら別サーバーやWebの直接公開領域の外へ置きます。必要なファイルだけをアプリの処理を通して返し、取得する利用者の認可も確認します。名前をランダムにすることや、保存先を分けることだけで、認可まで完了するわけではありません。[T01・T02]

アップロードしたファイルが、保存しただけで必ず動くわけではありません。しかし、保存先をWebサーバーがスクリプトとして処理したり、公開した内容をブラウザが解釈したり、後段の処理ライブラリに弱点があったりすると、被害につながる場合があります。実行や公開・処理の方法まで含めて制御します。[T02・T07]

サーバー側の処理

保存先を処理系が解釈する経路や、後段の処理ライブラリの弱点に注意します。

閲覧側の解釈

公開した内容をブラウザが解釈する経路に注意します。

ファイルの実行権限を外すことだけで、あらゆる処理系による解釈が止まるとは限りません。利用目的に合う配信方法と権限を設定し、処理ライブラリを更新します。検査・画像の再生成・マルウェア検査なども、必要に応じて組み合わせます。[T01・T07]

形式が合っていても、大量のファイルや大きな画像で保存容量・メモリ・CPUを消費することがあります。受信サイズ、件数・頻度、展開後の容量や画像の画素数など、用途に応じた制限を設けます。認証・認可やCSRF対策も必要です。[T01・T07]

主図は、小さいファイルを送る権限のある利用者という条件です。実環境では、ファイルの形式だけに頼らず、受信・検査・保存・利用の段階を通して対策します。[T01]

形式と拡張子の整合確認は、令和7年度秋期の情報処理安全確保支援士試験でも問われています。ここでは独自のPNG例を使い、今後の出題を保証するものではありません。[T06]