拡張子はただの名札なのか

🎬 アニメーション『ダブルクリックの3秒』の ② のところです！

上級では「名札を信じない」立場から、種別を確かめる3系統を精密にします。

1. 拡張子 — ファイル名の末尾。送り手が自由に付けられる自己申告で、証拠能力はない
2. マジックナンバー※1 — ファイル先頭の固定バイト列。形式の仕様が定めた署名で、中身に埋まっている物証
3. MIMEタイプ※2 — 「型/サブ型」の正式名。通信（HTTPのContent-Typeヘッダ）やアプリ間で形式を伝える宣言

種別を厳密に判定したいプログラムは、名札ではなく先頭バイトを読む。UNIX系の file コマンドや、サーバのアップロード検証がこれです。拡張子・マジックナンバー・MIMEタイプは互いに独立しており、一致する保証はない——その隙間こそが、後で見る偽装の余地になります。

登場人物メモ（※の説明）:

• ※1 マジックナンバー（ファイルシグネチャ） — PNGは 89 50 4E 47、ZIPは 50 4B、PDFは ％PDF、ELF実行形式は 7F 45 4C 46 など、形式ごとに決まった先頭バイト列。中身側の物証
• ※2 MIMEタイプ（メディアタイプ） — image/png text/html のような「大分類/小分類」表記。名前の由来はメール（Multipurpose Internet Mail Extensions）だが、今はWeb全体の標準

⚠️ イレギュラー（3つの証言が食い違うとき）:

• 署名を持たない形式 — プレーンテキストやCSVには決まった先頭署名がない。中身推測に頼るしかなく、判定が曖昧になる
• 署名を偽装したファイル — 先頭に本物の署名を貼り付けつつ、後続に別の中身を仕込むこともできる。署名の一致は「入口の一致」であって、全体の安全ではない

中身が結局すべて0と1であることは 2進数とデータ を参照。

🎬 アニメーション『ダブルクリックの3秒』の ③〜④ のところです！

「拡張子→アプリ」の対応表を、OSは具体的にどこに持っているか。機構はOSごとに違います。

1. Windows — レジストリ（設定を集約した階層データベース）に「拡張子→ファイルタイプ→開くアプリ」を記録する。.pdf の担当変更は、この階層の書き換え
2. Linux — xdg-mime の仕組み。拡張子や中身からMIMEタイプを求め、mimeapps.list で「このMIMEタイプ→この既定アプリ」を引く。拡張子を直接ではなく、いったんMIMEタイプを介すのが特徴
3. macOS — かつてのUTI※1（形式の抽象的な型）とLaunchServices※2 が、拡張子・種別・担当アプリを対応づける
4. どのOSでも、コマンドラインや「プログラムから開く」は表を経由せず、任意のアプリに任意のファイルを渡せる

共通する構図は「関連付けはファイルではなくOSのローカル設定」。だから同じ拡張子でも人のPCで担当アプリが違い、世界共通の一元データベースは存在しません。

登場人物メモ（※の説明）:

• ※1 UTI — Uniform Type Identifier。macOSが使う「形式の型」の識別子。拡張子やMIMEタイプを一段抽象化したもの
• ※2 LaunchServices — macOSで「どの種別をどのアプリが開くか」を管理する仕組み

⚠️ イレギュラー（関連付けまわりの事故）:

• 既定アプリの乗っ取り — インストール時に関連付けを一斉に自分へ向けるお行儀の悪いソフトがある。急に開くアプリが変わったらここを疑う
• MIMEと拡張子のズレ（Linux／Web） — MIMEタイプを軸にする機構では、拡張子と中身から求めたMIMEタイプが食い違うと、意図しないアプリが選ばれることがある

OSがアプリを起動して橋渡しする流れは アプリとOS を参照。

🎬 アニメーション『ダブルクリックの3秒』の ⑤〜⑦ のところです！

担当が中身を読む段でも、「宣言（拡張子・ヘッダ）」と「物証（中身）」のどちらを信じるかで挙動が変わります。

