1

私は omegle に似た小さなアプリを書いています。Java で記述された http サーバーと、html ドキュメントであるクライアントがあります。通信の主な方法は、http リクエスト (ロング ポーリング) によるものです。

https プロトコルを使用してある種のセキュリティを実装し、サーバーに接続するすべてのクライアントにセキュリティ ID を設定しています。クライアントが接続すると、サーバーはクライアントに securityid を与えます。これは、クライアントが要求を必要とするときに常に送り返す必要があります。

ここでの中間者攻撃が怖いのですが、そのような攻撃からアプリを保護する方法について何か提案はありますか?

このアプリは理論的な目的で構築されていることに注意してください。実用的な理由で使用されることはないため、ソリューションが必ずしも実用的である必要はありません。

4

2 に答える 2

3

HTTPS は暗号化だけでなく、サーバーの認証も行います。クライアントが接続すると、サーバーはそのドメインに対して有効で信頼できる証明書を持っていることを示します。この証明書は、中間者によって単純にスプーフィングまたはリプレイされることはありません。

于 2010-06-19T12:38:24.553 に答える
1

単純に HTTPS を有効にするだけでは十分ではありません。Web は非常に多くの複雑さをもたらすからです。

1 つには、Cookie にセキュア フラグを設定していることを確認してください。そうしないと、Cookie が盗まれる可能性があります。

https://<yourdomain>また、ユーザーがアドレス バーに入力することによってのみサイトにアクセスできるようにすることもお勧めします。これは、HTTPS セッションが有効な証明書で作成されることを保証する唯一の方法です。と入力するhttps://<yourdomain>と、サーバーが の有効な証明書を提供しない限り、ブラウザーはサイトへのアクセスを拒否します<yourdomain>。

https:// を前に付けずに入力<yourdomain>すると、ブラウザは何が起こっても気にしません。これには、頭のてっぺんから考えることができる2つの意味があります。

  1. 攻撃者は、似たような名前の Unicode ドメインにリダイレクトし (つまり、同じように見えますが、バイナリ文字列が異なるため、別のドメインです)、攻撃者はそのドメインに有効な証明書を提供します (彼はそれを所有しているため)、ユーザーこれは多分気付かない…

  2. 攻撃者はサーバーをエミュレートできますが、HTTPS がなければ、実サーバーへの独自の安全な接続を確立し、ユーザーとサーバーの間のクリアテキスト プロキシになります。セッションを所有しているため、攻撃者はすべてのトラフィックをキャプチャし、やりたいことを何でも実行できます。

于 2010-06-19T13:17:40.937 に答える