【ITニュース解説】A 200 OK response does not prove a secret leak

ウェブサイトのセキュリティを検査する際、セキュリティスキャナーというツールが、機密情報が格納されている可能性のあるパスへアクセスを試みることがある。例えば、パスワードやAPIキーなどの重要な情報が設定ファイルとして置かれている場所などだ。もし、そのリクエストに対してサーバーが「200 OK」という応答を返した場合、それは一見すると、求めていた情報がそのまま公開されているかのように見えるかもしれない。しかし、この「200 OK」というステータスコードは、サーバーがリクエストを受け付け、正常に何らかのコンテンツ（ボディ）を返したことだけを意味しており、そのコンテンツの中に機密情報が含まれているかどうかについては何も語っていない。これは、セキュリティ検証において非常に重要なポイントだ。

多くのウェブサイト、特に「シングルページアプリケーション（SPA）」と呼ばれる形態のウェブサイトでは、ユーザーがどんなURLにアクセスしたとしても、常に同じ基本的なHTMLの骨格（シェル）を返すように設計されている。これは、ブラウザ側でJavaScriptが動作して初めてコンテンツが動的に生成されるためだ。そのため、もしセキュリティスキャナーが架空のパスや、存在しないはずのパスにアクセスしたとしても、サーバーは「ファイルが見つかりません」というエラーではなく、単にサイトの基本的なシェルを「200 OK」で返してしまうことがある。また、ログインシステムを持つウェブサイトでは、未認証のアクセスに対して自動的にサインインページへリダイレクトしたり、そのサインインページのコンテンツを「200 OK」で返したりする場合がある。さらに、コンテンツデリバリーネットワーク（CDN）を利用している場合、CDNが独自のブランドが施されたエラーページを、なぜか「200 OK」という成功を示すステータスコードとともに提供することさえある。

このように、単に「200 OK」というステータスコードだけを根拠にして「機密情報が漏洩している」と判断することは、アクセス可能なURLと実際に公開されてはいけないファイルとを混同している可能性が高い。

では、どのようにして「200 OK」の真の意味を正確に評価すればよいだろうか。まず有効なのは、「制御リクエスト」を行うことだ。これは、疑わしいパスと同じホストに対して、意図的に存在しないと分かっているランダムなパスをリクエストするというものだ。例えば、「/nonexistent-random-path-12345」のような、通常はあり得ないURLにアクセスしてみる。そして、この制御リクエストから得られた最終的なURL、返されたコンテンツの種類（コンテンツタイプ）、ページのタイトル、そしてレスポンス全体の構造を、機密情報が含まれていると疑われるファイルへのレスポンスと比較する。

もし、疑わしいファイルへのレスポンスと、存在しないはずのパスへの制御リクエストのレスポンスが、実質的に同じページであると判断できた場合、その「200 OK」は、おそらくサーバーが未知のパスに対する「フォールバック」（代替）として、サイトの基本的なシェルや一般的なエラーページを返している可能性が高い。この比較を行うことで、全てのパスが安全であると証明できるわけではないが、少なくとも「この特定のレスポンスは機密情報漏洩の証拠としては弱い」ということを示すことができる。

次に重要なのは、単に「200 OK」で返されたコンテンツがあるという事実だけでなく、その内容が具体的に何であるかを詳しく調べることだ。具体的に期待しているファイル、例えば環境設定ファイル、リポジトリのメタデータファイル、あるいはバックアップアーカイブなどは、それぞれ固有の構造やフォーマットを持っている。例えば、環境設定ファイルであれば「KEY=VALUE」のような形式が多く見られるだろうし、リポジトリのメタデータであればバージョン情報やコミット履歴に関連する記述があるだろう。コンテンツの中に「password」のような一般的な単語が含まれているだけで「機密情報が漏洩している」と結論付けるのは早計だ。なぜなら、そうした単語は、ウェブサイトのドキュメントや普通のHTMLコンテンツの中にも頻繁に登場する可能性があるからだ。信頼できる結果を得るためには、疑われるリソースに合った固有のフォーマットを、フォールバックの制御リクエストとは明らかに異なるレスポンスの中で見つける必要がある。

機密情報漏洩の証拠が見つかったと判断した場合、その取り扱いには細心の注意が必要だ。実際に発見された機密情報、例えば生パスワードなどを、そのまま公開された問題報告システム、スクリーンショット、あるいはレポートにコピーしてはならない。これは、さらなる情報漏洩を引き起こすリスクがあるため、絶対に避けるべきだ。代わりに、発見されたパス、関連するHTTPヘッダー、そして結論を明確に説明できる範囲で、機密部分を適切に編集（匿名化または伏字化）した抜粋を記録するようにする。もし、得られたレスポンスが曖昧で、機密情報が含まれているかどうかの判断が難しい場合は、そのことを明記し、「さらに確認すべき点」を具体的に示すべきだ。そして、もしレスポンスが明らかにサイトの基本的なシェルや一般的な情報に過ぎない場合は、それを機密情報の漏洩として報告すべきではない。

この「観察と推論を区別する」というアプローチは、公開されたファイルに関する検証にとどまらず、より広範なセキュリティ検証の場面で適用できる普遍的な原則である。自動化されたセキュリティレポートは、ツールが「実際に何を観察したのか」という事実と、「その観察に基づいて何を推論したのか」という結論を明確に区別して提示する際に、最も有用なものとなる。ウェブサーバーが返した「200 OK」というステータスコードは、あくまで「観察」された事実の一つに過ぎない。しかし、「機密情報が存在する」という結論は、この単なる観察以上の、より強力で具体的な証拠に裏付けられる必要がある。セキュリティ検証を行う上で、表面的な情報だけでなく、その背後にある真実を深く掘り下げて理解する姿勢が求められる。