ファイルアップロード機能の脆弱性と対策。Webシェルを置かせないための検証と保存の設計

プロフィール画像や添付書類、CSVの取り込みなど、ファイルを受け取る機能はWebアプリのあちこちに登場します。受け取ったファイルをそのまま公開ディレクトリに保存し、拡張子やContent-Typeだけを軽く見て通してしまうと、攻撃者はサーバ上で動くプログラムを送り込めます。PHPやJSPのような、Webサーバが自動的に解釈して実行する形式のファイルが置かれた瞬間、それはリモートからのコード実行（RCE）への入口になります。

この記事は、ファイルを受け取るコードを書くWebアプリ開発者に向けて、アップロード機能がなぜ狙われるのかという悪用の機構から、入口での検証で見るべきこと、そして受け取ったファイルを実行させない保存と配信の設計までを順に整理します。これはCWE-434「Unrestricted Upload of File with Dangerous Type（危険な種類のファイルの無制限なアップロード）」として知られる問題で、入力の検証という一般原則とは別に、アップロード固有の落とし穴を扱います。

なぜアップロード機能が狙われるのか#

アップロード機能の危うさは、外部から受け取ったファイルが、サーバ上で単なるデータにとどまらず「実行される」「解釈される」余地を持つ点にあります。悪用のされ方はいくつかの型に分かれます。

もっとも影響が大きいのがWebシェルの設置です。攻撃者は.phpや.jsp、.aspといった、Webサーバが自動で実行する形式のファイルをアップロードし、そのURLへアクセスして中身のコードを走らせます。OWASPのコミュニティ資料は、Webシェルをアップロードして実行されるとサーバが乗っ取られ、コマンドの実行やシステムファイルの閲覧、内部リソースへの探索、他サーバへの攻撃の踏み台化にまで至ると説明しています。CWE-434も、アップロードされたファイルが受け手の環境でコードとして解釈、実行されると任意コード実行が成立し得るとしています。

次に保存型XSSです。HTMLファイルやSVG画像、JavaScriptを含むファイルをアップロードでき、それがブラウザにHTMLとして表示される経路があると、閲覧した利用者のブラウザで攻撃者のスクリプトが動きます。SVGは画像でありながら内部に<script>を書ける形式のため、画像として許可したつもりでもスクリプトの実行口になります。

ファイル名の扱いも見落とされがちです。受け取ったファイル名をそのまま保存パスに連結すると、../を含む名前によって想定した保存先の外へファイルを書き込まれるパストラバーサルが起こります。既存ファイルの上書きや、公開ディレクトリの意図しない場所への配置を許すことになります。

OWASPのUnrestricted File Uploadは、実行可能なファイルのアップロードによるサーバ乗っ取り、悪意あるHTMLやSVGによるクライアント側攻撃、ファイル名の細工による上書きや意図しない配置、そしてContent-Typeの詐称や二重拡張子（file.php.jpg など）による検証の回避を、代表的な悪用として挙げています。

このほか、過大なサイズや大量のファイルを送りつけてディスクや処理を枯渇させるDoS、圧縮ファイルを展開させて巨大化させる攻撃、そして画像として正しく開けながら別の形式としても解釈されるポリグロット（複数形式を兼ねるファイル）による検証の擦り抜けも想定します。共通するのは、外部が用意したファイルの中身と、その置き場所をサーバ側が制御しきれていない点です。

入口の検証で見るべきこと#

入口の検証は、明らかに不正なファイルを早い段階で拒否する一段目の壁です。ただし後述するとおり、これだけを頼りにはできません。まずは検証で押さえる項目を整理します。

拡張子は許可リスト（allowlist）で判定します。OWASPのFile Upload Cheat Sheetは、業務に必要な安全な拡張子だけを許可し、危険なものを列挙して弾く拒否リストではなく許可リストで組むことを勧めています。「危険な拡張子を消す」発想は、.php5や.phtmlのような別表記、大文字小文字の混在、file.php.jpgのような二重拡張子で回避されます。CWE-434も、二重拡張子の防止と、大文字小文字を区別しない環境での判定を明記しています。

