方法は知りたくない...どれだけ複雑なのか....
発信者の着信クライアント IP アドレスに基づいて、1 つまたは 2 つの Web サービスを保護することを考えています。これは何らかの形で安全ですか？
確かに、IP アドレスがスプーフィングされていた場合、結果はスプーフィングされていたアドレスに送り返されなければならないため、スプーファーには到達しませんか?
更新:わかりましたので、私が言えることは....IPアドレスをチェックし、暗号的に重要なトークンをタイムアウト付きで有効なIPアドレスに渡すGettoken()メソッドを作成する必要があります。これは、あらゆる種類の副作用が許可される前に、他のメソッドで必要になります。
攻撃者は有効な IP を持っていないと (おそらく) トークンを取得できないため、私の「危険な」Web メソッドを有効に呼び出すことはできませんか?
DDoS 攻撃やセキュリティ ホールのトリガーよりも複雑なことをしようとしている場合、スプーフィングは解決策ではありません。必要なのは、リクエストの真の発信元を隠すシステムです。HTTP トラフィックについて話しているので、匿名プロキシがそのトリックを行います。
あなたが言及しているセキュリティの目的のために、それはアクションを実行できるかどうかに依存します。サイトが純粋に情報提供を目的としている場合は、安全です。サイトでアクションの実行が許可されている場合 (たとえば、これを更新する、それを削除する)、少なくともパスワード認証を追加することを検討してください。
心に留めておくべきもう 1 つの問題は、サーバーと許可したい IP アドレスの間のルーターを制御している人は誰でもパケットを傍受できるということです。これにより、サーバーが気付かないうちに、完全な双方向のなりすまし通信を行うことができます. 情報を真に安全にしたい場合は、HTTPS と認証スキームを使用して、そのような傍受が起こらないようにします。
それほど難しいことではなく、他の通信のために IP アドレスをスプーフィングするのと同じくらい簡単です http://en.wikipedia.org/wiki/IP_address_spoofing
しかし、彼らは応答を得るつもりはありません。彼らがスプーフィングした実際の IP アドレスです。
あなたが正しい。双方向通信を確立するためにサーバーの応答がクライアントに到達する必要がある場合、なりすまし IP は応答を受信しません。ただし、応答を計算するとサーバーの CPU が消費されるため、なりすまし IP からサービス拒否攻撃を受ける可能性があります。
当社の Web サービス セキュリティの一部は、許可されたクライアントのみがサービスにアクセスできるようにするために、否認防止を保証するためにクライアントに公開鍵/秘密鍵暗号化 (xml デジタル署名) を使用することを要求することです。