127.0.0.1 を介した通信は、単なる別の IPC メカニズムと考えることができますが、既存のプロトコルを再利用するものです。共有メモリや UNIX ドメイン ソケットまたはパイプと同様に、これは 2 つのプロセスが 1 つのシステムで通信できる無数の方法の 1 つです。システム上のプロセスが侵害されていないと信頼できる場合は、127.0.0.1 を経由する接続を「盲目的に」信頼できます。
TCP ソケットの反対側の IP アドレスが 127.0.0.1 であることがわかっている場合は、システム管理者がこの特定の接続をリダイレクトするようにファイアウォールを構成しているか、TCP ソケットの反対側で実行中のプロセスであることが保証されます。同じマシン。したがって、サーバー マシン全体を信頼する場合は、127.0.0.1 を信頼できます。ただし、多層防御のために、TCP ソケットを使用しないことには利点があります。
localhost チェックの実装方法には注意が必要です。たとえば、デフォルトで IPv6 を使用するライブラリのバージョンに切り替えるか、何らかの形式の転送プロキシをミックスに追加して、異なるマシンまたはコンテナー上の 2 つのサービス。プロキシの使用を開始する場合は、適切な場所で確認するように注意してください。そしてもちろん、危険な可能性のあるものを同じマシンでホストしないようにする必要があります (ただし、VM とコンテナーの時代にホストする必要はありません)。
同じマシンと話していることを知っていても、some 同じマシン上のプロセスは、接続の反対側にあります。それが正しいプロセスだとは言いません。通常の操作では、おそらく両方のプロセスが実行されています。しかし、サービス拒否攻撃によりメモリ不足になった後に 1 つのプロセスがクラッシュするなど、何か問題が発生した場合、ポートは別のプロセスがリッスンできるように解放されます。また、任意のローカル プロセスが実行中のサーバーにいつでも接続できます。これには、攻撃者が何らかのプロセスをローカルで実行できる必要がありますが、そうでなければ多くのことを実行できない特権のないプロセスである可能性があります。したがって、127.0.0.1 に依存することは脆弱性ではありませんが、権限昇格の可能性があります。
代わりに Unix ソケットを使用できます。 Unix ソケットと TCP ソケットは、接続またはリッスンするアドレスを指定する以外は同じように機能するため、多くのコード変更は必要ありません。 Unix ソケットはパーミッションを持つか、親スーパーバイザーによって作成される可能性があり、それ以外には何も接続できません。 Unix ソケットを使用すると、ソケットの反対側にあるものが同じマシンで実行されているだけでなく、それが予期されたプロセスであることが保証されます。これは、同じマシン上で実行されている何かの違反ではなく、オーセンティケータ サービスまたはメイン サービスのセキュリティ違反に対して脆弱になるだけです。