拡張子だけでは中身を保証できないため、ファイルの実体を検証します。多くの形式は先頭に固有のバイト列（マジックバイト、シグネチャ）を持ちます。PNGなら先頭が89 50 4E 47、JPEGならFF D8 FFといった具合です。宣言された拡張子と実体のシグネチャが一致するかを確かめることで、拡張子だけを書き換えた偽装を弾けます。

そして、Content-Typeヘッダとファイル名は信用しません。OWASPは、Content-Typeは詐称できるため信用せずファイルの種類を検証せよと述べ、コミュニティ資料もWebプロキシでリクエストヘッダのContent-Typeを書き換えるだけで容易に回避できると指摘しています。ファイル名も同様に攻撃者が自由に決められる文字列であり、それを保存パスや表示にそのまま使ってはいけません。

サイズの上限も入口で設けます。OWASPはファイルサイズの上限設定を挙げており、過大なファイルによる枯渇を防ぎます。圧縮ファイルを扱う場合は、展開後のサイズを安全に見積もってから展開します。入口検証の考え方は、入力全般の検証原則と地続きです。役割分担は別記事で整理しています。

あわせて読みたい

入力バリデーションと出力エスケープの原則。入口で検証し、出口で文脈別にエスケープする

実行させない保存と配信の設計#

入口の検証をすり抜けたファイルがあっても被害に至らせない、というのが対策の要です。要点は、受け取ったファイルをサーバに実行させない、解釈させないことにあります。

さらに、アップロードと取得の認可を設計します。誰がアップロードでき、誰がそのファイルを取得できるのかを認証と認可で制御し、想定外の利用者が任意のファイルへ到達できないようにします。運用の防御として、受け取ったファイルをマルウェアスキャンにかける、可能ならCDR（Content Disarm and Reconstruction）で無害化する、といった多層の備えも有効です。ファイル名を保存パスへ連結する処理を残す場合は、パストラバーサルへの対策も併せて確認してください。

あわせて読みたい

パストラバーサルとは何か。基準ディレクトリの外へ解決されるパスの脆弱性と根本対策を解説

対策チェックリスト#

OWASPのFile Upload Cheat Sheetは、拡張子の許可リスト、Content-Typeを信用しないファイル種別の検証、アプリが生成した名前への変更、別サーバまたはwebroot外への保存、ファイルサイズの上限、画像の書き換えによる無害化、アンチウイルスやサンドボックスでの検査を、アップロードを安全に扱うための管理策として整理しています。

まとめ#

ファイルアップロードの脆弱性は、外部が用意したファイルをサーバが実行、解釈してしまうことで成立します。拡張子の許可リストとマジックバイトの検証、Content-Typeとファイル名を信用しない姿勢は、明らかな不正を早く弾く一段目の壁として役立ちます。ただし入口の検証は擦り抜けられる前提で考えるべきで、要は公開ディレクトリの外へランダム名で保存し、その場所でスクリプトを実行させず、配信時にはダウンロードとして扱わせる、という実行させない保存と配信の設計にあります。CWE-434やOWASPが示す管理策も、この二段構えを土台にしています。OWASP Top 10でも、アクセス制御やインジェクションと並んで、外部入力を信頼しすぎないことが繰り返し説かれています。

MITREのCWE-434は、危険な種類のファイルの無制限なアップロードが自動的に処理、実行されることで任意コード実行に至るとし、対策として一意なファイル名の生成、webroot外への保存と代替経路での配信、許可リストによる厳格な入力検証、二重拡張子の防止、サーバ側での検証、権限分離やサンドボックスの活用を挙げています。IPAの「安全なウェブサイトの作り方」も、ディレクトリトラバーサルやアクセス制御の不備を代表的な脆弱性として整理しています。