ファイルアップロードの「聖域」を守る：パス・トラバーサルを根絶するアーキテクチャ設計
ファイルアップロード機能は、Webアプリケーションにおける「最大のパンドラの箱」だ。多くの開発者は「拡張子をチェックしているから安全だ」と安堵するが、現場の泥臭いインシデントハンドリングの最前線にいる人間から言わせれば、それは脆弱性の入り口に過ぎない。
今日は、攻撃者がOSの権限を奪取する際、あるいはWebシェルを仕込む際に必ず通過する「パス・トラバーサル（Path Traversal）」の深淵に切り込む。なぜ、単なるバリデーションでは不十分なのか。そして、プロの現場で採用される「防御的設計」の真髄を語ろう。
—
1. 脆弱性の解剖：なぜ「ファイル名」を信じてはいけないのか
攻撃者が狙うのは、ファイル名に含まれるメタ文字やディレクトリトラバーサルシーケンス（../）だ。例えば、攻撃者が ../../var/www/html/shell.php というファイル名を送信した際、アプリ側がこの入力をそのまま保存処理に使えば、意図しないディレクトリにファイルを書き込まれる。
これは単なるコーディングミスではない。OSレベルでは、ファイルシステムAPIがパスを解決する際、正規化（Normalization）プロセスに脆弱性が潜むことが多い。メモリレイヤで言えば、ヌルバイト注入（\0）による文字列終端の誤認や、ファイルシステムドライバの挙動を突いた攻撃が、今なおCVEの常連として君臨している。
2. 「防御の鉄則」：保存ロジックの完全分離
安全なファイルアップロードを実装するための鉄則は、「ユーザー入力とファイルシステムパスを物理的に切断すること」だ。これを実現するアーキテクチャ設計を以下に示す。
推奨する保存ロジック（擬似コード）
import os
import uuid
import mimetypes
from werkzeug.utils import secure_filename
許可する拡張子のホワイトリスト（MIMEタイプとペアで管理するのがベスト）
ALLOWED_EXTENSIONS = {‘.jpg’, ‘.png’, ‘.pdf’}
def save_uploaded_file(uploaded_file):
# 1. ファイル名から一切のメタ文字を除去（最悪の事態を防ぐための最低限の層）
original_filename = secure_filename(uploaded_file.filename)
# 2. 拡張子の検証
ext = os.path.splitext(original_filename)[1].lower()
if ext not in ALLOWED_EXTENSIONS:
raise ValueError(“不適切なファイル形式です”)
# 3. ファイル名の完全ランダム化（UUID v4を採用）
# ユーザー由来の情報をファイル名に含めないことが最大の防御
secure_name = f”{uuid.uuid4()}{ext}”
# 4. 保存先はWeb公開ディレクトリから隔離された領域にする
# Webサーバが直接実行権限を持たないパスを指定する
upload_path = os.path.join(‘/var/www/uploads/internal/’, secure_name)
# 5. 保存実行
uploaded_file.save(upload_path)
# DBには secure_name のみを保存し、マッピングテーブルで管理する
return secure_name
3. 深層防御（Defense in Depth）の視点
上記コードはあくまで「アプリ層」の対策だ。チーフホワイトハッカーとして言わせれば、これだけでは足りない。以下の3層構造で守りを固めるのが、堅牢なシステムの条件である。
- ストレージ層の制限: アップロード用ディレクトリに対し、Webサーバの実行ユーザー（
www-dataなど）に「書き込み権限」は与えても、「実行（Execute）権限」は絶対に与えてはならない。mountオプションでnoexecを指定するのは常識だ。 - コンテンツ検証: 拡張子だけでなく、ファイルバイナリの先頭数バイト（マジックナンバー）を解析し、MIMEタイプを厳格に判定する。画像であれば、実際に画像処理ライブラリを通し、再エンコードさせることで、悪意あるコード片が埋め込まれたステガノグラフィ攻撃を無効化する。
- ガードレイルの適用（生成AI時代）: 近年、LLMを活用したアップロード機能も増えている。この場合、アップロードされたファイルを直接LLMに渡すのは自殺行為だ。ファイルの中身を安全なサンドボックス内でテキスト化し、その「テキストの内容」に対してプロンプトインジェクションのガードレイルを適用した後に、LLMへ渡すというパイプラインが必要になる。
4. 監査とインシデントへの備え
最後に、セキュリティアーキテクトとして提言したいのは、「ログの透明性」だ。
ランダム化したファイル名を保存する場合、元のファイル名が分からなくなると、インシデント発生時のフォレンジックが困難になる。UUIDと元のファイル名、そしてアップロード時のIPアドレスやセッションIDを分離した「監査ログテーブル」を作成しておくこと。
もし攻撃者がパス・トラバーサルを試行した際、それが「失敗した記録」こそが、次にくる大規模攻撃の予兆（シグナル）となる。ログを監視し、特定のIPが短時間に何度も異なるパス名でアップロードを試みているなら、即座にそのセッションを遮断する自動防御機構を構築しておこう。
—
結びとして：
セキュリティとは「穴を塞ぐ」ことではない。「穴が開いてもシステムが沈まないような設計」をすることだ。ファイルアップロードの設計は、その最たる例といえる。便利さと引き換えにリスクを持ち込まない。その矜持こそが、我々エンジニアに求められている。
コメント