認証後静的ファイルの未認証到達性とは？ログインを通らず見られる仕組み・対策・診断基準

認証後静的ファイルの未認証到達性とは

認証後静的ファイルの未認証到達性とは、ログイン画面を通った後に表示するはずの静的ファイル（.html・.htm・.txt・.csv）が、ログインせずに URL を直接指定するだけで取得できてしまうかどうか、という問題です。

「パスワードを入力すると member/top.html に移動する」「JavaScript で合言葉を確認して data.csv を表示する」といった作りでは、移動先のファイル自体は、Web サーバーが誰にでも返す普通の静的ファイルです。URL を直接入力すれば、ログイン画面を通らずに中身を取得できます。

セキュリティAIチェッカーのこの項目は、パスワード欄のあるページから遷移先・送信先になっている静的ファイルや、会員・管理系のパスにある静的ファイルを、Cookie なしで直接要求し、内容が返ってくるかを確認します。

HTML の兆候から「認証後コンテンツを静的ファイルで直接配信していない」が構成を推定するのに対し、この項目は実際にそのファイルへ到達できるかを確かめます。

なぜ静的ファイルはログイン画面で保護されないのか

Web サーバーは静的ファイルをそのまま返す

Web サーバーは、.html や .csv を要求されると、設定で制限していない限りそのまま返します。ログイン画面の JavaScript がパスワードを確認しても、それは利用者のブラウザ内での処理で、サーバーへの直接要求には何の影響もありません。CWE-602 は、サーバー側で行うべきセキュリティ制御をクライアント側に任せる弱点として、この型を説明しています。

典型的な誤実装

<script>
// 誤り: パスワードがソースに見え、遷移先は直接開ける
function check() {
  if (document.getElementById('pw').value === 'kaiin2024') {
    sessionStorage.setItem('auth', 'ok');
    location.href = 'member/top.html';
  }
}
</script>

<!-- member/top.html 側の誤ったガード: JS を無効にすれば、または curl なら素通り -->
<script>if (sessionStorage.getItem('auth') !== 'ok') location.href = '../login.html';</script>

2つ目のガードは、HTML の本文がすでにブラウザへ届いた後に動くため、本文は取得済みです。「見せないようにしている」だけで、「渡さないようにしている」わけではありません。

正しい構成

• 保護したいデータは Web 公開ディレクトリの外に置き、認証チェックをするプログラム（PHP 等）が読み出して返す。
• または、Web サーバー自体の認証（Basic 認証、SSO 連携のリバースプロキシ等）でディレクトリごと保護する。

認証後静的ファイルについてよくある誤解

• 「ファイル名を推測しにくくすれば安全」：URL はブラウザ履歴、Referer、アクセスログ、メール転送、検索エンジンのクロールで漏れます。ログイン画面の JS に遷移先が書かれていれば、ソース表示で即座に分かります。
• 「robots.txt で検索除外したから大丈夫」：robots.txt は公開ファイルで、隠したいパスの一覧を攻撃者に教えることになります。

認証後静的ファイルの未認証到達性の診断基準（セキュリティAIチェッカー）

候補の抽出（追加の通信なし）

トップページと、巡回した最大2ページの HTML を材料にします。

1. 認証の兆候があるページ を選びます。type="password" の input 要素を含むページ、または sessionStorage/localStorage の getItem/setItem で auth・token・session・login・user を含むキーを扱うページです。「ログイン」「認証」という単語だけでは兆候とみなしません（「認証保育所」「ISMS 認証」など、自治体サイトに頻出する語での誤検知を避けるため）。
2. 1 のうち パスワード欄のあるページ について、ページ内の location = "…"・location.href = "…"・location.assign("…")・location.replace("…") の遷移先と、パスワード欄を含むフォーム（form の開始タグから最初の終了タグまで）の action のうち、同一オリジンで拡張子が .html/.htm/.txt/.csv のものを候補にします。パスワード欄のあるページ自身の URL は除きます。
3. 加えて、取得したページの HTML や巡回結果から得た同一オリジンの URL のうち、パスに member・members・mypage・my-page・private・secure・protected・staff・internal・admin・dashboard で始まるディレクトリ名／ファイル名（直後が /・.・_・-・末尾）を含む .html/.htm/.txt/.csv を候補にします。
4. 1 の兆候ページが無い場合、または 2・3 の候補が無い場合は対象外（na）です。候補は重複を除き、2 を優先して最大2件です。Web Storage の兆候だけでパスワード欄の無いページは、1 の兆候にはなりますが、2 の抽出元にはなりません。

確認方法と判定条件

候補へ Cookie・Referer なしで GET を送ります（リダイレクトは追跡しない、タイムアウト5秒）。180KB を超える応答は、先頭部分だけで判定します。

証拠欄には「n/m 件が Cookie なしで内容を返しました」と件数だけを表示し、取得した内容は表示しません。

自治体サイトでの判定例

判定の限界

公開ページからリンクやスクリプトで参照されていない保護ファイルは発見できません。ログイン後のメニューに並ぶファイルは、手動で一覧化して同じ確認を行ってください。

認証後静的ファイルに未認証で到達できるとどんなリスクがあるか

