2012-04-06 16 views
0

は、私は(ユーザーが投稿したコードは、私のサイトを脆弱にすることができない一方で、すなわち、私が開発した貴重なコードのホールドを維持する)、そのサーバー上のすべてのクライアントのファイルを格納するが、地雷の処理を行うこと、CMSのアプリを開発しました。今問題は、ユーザーが自分のウェブサイトを編集するためのコントロールパネルを持っている、これは自分のウェブサイトでホストされている、それは1ページのものですが、ログインの詳細/セッションは常に私のウェブサイトにあります。私は渡されたトークンが有効な場合のみアクセスがあるサイト上の編集ページを作る方法を有していると考えていた2つの異なるサーバーでログインを認証するにはどうすればよいですか?

、両方のサイトは、同じトークンを開発し、チェックするのと同じ方法を持つことができます。これは受け入れ可能なセキュリティです。私は、URLが何らかの形でスニッフィングされ、トークンが有効であることと同じ時間フレームで独立して使用された場合、私が考えることができる唯一の悪用方法であることを意味します。ヘッダーをチェックすることはセキュリティのオプションの余分なビットですが、これらは偽装されている可能性があるため、絶対的な解決策ではありません。私はユーザーのウェブトラフィックを盗聴することがどれほど簡単かわかりませんが、この方法は使えますか?

ありがとうございます。

答えて

1

スニッフィング攻撃は、証明書の検証(man-in-the-middle攻撃を無効にする)が必要な場合は、トランスポートを暗号化するだけで簡単に無効になります。

私はあなたの設定を完全に理解していませんが、編集ページをバックエンドサーバーに呼び出して、認証用のトークンを渡す必要があるようです。あなたが意図したものなのでしょうか?

+0

返信いただきありがとうございます。クライアントサーバーを使用しているためSSL機能がない可能性がありますが、SSLは使用できません。主な問題は悪意のあるユーザーに編集ページにアクセスさせたくないということですが、クライアントWebサイトに重大な損害を与える可能性があるため、編集ページはバックエンドサーバーに呼び出されます。 – Ally

+0

SSLを使用できない場合、セキュリティオプションを真剣に制限しています(基本的にMITMを保証するか、再生攻撃が可能です)。つまり、私が呼び出すことが意味するのは、編集ページはバックグラウンドサーバーにコールしてから、*(*ローカルの)アクションを取ることです。これにより、バックエンドサーバとのリンクの安定性を犠牲にしても、被害は抑制されます。 –

+0

あなたが何を意味するかは完全には分かっていませんが、私はそれをもう少し考えるのを助けてくれてありがとうございました。私は、sslを両方の方法でシミュレートするためにrsa暗号化を使っていれば、実際にこれについて考えてみると、MITM攻撃に対してはまだ脆弱です。 – Ally

関連する問題