web-dev-qa-db-ja.com

ブラウザーの作成者が127.0.0.1/localhostでホストされているWebページでリファラーをスキップしないのはなぜですか?

長い間、127.0.0.1/localhostでホストされているWebページ、つまり次のようなURLを使用していると確信していました。

http://127.0.0.1/MySecretControlPanel/sensitive.php?stuff=goes&here=dude

...のハイパーリンクをクリックしても、「HTTPリファラー」ヘッダーは送信されませんでした。

しかし、そうです!つまり、邪魔にならないようにしてこれを理解し、特別なヘッダーを積極的に追加する場合を除きます。

<meta name="referrer" content="no-referrer">

つまり、コントロールパネルのリンクをたどってアクセスしたすべてのいまいましいサイトには、長い間、プライベートな機密URLが表示されていました。

たくさんのリンクをクリックしました。多くの場合、簡単に確認できるショートカットがあります。これらのサイトはすべて私のURLを見ることができました。ローカルホストでホストされていたとしても。

繰り返しになりますが、ブラウザの作成者がそのようなWebサイトのヘッダーをスキップする基本的な正気を持っていると確信していました。結局のところ、デフォルトではプロキシの127.0.0.1/localhostを明示的にスキップするため、私の考えではこれは当然のことでした。しかし、それは与えられたものではありませんでした。全く行われませんでした。

今、世界中の多くのサイトが理論的に私が自分のサイトで見たものを正確に理解することができます(私のアプリケーションの名前、したがって/の後のURLは非常に一意であるため)tons私が入力した機密性の高い「検索クエリ」の種類のデータは、プライベートで安全だと思って入力しました。

なぜ彼らがこの決定をしたのかと思うだけです。 「リファラー」の概念全体は、少なくとも、ホスト名よりも多くのものが含まれている場合、最初は悪いです。少なくとも「127.0.0.1」しか見られなかったとしても、それほど悪くはありません。

そして、私は「チェックすべきだった」と私に言うのを助けません。私はそうすべきだったことを知っています。私がこれを「すべき」だったことを知るように、それが手遅れになった後でも、テストする必要がないもののように見えたので、テストすることを考えたことはありません。

1
Solace

ブラウザの作者はHTTPプロトコルに従っているので、ブラウザの作者を責めないでください。 RFC 7231、5.5.2Refererヘッダーの指定はプライバシーの問題を認識していますが、安全でないHTTPSチャネルの安全なHTTPSページのURLの送信のみを禁止しています。

リファラーフィールドは、ユーザーのリクエストコンテキストまたは閲覧履歴に関する情報を明らかにする可能性があります。これは、参照リソースの識別子が個人情報(アカウント名など)または機密であるはずのリソース(リソースなど)を明らかにした場合のプライバシーの問題です。ファイアウォールの内側や安全なサービスの内部など)。参照リソースがローカルの「ファイル」または「データ」URIの場合、ほとんどの汎用ユーザーエージェントは、Refererヘッダーフィールドを送信しません。安全なプロトコルで参照ページを受信した場合、ユーザーエージェントは、安全でないHTTPリクエストでRefererヘッダーフィールドを送信してはなりません(MUST NOT)。セキュリティに関するその他の考慮事項については、 セクション9.4 を参照してください。

rl内のクエリ文字列による情報漏えい のため、URLに機密データを配置しないでください。 Refererヘッダーは、この情報をリークする唯一の方法ではありません。

  • リファラーヘッダー
  • ウェブログ
  • 共有システム
  • ブラウザの履歴
  • ブラウザキャッシュ
  • ショルダーサーフィン
4
Esa Jokinen