• 個人情報・内部資料の流出：会員名簿、利用者一覧 CSV、議事録案、マニュアル等を URL の直接指定で取得されます。
• パスワードの露出：クライアント側でパスワードを照合する実装では、HTML/JS のソースにパスワード（またはそのハッシュ）が含まれていることが多く、総当たりも容易です。
• 検索エンジンへの掲載：どこかにリンクされた保護ファイルがクロールされ、検索結果に表示されることがあります。
• 気づきにくさ：アクセスログ上は通常の GET と区別がつかず、流出に気づくのが遅れます。
• CWE-425（強制ブラウジング：認証画面を経由せず URL を直接要求する）として古くから知られる型で、OWASP WSTG-ATHN-04 の目的「認証を必要とするすべてのサービスに認証が適用されていること」の確認対象そのものです。

流出シナリオの例（地域団体の会員名簿）

1. 地域団体向けのページで、合言葉を入れると JavaScript が kaiin/meibo.html へ移動する作りになっている。
2. 第三者がページのソースを表示し、合言葉と移動先の URL を見つける。合言葉を知らなくても、移動先の URL さえ分かれば十分である。
3. 第三者が kaiin/meibo.html を直接開くと、Web サーバーは名簿をそのまま返す。
4. アクセスログには通常の閲覧と同じ GET が残るだけで、担当者は流出に気づかない。

名簿を公開ディレクトリの外へ移し、セッションを確認する配信スクリプト経由にしていれば、手順3の要求は 403 や 404 になります。

認証後静的ファイルを保護する方法（PHP・Apache・nginx・IIS・Next.js）

基本方針

1. 保護対象のファイルを Web 公開ディレクトリ（DocumentRoot）の外へ移動する。
2. サーバー側セッションを検証するプログラム経由でのみ返す。
3. 旧 URL は 404（または 410）にし、内容を返さない。

PHP（配信スクリプト）

<?php
// download.php?f=meibo.csv
session_start();
if (empty($_SESSION['user_id'])) { http_response_code(403); exit; }
$name = $_GET['f'] ?? '';
if (!preg_match('/\A[a-z0-9_-]{1,64}\.(?:csv|txt|html)\z/', $name)) { http_response_code(400); exit; }
$base = realpath(__DIR__ . '/../private_data');      // 公開ディレクトリ外
$path = realpath($base . '/' . $name);
if ($path === false || strpos($path, $base . DIRECTORY_SEPARATOR) !== 0) { http_response_code(404); exit; }
header('Cache-Control: no-store');
header('X-Content-Type-Options: nosniff');
header('Content-Disposition: attachment; filename="' . $name . '"');
readfile($path);

ファイル名は、ホワイトリストの正規表現と realpath の両方で検証し、ディレクトリ・トラバーサルを防ぎます。

Apache（暫定措置）

移行が終わるまで、旧ディレクトリを全拒否します。

# /member/.htaccess
Require all denied

または、Web サーバーの認証で保護します（AuthType Basic と Require valid-user、パスワードファイルは公開ディレクトリの外に置く）。

nginx

location /member/ { internal; }   # 外部からの直接要求は 404
# アプリが認証後に X-Accel-Redirect: /member/xxx.csv を返したときだけ配信

IIS

web.config の requestFiltering → hiddenSegments に <add segment="member" /> を追加して直接要求を 404 にし、ASP.NET 等の認証付きハンドラーから配信します。

Next.js

保護ファイルを public/ に置かないでください。public/ 配下は認証なしで配信されます。サーバー側の Route Handler でセッションを確認してから読み出して返します。

設定後の確認方法

curl -s -o /dev/null -w "%{http_code} %{size_download}\n" https://www.city.example.lg.jp/kaiin/meibo.html
# 期待: 403 / 404 / 302（ログイン画面へ）

ログイン画面のソースに残っている遷移先の URL や、ブラウザ履歴にある URL を一覧化し、すべて確認してください。

サイトを壊さないための注意点（ガードレール）

• 移動する前にファイルのバックアップを取り、外部から参照されているリンク（他課のページ、PDF 内のリンク）を洗い出します。
• 既に流出した可能性がある場合は、アクセスログで該当 URL への外部からの 200 応答を確認し、個人情報が含まれていれば組織の手順に従って報告します。
• クライアント側に書かれていたパスワードは、漏えいしたものとして変更してください。

よくある質問（FAQ）

参考資料

• OWASP ASVS 5.0.0 V8 Authorization
• OWASP WSTG-ATHN-04 Testing for Bypassing Authentication Schema
• OWASP WSTG-ATHZ-02 Testing for Bypassing Authorization Schema
• CWE-425 Direct Request ('Forced Browsing')
• CWE-602 Client-Side Enforcement of Server-Side Security
• nginx「internal」ディレクティブ（ngx_http_core_module）
• IPA「安全なウェブサイトの作り方」

「認証後静的ファイルの未認証到達性」と関連する診断項目

• 認証後コンテンツを静的ファイルで直接配信していないcritical
• クライアント保存値を認証判定に使っていないcritical
• Cookie・Referer偽装でアクセス範囲が増えないcritical
• Refererをアクセス制御に使っていないcritical
• 未認証APIの情報露出兆候high
• OAuth/OIDCの非推奨フロー兆候high