2

SSL が混在する Web アプリケーション (asp.net 3.5) があります。すべてのアカウント関連ページは SSL 経由で配信されます。ほとんどの他のすべてのページは非 SSL 経由で配信されます。HTTPS と HTTP を自動的に切り替えるには、このコンポーネントを使用します。最近、セキュリティで保護されていない Wifi ネットワークでユーザー セッションを乗っ取る機能に関するニュースがありました。これは、非 SSL 接続を介して送信される Cookie をキャッチすることで可能になります。

これにより、この Web アプリケーションでのセキュリティの選択を見直すきっかけになりました。(再び) MSDN からこの記事を入手し、Formsauthentication でrequireSSL=trueプロパティを試しました。Web アプリケーションを開始する前に、この情報を含む Cookie が Web ブラウザーとの間で送受信されないため、非 SSL ページでは User.Identity が null になることに気付きました。

SSL 接続を介してユーザーを認証するメカニズムが必要です... 非 SSL ページであっても、この認証情報を記憶しています。

SOを検索しているときに、この投稿を見つけました。これは良い解決策だと私には思えます。しかし、Sessionstate にログイン情報を保存することで解決策を見つけることができるのでしょうか? Global.asax で Application_AuthenticateRequest をキャッチすることを考えています。接続が安全かどうかを確認し、authcookie またはセッションを確認します。これをどのように実装するのか、まだ正確にはわかりません。多分あなたはこれについて私と一緒に考えることができますか？

4

2 に答える 2

3

残念ながら、相反する要件があります。非 SSL を介して安全なセッションを行うことはできないため、根本的な仮定に異議を唱えたいと思います: サイト全体で SSL を使用しないのはなぜですか?

于 2011-04-13T15:45:49.383 に答える
2

SSL を使用しないように属性を要求する MVC FAQ (セキュリティの第一人者 Levi が回答した同様の質問) から。

• [RequireHttps] 属性をコントローラ タイプまたはアクション メソッドで使用して、「これは SSL 経由でのみアクセスできます」と言うことができます。コントローラーまたはアクションへの非 SSL 要求は、SSL バージョンにリダイレクトされるか (HTTP GET の場合)、拒否されます (HTTP POST の場合)。必要に応じて、RequireHttpsAttribute をオーバーライドして、この動作を変更できます。反対のことを行う組み込みの [RequireHttp] 属性はありませんが、必要に応じて独自の属性を簡単に作成できます。

プロトコル パラメータを取る Html.ActionLink() のオーバーロードもあります。プロトコルとして「http」または「https」を明示的に指定できます。そのようなオーバーロードの 1 つに関する MSDN ドキュメントを次に示します。プロトコルを指定しない場合、またはプロトコル パラメータを持たないオーバーロードを呼び出す場合は、リンクに現在の要求と同じプロトコルを持たせたいと想定されます。

MVC に [RequireHttp] 属性がない理由は、あまりメリットがないからです。[RequireHttps] ほど面白くなく、ユーザーが間違ったことをするのを助長します。たとえば、多くの Web サイトは SSL 経由でログインし、ログイン後に HTTP にリダイレクトしますが、これは絶対に間違ったことです。ログイン Cookie は、ユーザー名 + パスワードと同じくらい秘密であり、ネットワーク上で平文で送信されます。その上、MVC パイプラインが実行される前に、ハンドシェイクを実行してチャネルを保護するための時間 (HTTPS を HTTP よりも遅くする原因の大部分) を既に取っているため、[RequireHttp] は現在の要求または将来の要求を作成しません。より速くリクエストできます。

于 2011-07-28T21:47:54.980 に答える