【SC試験】ファイルアップロード機能の脆弱性 — 午前I・午前II・午後 問題セット

正解： イ

解説：

• ア）不正解。クライアント側の検証はブラウザの開発者ツールやプロキシツールで容易に迂回できるため、サーバ側での検証が必須である。
• イ）正解。拡張子は偽装・二重化（例：shell.php.jpg）が可能であり、Content-Type ヘッダはクライアントが自由に設定できるため信頼できない。ファイル内容も先頭バイト（マジックバイト）を偽装したポリグロットファイルが存在するため、拡張子・MIMEタイプ・内容検証・保存先設定など複数の防御層を組み合わせる必要がある。
• ウ）不正解。CDNや保存先の設定によってはスクリプトとして実行されてしまう構成もあり得るため、「CDNに保存すれば絶対安全」とは言えない（実行権限の設定・Content-Typeの強制指定等の対策が別途必要）。
• エ）不正解。閲覧経路がなくても、アップロードされた悪意あるファイルが後続のバッチ処理やライブラリ（画像処理ライブラリの脆弱性等）で解析される際に悪用される可能性がある。

正解： ア

解説：

• ア）正解。二重拡張子攻撃は、拡張子検証ロジックの不備（最後の拡張子だけを見る／最初の拡張子だけを見る等）や、サーバ設定（Apacheの AddHandler 設定で .php.jpg のようなファイルも .php として実行されてしまう等）を悪用し、検証を迂回してスクリプトを実行させる古典的だが依然有効な攻撃手法である。
• イ）不正解。Webシェルとは、アップロードに成功した悪意あるスクリプトファイル自体を指し、これにアクセスすることで攻撃者がリモートからOSコマンド実行等を行うための「裏口」となるものである。ウイルス対策ソフトのシグネチャ埋め込みとは異なる概念。
• ウ）不正解。Webシェルが実行可能な状態でアップロードされると、リモートコード実行（RCE）に直結する重大な脅威となる。ディスク容量枯渇によるDoSは可能性の一つに過ぎない。
• エ）不正解。Content-Typeヘッダはクライアントが自由に設定可能であり、単独の検証手段としては不十分。拡張子検証・ファイル内容（マジックバイト）検証・保存先の実行権限制御など多層的な対策が必要である。

正解例：

• (1) 検証ロジックの不備：拡張子の末尾一致のみを確認しており、ファイル内容やMIMEタイプを検証していない（38字）。
• (2) サーバ設定・保存先の不備：アップロード先ディレクトリでスクリプト実行が許可されており、.php を含むファイル名も実行対象となる設定だった（46字）。

解説： 本事例は「入力検証（アプリケーション層）」と「実行環境設定（インフラ層）」という2つの防御層がいずれも機能していなかった典型例である。拡張子の末尾一致という緩い検証は二重拡張子攻撃を防げず、加えてアップロード先ディレクトリでスクリプト実行が許可されていたため、たとえ検証を通過してしまったファイルであっても実行には至らない設計（多層防御）が欠けていた点が問題である。

解説・採点基準（計15点）：

正解例：

• 入力検証：拡張子だけでなく、ファイル内容の先頭バイト列（マジックバイト）を検査して実際のファイル形式を判定し、画像であればさらに画像処理ライブラリで再エンコード（無害化）することで悪意あるコードの混入を排除する。
• 保存方式：アップロードされたファイル名をそのまま使わず、サーバ側でランダムな一意のファイル名（UUID等）に変更して保存し、拡張子も検証済みの許可リストの値に固定し直す。
• 実行環境設定：アップロードディレクトリをWebサーバの公開領域（Webルート）外に配置する、またはやむを得ず公開領域内に置く場合はそのディレクトリでのスクリプト実行を明示的に無効化する設定（例：.htaccess でのハンドラ無効化や、実行権限のないストレージ・別ドメインでの配信）を行う。

解説： ファイルアップロード対策のベストプラクティスは「検証・命名・実行制御」の3層防御に集約される。特に「アップロードされたファイルは実行可能な場所に置かない」という原則が最も効果的であり、加えて画像の再エンコードによる無害化やファイル名のランダム化を組み合わせることで、検証をすり抜けたファイルがあってもRCEに直結しないようにする多層防御が重要である。

解説・採点基準（計15点）：