うーん...ここでうまくいかないことがたくさんあります...
1 つには、SSL サーバー証明書は、通常の盗聴からのみ保護し、正しく行われた場合はサーバーの ID を保護します。クライアントが誰であるかは保証されません。（クライアントのサーバー証明書で適切なセキュリティチェックを行っていると仮定しています）。
しかし、それはサーバーにクライアントについて何も伝えません。そのためには、クライアント証明書を割り当ててサーバー上で検証する必要があります。それでも、このソリューションは、正しく行われないと中間者攻撃に対して脆弱です。
構成に戻ります。サーバー証明書の検証が正しく行われていない場合、誰かが盗聴するだけでなく、通信チャネルの情報を挿入/変更することもできます (メッセージ自体に署名を実行して、変更されていないことを確認していないため)。
ほとんどの機関は外部アクセス用にNATまたはプロキシ構成を使用しているため、IP フィルターはかなり弱いものです。したがって、同じノードを介した外部アクセスを持つ PC は、同じ IP を示します。したがって、「スプーフィング」は必要ありません...内部マシンのいずれかを侵害する必要があるだけです...秘書のマシンのように（笑い）...そこからリクエストを行います。
IP スプーフィングが有効な攻撃かどうかはわかりません。この場合、攻撃者はクライアント マシンでサービス拒否を引き起こし、サーバーに接続してパケットを偽造し、スプーフィングされたクライアントが応答できないことを利用して最初に攻撃します。接続を終了するためのパケット。
これは、パッケージのシーケンス番号を推測することを意味します。これは今日では困難ですが、不可能ではありません。そこから、攻撃者は必要なメッセージをやみくもに注入できますが、この場合、接続はプレーンな html ではなく、キーなどの情報の交換を伴う ssl ストリームであるため、注入がやみくもに行われるため、攻撃者は見ることができません (少なくとも、同じサブネット内にあり、パケットを盗聴できない限り）...その可能性は疑わしいです。
とにかく...推奨構成。
1 - クライアントで検証されたサーバー SSL 証明書。- サーバーで検証されたクライアント SSL 証明書。- GUIDトークンに加えて、メッセージのある種のチェックサム..セッションクライアントごとに毎回生成することをお勧めします。(この証明書を暗号化されたストア pkcs12 などに安全に配布することを忘れないでください。そうしないと、このアプローチは中間者攻撃の影響を受けやすくなります)
2 - Web サービスの SOAP メッセージを WS-Security で拡張し、クライアントとサーバーの証明書でクライアントとサーバーの署名/暗号化を使用し、タイムスタンプ サービスを使用します。
接続をIPバインドすることはできます...しかし、必要はありません...そしてまだ弱いです。
余談ですが、 1994 年にケビン・ミトニックが下村に対して IP スプーフィングを使用しました。サーバーの OS のバージョンによっては、ほとんどのプロセスを自動化するツールが既に存在するに違いありません。
他の人の考えを聞くのが大好きです。お役に立てれば。