1. きちんとしたアプリは、まず中身の署名や構造を検証してから解読する（宣言を鵜呑みにしない）
2. Webのブラウザは原則、配信側が宣言したMIMEタイプに従って扱いを決める
3. ただし宣言が曖昧・欠落のとき、ブラウザが中身から種別を推測するMIMEスニッフィング※1 が働くことがある
4. スニッフィングは便利だが、「テキストのふりをしたスクリプト」を実行扱いにしてしまう危険があり、推測を禁じる宣言（X-Content-Type-Options の nosniff）で無効化できる

つまり「中身を見破る」には二つの態度がある——宣言を信じて速くするか、中身を検証して安全にするか。上級のシステム設計は、この綱引きの上に立っています。

登場人物メモ（※の説明）:

• ※1 MIMEスニッフィング — 宣言されたMIMEタイプが曖昧なとき、ブラウザが中身の先頭を覗いて種別を推測する機能。利便と危険の両面を持つ

⚠️ イレギュラー（解読の判断ミス）:

• 推測の悪用 — 攻撃者は「無害な型に見せかけつつ、ブラウザに危険な型と推測させる」ことを狙う。nosniff はこの推測経路を塞ぐ防御
• 宣言と中身の不一致 — 宣言は image/png なのに中身がHTML、のようなファイルは、検証するシステムでは弾かれ、検証しないシステムでは侵入口になる

ここが上級の核心です。拡張子は「実行するか/どう扱うか」の判断に効くのに、中身を保証しない——この非対称が攻撃に使われます。手口は「表示と実体のズレ」を突くのが共通点です。

1. 二重拡張子 — 「請求書.pdf.exe」。効くのは最後の .exe だけで、正体はPDFを装った実行プログラム。OSの既定が拡張子非表示だと「請求書.pdf」に見え、成立してしまう
2. RLO（右書き制御文字）※1 — ファイル名に見えない制御文字を1つ挟むと、そこから先の表示の向きだけが反転する。目には .pdf などに見えるのに、OSが扱う実際の拡張子は末尾の実行形式のまま
3. 紛らわしい名前 — 「写真.jpg     .exe」のように空白を大量に入れ、末尾の実体を画面外へ追いやる古典手口
4. いずれも中身も関連付けも変えていない。変えたのは「人間の目に映る名札」だけ——だから対策も「拡張子を常に表示する」「中身で判定する」に行き着く

登場人物メモ（※の説明）:

• ※1 RLO — Right-to-Left Override（U+202E）。「以降を右から左へ表示せよ」という制御文字。アラビア語などの表示用だが、拡張子偽装に悪用される

⚠️ イレギュラー（偽装を見抜くには）:

• 拡張子を常に表示する設定にする — 二重拡張子・空白詰めはこれだけで大半が見える
• 中身（マジックナンバー）で判定する — file コマンドや検証付きのシステムは、名札を無視して物証を見るので偽装に強い
• 未知のファイルは隔離環境で扱う — 名札の真偽に関係なく、危険な中身は実行させない構え（サンドボックス）が最後の砦

こうした手口の全体像は 攻撃の種類 と マルウェア を参照。

• 拡張子を検証と取り違える — 拡張子チェックは「宣言の確認」であって「中身の検証」ではない。アップロード受け入れはマジックナンバーと構造で確かめる
• 署名さえ合えば安全という誤解 — 先頭署名の一致は入口の一致にすぎない。後続に危険な中身を仕込む余地は残る
• MIMEスニッフィングを無防備に放置 — 宣言を曖昧にしたまま配信すると、ブラウザの推測が攻撃経路になる。nosniff と正確なMIMEタイプ宣言で塞ぐ
• 拡張子非表示のまま運用 — 二重拡張子・RLO・空白詰めは、非表示設定が成立条件。表示に切り替えるだけで多くが露見する
• 関連付けを世界共通と思い込む — 対応表はOSのローカル設定。自分のPCで安全に開けたことは、他人の環境の安全を意味しない