ユーザー名とパスワードを受け入れる .NET アプリケーションのテストを手伝っています。アプリケーションは SSL を介して実行され、SSL でセットアップされたページの iframe を介してホストされます (ユーザーは親ページで https を確認し、自信を持って情報を入力できます)。
したがって、明確にするために、 https ://www.mydomain.com/mypage.aspx というページがあり、そのページ内には、 https://wwwと同じサーバー上の .NET アプリケーションを参照する iframe があります。 mydomain.com/apps/myapp.aspx
ユーザーがページを送信すると、Filezilla ブラウザ アドオン「Live HTTP Headers」を介してヘッダーを監視しています。残念なことに、ユーザー名とパスワードを含むフォーム データは、ヘッダーの POST セクションにプレーンテキストで表示されます。
私の結論は、情報は暗号化されていないということです。あれは正しいですか？もしそうなら、最善の解決策は何ですか？
これらのフォーム変数を https/SSL 経由で投稿する場合、実際の送信は暗号化されます。ブラウザの拡張機能でそれらを表示することはできますが、投稿が実際に http:// ではなく https:// に投稿されている限り、ブラウザはそれらを暗号化して SSL 経由でサーバーに送信する必要があります。
次に、ユーザー名とパスワードのペアをユーザーに返すのではなく、ユーザーを認証し、一致する場合はフォーム認証などを使用して、現在のセッションでユーザーを認証するトークンを生成する必要があります。
.net 認証がどのように設定されているか (Windows、フォーム、またはパスポート) はわかりませんが、SSL を使用しなくても認証チケットは暗号化されます。SSL は、クライアント (ブラウザー) とサーバーの間の通信チャネルを保護するだけです。あなたの説明から、フォームは.Net認証機能を使用せずに、投稿または取得を介してユーザー名/パスワードフィールドをパラメータとして送信しているように思えますか?
この件に関する良い背景は次のとおりです。
更新: あなたの質問を読み直しました: .net 基本認証 + SSL を使用していることは明らかです。SSL は、基本認証に欠けている暗号化部分をカバーするため、これは正常に機能するはずです。セットアップが正しいことを確認するだけです。FFアドオンに関しては、クライアント（発信者）が利用できる情報を見ているだけで、サードパーティはそれを行うことができません.