2017-04-11 35 views
0

私はすべてのフォームを保護するために偽造防止剤を使用するアプリケーションを持っています。アプリケーションは、HTTPバインディングが8080に設定されているWebサイトでホストされています。httpsは443(デフォルトのhttpsポート)に設定されています。これまでは、すべてのリクエストがhttps(MVCアプリは必須のhttpsフィルタを使用していました。ウェブ設定ではクッキーのエントリrequiresslがtrueに設定され、owinには認証Cookieもhttpsに設定されています)ASPNET MVC 5:偽造防止クッキーがありません

最近私たちは、私たちのためにhttps要求を処理するファイアウォールを持っているので、変更する必要がありました。それは常に最終的なクライアントにhttpsを介して応答を提供しますが、私はhttpを介して呼び出すことができるように私のアプリを変更していた。

必須のhttpsフィルタ、設定からのCookieに必要なSSLを削除し、owin auth cookie設定を変更しました。すべてがOKであると思っていました。残念ながら、それは起こりませんでしたし、私は偽造トークンのクッキーが検証中に例外が見つからないようになってきました。さて、私はhttpsを使用するとすべてが機能しますが、http(ポート8080にあります)に変更すると破損します。

偽造防止構成の設定をグローバルasax内から変更してしまいましたが、私は以前の問題の説明を見つけることができません。言い換えれば、httpsのアクセスは何の問題もなく動作しますが、httpアクセスでは、偽造防止クッキーが見つからないという例外がスローされてしまいます...

アイデア?

おかげで、 ルイス・

答えて

2
ないより

より可能性が高いが、あなたは安全なクッキー(Secureタグで送信されたクッキー)を使用しています。これらはHTTPS接続でのみ存続します。 SSLが破棄されるとすぐに、セキュアなCookieもすべて削除されます。 になる可能性がありますが、実際にはユーザーに攻撃経路を開いて、Cookieをプロトコル切り替えによってプレーンテキストで公開することができます。

あなたができる最良のことは、それをすべて安全に保つことです。 SSLがファイアウォールによって提供されているからといって、サイトにSSLを実装することはできません。唯一の違いは、明らかに外部ドメインが適用されないため、自己署名証明書が必要になることです。それ以外に、セキュリティ保護されていないサイトではなく、内部的に安全なサイトへのプロキシ処理に問題はありません。

+0

こんにちはChris。私はそれを行うことができます。 しかし、私が記述している動作は、ファイアウォールを介して要求を受信して​​いる間は起こらないことに注意してください。それは私がhttpsを介してのみ動作させる私のアプリから以前の設定を削除した後、マシンにアクセスするとき起こっている。だから、私はhttpやhttpsで動作するはずのアプリケーションで終わったのですが、httpでアクセスしようとするたびに言及した偽造防止のエラーで失敗しています(理由はわかりませんが、localhostという名前ADマシン名の代わりに、私はエラーを取得することはありません)。 –

+0

@Chris Prattはsslを変更するように思い出し、私が期待したようにlocalhostで作業しています。

関連する問題