1

組織内のいくつかの異なるサイトにリソース（js / css）を提供するためのリソースマネージャーハンドラーを作成しました。ほとんどのサイトは内部にありますが、いくつかは外部にあり、SSLを使用しています。QA / Devサイトには証明書と同じドメイン名がないため、カスタム検証にコールバックを使用する必要があります。私は、環境をチェックして本番環境にない場合にのみtrueを返すか、ドメイン名をチェックしてqa/devドメインと一致する場合にtrueを返すなどの操作を実行できることを理解しています。私の質問はそれをどのように行うかではありませんが、なぜですか？リソースハンドラーのすべての証明書を受け入れることが安全でないのはなぜですか？ユーザーが実際に行うことができる悪意のあることは何ですか？

ServicePointManager.ServerCertificateValidationCallback += ValidateRemoteCertificate;
public static bool ValidateRemoteCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors)
{
     return true;//Why not do this?
}

更新：ハンドラーが何をするかについて、いくつかの説明を追加する必要があるかもしれないと思います。このハンドラーを通過するリソースに対するすべての要求はハッシュされます。ハンドラーは要求を復号化し、アセンブリからリソースをプルするか、プロジェクト独自のローカルリソースを要求することにより、リソースを提供します。ドメインの不一致が発生するのは、そのローカルリソースがハンドラーによって要求されたときだけです。振り返ってみると、おそらく別の方法で処理する必要があると思いますが、元の質問に関しては、MITM攻撃がどのように適用されるかはまだわかりません。この場合、すべての証明書を受け入れるのが安全だと思いますが、100％ではありません。なぜ私はそれをここで育てたのですか。:)

4

3 に答える 3

4

それはHTTPSの目的を打ち破ります。

すべての証明書を受け入れると、誰でも自己署名証明書を使用して中間者攻撃を実行でき、正常に機能します。

于 2012-04-27T14:23:36.877 に答える
1

秘密を交換している相手の身元を確認する必要があります。そうしないと、彼らがなりすましになる可能性があります。

クライアントからサーバーへ、アクティブなMITM攻撃者は自分の証明書を使用して、気付かないうちにトラフィックを本物のサイトに中継する可能性があります。Security.SEでこの質問を確認してください：未認証の証明書を許可することの欠点。

クライアント証明書の受け入れに関しては（サーバーの観点から）。クライアントと密かにデータを交換しますが、クライアントが誰であるかはわかりません。クライアント証明書は認証に使用されます。これは、追加の検証なしで何でも許可することでバイパスされます（そしてこのステップは役に立たなくなります）。

編集（サーバー側の観点からのものであることを追加しました）：

おそらく、あなたがしていることは、証明書を受け入れ、それらに含まれる名前をユーザーのIDとして取得することです。これの欠点は、実際には認証を行っていないことです。つまり、ユーザーが額面通りに主張している名前を受け入れているだけです。これは、正式なID（パスポートなど）を確認する代わりに、「私の名前はXです」という紙を受け入れるようなものです。

于 2012-04-27T14:24:43.230 に答える
1

提示された証明書を信頼しているため、man-in-the-middle攻撃の影響を受けやすくなります。

中間者攻撃は、攻撃者が各エンドポイントを他のエンドポイントになりすますことができる場合にのみ成功します。これは、相互認証に対する攻撃（または相互認証の欠如）です。

http://en.wikipedia.org/wiki/Man-in-the-middle_attack

于 2012-04-27T14:28:17.537 に答える