リファラーで追加の「パスワード」を使用してプライベートサイトを非表示にしますか？
私はexample.com/private/にプライベート（=私が唯一のユーザー）サイトを持っています。このホストでは他に何も公開されていません（私のドメインです）。
example.comには何かがあることを誰にも知られたくありません。特に私のプライベートサイトはそうではありません。
ここで、アリスがURLを「推測」してexample.com/private/にアクセスするとします。もちろん、ログインを要求することでサイトを保護しましたが、それでも、アリスにそのようなサイトがあることをまったく知らせたくなく、ログインを試してもらいたくありません。
次の方法がここで私を助けることができるかどうか私は思います：
Firefoxアドオン RefControl を使用して、特定のホストへのリクエストにのみ使用するカスタム Referer ヘッダーを設定できます。
9b2389Bqa0-ub712/bauUU-UZsi12jkna10712へのリクエストについては、Refererを（たとえば）example.comに設定します。
次に、.htaccess（正確にどのように可能であるかはわかりませんが、それは可能であるべきだと聞きました 訪問者のリファラーについては、コードレビューSEの 質問 ）を参照してください。
9b2389Bqa0-ub712/bauUU-UZsi12jkna10712の場合、特別なことは何もしません（=サイトへのアクセスは可能です）- それ以外の場合は、HTTPエラー404を送信します
404の代わりに偽のサイトが表示されると思いますが、私の場合、/private（存在する）と/foobar（存在しない→404）の違いを誰にも見られないようにしたいと思います。
これはうまくいくでしょうか？ .htaccessで可能ですか？この方法に欠陥はありますか？変更すべきことはありますか？同様の方法はありますか？
更新と説明
- ホスト全体がHTTPSを使用します。
- サーバーがあるであることを非表示にする必要はありません。コンテンツが提供されていることを非表示にしたいだけです。
「もっともらしい否認」という用語を実行してくれて@ Adnan に感謝→これ（クライアント側）が欲しい！
推測しにくいURLを使用することを提案した人（例：URLに追加された秘密の文字列）：これは確かに機能するかもしれませんが、Refererメソッドを使用すると、できない誤って秘密を明らかにします（簡単に）。 URLはHTTPヘッダーよりも見やすくなっています。誰かが画面を見ている、誤って公開されたブックマークリスト（秘密のURLが含まれていることを覚えていない）、ブラウザーの履歴、ブラウザーのアドレスバーをバックグラウンドで表示したデスクトップのスクリーンショットなど。そして、あなたは再び最初の問題を抱えています：サイトがあることを隠す方法whenアリスはURLを「推測」（または何でも）します。
一部のユーザーは、外部（さらに良いローカル）ログインページの使用を提案しました。私はその考えが好きです。 Refererメソッドと比較して（それが
.htaccessで実装できる場合、それが可能であると想定しています）、サイトのコード/ CMSを適合させる必要があるかもしれないという欠点があります。.htaccessについては、コードレビューSEの に関する質問をご覧ください@НЛОが指摘するように、カスタムヘッダーの方が適しています。私もそう思います。しかし、そのためのFirefoxアドオンはまだ見つかりませんでした（ スーパーユーザーに関する質問を参照してください ）。
私は個人的にあなたが大丈夫だと思います。基本となるログイン方法が安全である限り、必要なだけ多くの隠蔽レイヤーを追加します。
私はあなたが達成しようとしている正確なことを望んでいるいくつかのクライアントと協力してきました。私は常に次の2つの方法のいずれかを使用しています。
- クロスサイトログインフォーム：
.htmlに送信するログインフォームがあるローカルexample.com/private/login.phpファイル。ログインフォームには、ランダムに生成されたトークンを含むhiddenフィールドがありました。
もちろん、誰もが同じ.htmlファイルを配布することはできますが、私たちの主なセキュリティメソッドはログインプロセス自体だったため、それは重要ではありませんでした。ユーザー名とパスワード。
example.com/privateへのリクエストはすべて拒否され、404が訪問者に表示されました。しかし、正しいクレデンシャルを含むPOSTリクエストを受信すると、Webサイトが正常に機能していたセッションが開始されます。
この方法の利点は、 もっともらしい拒否性 が付与されることです。誰かが.htmlファイルを手に入れたら、ログインを試みても404を受け取ります。このファイルが実際に機能しているWebサイトに関連しているという証拠はありません。
- URLの追加のパスワード：メソッドとほとんど同じですが、追加の認証トークンがURLにありました。
example.com/privateへのリクエストはすべて拒否され、404が訪問者に表示されます。しかし、適切なexample.com/private/login.php?token=Zz37vQQCnLTpe527xeFfFEG9を受信すると、ログインフォームが表示されます。
彼らはそのURLをブックマークすることができたので、ほとんどのクライアントはこの方法を好んだ。ただし、この方法の欠点は、もっともらしい否認を許可しないことです。 URLを知っている人なら誰でも、そのWebサイトにログインフォームが機能していることを証明できます。
正直なところ、あなたの方法が好きで、いつかは使うかもしれないと思います。
重要：上記のすべてが適用されるのは、後ログイン方法が安全であることを確認した後です。
この方法は、機能的には2つのパスワードを使用した認証を要求するのと同等であり、Refererはそのうちの1つです。より一般的なバリエーションは、秘密のURLを使用することです。つまり、「特別な文字列」をプライベートサイトへのパスの一部にします。 URLに秘密の文字列を含めると、考えなければならない追加の詳細情報が含まれる可能性があります（たとえば、ユーザーはブックマークを付けることができます。つまり、文字列はユーザーのマシンのそれほど隠されていないファイルに書き込まれます）。ブックマークして、Firefox-with-an-extensionだけでなく、あらゆる種類のブラウザと互換性があるようにします。 usabilityの場合、URL自体の秘密の文字列の方が良いトレードオフであると思う傾向がありますが、それはあなたの呼び出しです。
完全なサイトでHTTPSを使用していることを願っています。実際、パブリックサイトとプライベートサイトの両方にプレーンHTTPを使用している場合、パッシブ盗聴者がプライベートサイトとの通信を監視し、パスワードとすべての秘密を明らかにする可能性があります。これは悪いです。
プライベートサイトだけにHTTPSを使用している場合、ポート443でリッスンするサーバーを持っていると、攻撃者はそれを非常にはっきりと見ることができます（接続試行と同じくらい簡単です）その上）。メインのパブリックサイトがHTTPのみである場合、攻撃者はプライベートサイトがあることをすぐに理解します（SSLサーバー証明書を購入してセットアップするという面倒なことはありません）。プライベートサイトを検出されないようにしたい場合は、パブリックサイトにもHTTPSを使用する必要があります（一部の人々 推奨 一般的に、さまざまな理由で、技術的なものすべてではありません）。
RefControl拡張機能の正確な動作についてはわかりませんが、特別なReferer文字列が[〜＃〜] httpsにのみ送信されることを確認する必要があります[〜＃〜]サイトのバージョン。[〜＃〜] http [〜＃〜]（存在する場合）ではありません。ここでも、URLの秘密の文字列を使用すると、個人的には安全だと感じるでしょう。少なくともいつ送信されるか、いつ送信されないかはわかっているからです。
特別なURLが要求されない限り、example.comにWebサーバーがあることを誰かに知られたくない場合は、IPファイアウォールレベルでルールとしてそれを実装する必要があります。ポート80に到着するSYNパケットを探し、ペイロードを調べて、許可されたURLに対する有効なHTTPリクエストであることを確認する必要があります。そうでない場合は、パケットをドロップします。
それ以外の場合、間違ったURLの要求がサーバーに届くと、サーバーはTCP接続を確立して（そして404で応答する）ことで、その存在を通知します。
Linuxを使用している場合は、iptables文字列モジュールを使用してこのようなことを行うことができます。
はい、大丈夫です。パスワード層が安全である限り、不明瞭な層をさらに追加すると役立ちます。
他のいくつかのトリック（ミックスアンドマッチ）：
- ログインページにAJAX POSTリクエストを介してのみアクセスできるようにします（ログインするには、JSでPOSTリクエストを作成しますコンソール）
- 最後の1分間に
example.com/trigger?pwd=abcd（404ページでもある）にアクセスした場合にのみ機能します。 - URLを日付と時刻の関数にします。 JSコンソールで計算するのは簡単ですが、推測が難しいもの
あなたがサイトをデザインしたと仮定すると、最良のことは常にページの最初に "/ private /"が参照する節を追加することです。この句は、user.authenticated = trueのようになります。次に、「ページをロード」します。それ以外の場合は、「エラー404」
私のラベルは非常に一般的です
User.authenticatedステートメントはページの言語によって変わる可能性がありますが、アリスがすでにログインしているかどうかを確認します。アリスがまだログインしていない場合、エラー404を受け取り、手動でexample.com/home.phpにアクセスするかログインする必要があります。 aspxまたはログインページが呼び出されるもの。
1つの解決策：ディレクトリのインデックス作成をオフにし、コンテンツを「example.com/9b2389Bqa0-ub712-bauUU-UZsi12jkna10712」の下に配置します。この特別なURLをブックマークします。総当たり攻撃を試みる攻撃者は、ほとんどの場合、本物のHTTP 404エラーを受け取ります。ソリューションでは、攻撃者はタイミング分析を実行し、「/ private」からの404が「/ nosuchpage」の404よりも遅いことに気づく場合があります。私が提案するソリューションでは、404応答は1種類だけです。
欠点：醜いURL。私が考えることができる他の欠点がありますが、それらはあなたのスキームにも存在します。
攻撃者が何にアクセスしようとしても「HTTP 401 Unauthorized」応答を受け取った場合、そのサイトに「何か」があることを攻撃者が発見したと見なされますか？攻撃者は、そのドメインが登録されており、そのホスト名でWebサーバーが実行されていることをすでに知っています。
このソリューションがあなたに合っている場合は、 http://httpd.Apache.org/docs/2.4/howto/auth.html を使用してください
欠点：「サイトが空です。自分で確認してください」と主張することはできません。あなたがそれを必要とするならば、あなたは面白いビジネスにいます。 :-)
この単純なPHPコード（index.phpファイルを作成する）を使用できます）：
<?php
if (isset($_GET['passkey']) && $_GET['passkey'] == '9b2389Bqa0-ub712/bauUU-UZsi12jkna10712') {
?>
... your html page ...
<?php
} else {
header("HTTP/1.0 404 Not Found");
}
?>
あなたのサイトにアクセスしたい場合は、単純に「www.example.com/?passkey=9b2389Bqa0-ub712/bauUU-UZsi12jkna10712」というURLを開いてください。
この場合、そのURLでWebサーバーが処理するのはBasic-Authリクエストのみにしたいのです。したがって、アリスが推測しようとすると、example.com/privateで404を取得しますが、URLを知っているので、認証ヘッダーを直接送信できます（つまり）。
承認：基本的なQWxhZGRpbjpvcGVuIHNlc2FtZQ ==
example.com/privateでのリクエストと一緒に受け入れられ、処理されます