2

(FWIW、この質問をブログにも投稿しました: http://blog.wolffmyren.com/2011/07/11/ie-protected-mode-ssl/ )

エンドユーザーがサイトを信頼済みサイト リストに追加する必要なく、Internet Explorer の保護モードの制限を回避する方法を知っている人はいますか?

問題は、サイトで SSL ログインを有効にすると、SSL ページにしかアクセスできないことです。IE は、非 SSL で提供されるページが SSL セッション中に作成された Cookie にアクセスするのを防ぎます。そのため、SSL を介してすべてを提供するか (非常に高価/リソース集約型)、SSLおよび非 SSL Cookieを設定する方法を見つけることができます。ログインプロセス中。

この MSDN の記事 (What does ielowutil.exe have to do with Internet Explorer 8.0?) には、これまでで最も関連性の高い情報が含まれていますが、Windows API の使用について説明されており、ASP で実装できるソリューションを探しています。 NET、JavaScript、またはその他の優れたソリューションを使用できます。

更新:私の友人がこれらのリンクを共有しました。

4

2 に答える 2

1

Bruno が暗示しているように、SECURE 属性が Cookie に設定されていることを確認する必要があります (F12 開発者ツールまたは Fiddler を使用します)。そうである場合、すべてのブラウザでこの動作が見られます。

そうでない場合は、トラスト ゾーンに問題があり、http: //whatever.comもトラスト ゾーンにない可能性があります。それがあなたの構成である場合、はい、保護モードが問題の根本原因です。これについては、ここでより完全に説明しました。

http://blogs.msdn.com/b/ieinternals/archive/2011/03/10/internet-explorer-beware-cookie-sharing-in-cross-zone-scenarios.aspx

于 2011-07-12T13:16:16.167 に答える
1

IIS が HTTPS 接続を介して安全な Cookie を提供しているように見えますが、これは非常に賢明です。これらの Cookie はプレーンな HTTP 接続に漏洩しないように設計されているため、得られる結果が得られます。

セキュリティで保護されていないセカンダリ Cookie を作成して、サイトの HTTP 側に認証情報を渡すことができます。ただし、これを行った後、ある時点で HTTPS に戻る必要がある場合は、プレーン HTTP セッション中に行われたことや送信されたことが正当な認証済みユーザーによって行われたと想定しないでください。認証トークンを HTTPS から HTTP に渡すことは問題ありませんが、その逆は問題ありません。(もちろん、プレーンな HTTP での攻撃に対しては依然として脆弱ですが、これはアプリケーションでは許容できるリスクである可能性があります。)

この質問には、この問題に関する詳細があります (Tomcat に適用されるものは、IIS を含むどの Web サーバーでも同じです): Tomcat セッション管理 - URL の書き換えと http から https への切り替え

于 2011-07-12T09:58:57.003 に答える