iframe内のページがSSLで保護されている場合、iframeを介して詳細を提供しても安全ですか？
ストリーミングサービスにアクセスしたところ、支払いの詳細を提供したかったのですが、HTTPS/SSLで保護されていないページが表示されました。
私は詳細を提供せず、サポートに連絡して、私のお金が必要かどうかを修正するよう依頼しました。
返答は、支払いの詳細フォームが実際にiframeにあり、iframeのソースisがHTTPS/SSLによって保護されているということでした（これは私が確認できます）。
しかし、これは安全ですか？ iframeのソースがHTTPSであるのにiframeを表示するページがそうでない場合、iframeを介して支払いの詳細を提供しても安全ですか？
これは不適切なデザインであり、ページ全体でHTTPSを使用する必要があります。これは、HTTPを介して個人情報を信頼して送信するという安全ではない慣行にユーザーをトレーニングするためです。中間者の攻撃者が外部のHTTPページを変更して正しいHTTPS iframeを使用せず、代わりに攻撃者が制御するiframe（攻撃者が制御するドメインへのHTTPS）を使用するのは簡単です。
したがって、プライベートデータを送信するたびにiframeのソースコードをチェックする必要があります（最初に検査したときに問題がなかったが、次にHTTPタンパーによって変更されたという保証はありません）。
さらに、ページがHTTP経由で読み込まれると、MITMの攻撃者は、外部ページに必要なJavaScriptを挿入して実行する可能性があります（そして、外部から読み込まれる難読化されたスクリプトでこれらの変更を非表示にします）。 HTMLページのソースの表示をクリックした場合、元のiframeを正しいhttps URLのままにすることができますが、JavaScriptでは、iframeを非表示にしたり、同一に見える悪意のあるDOM要素に置き換えたりできます（ただし、詳細を攻撃者に漏らします）。これは、最新の開発者ツールのインタラクティブなDOMインスペクター（現在のDOMを表示するので、iframeを検査できるはずです）の問題ではそれほどありませんが、繰り返しますが、これには、必要なすべてのユーザーに対して多くの検証作業が必要です安全にデータを送信します。
IframeはHTTPSを介していますが、メインのWebページはHTTPです。これは混合コンテンツですが、ブラウザは、HTTPコンテンツがSSLで保護されたページに埋め込まれている場合にのみ警告を表示し、この場合のようにその逆は行いません。
メインページがHTML postMessage API呼び出しを介してiframeのコンテンツと通信できるため、依然として安全でない組み合わせです。このクロスドメインシナリオでは、iframe内のドキュメントがメインページからのこれらのメッセージベースのクエリを受け入れて応答する場合にのみ機能します。 この例 を参照してください。これは 別の例 で、メインページのiframeをiframe自体に埋め込むことによってこのクロスドメインセキュリティを回避する方法を開発者に示しています。そのため、ブラウザが時間の経過とともに更新され、これらのギャップを修正します。
ここで私が目にする唯一の問題は、メインのHTTPページ（安全ではない）とHTTPSで保護された支払いページの間でデータが交換される場合、その安全性と、安全でないHTTPドメインへのアクセス時の保護の程度です。
ただし、繰り返しになりますが、この種の問題は、iframeが関係するかどうかに関係なく、あるWebアプリがユーザーセッション/トランザクションを別のWebアプリに渡す場所であればどこでも有効です。エンドユーザーは、トランザクションを完了するときに、さまざまなサービスプロバイダー間で舞台裏で行われている通信の種類を知りません。これらは、PCI-DSSなどが検証するはずの種類のチェックです。
HTTPページとHTTPSページに属する両方のサーバーが同じストリーミングサービス会社に属している場合は、それらを信頼できることをお勧めします。
いいえ、安全ではありません。
親ページがhttpsで保護されていない場合、ユーザーに正しいhttps iframe URLが表示される保証はありません。
攻撃者は、親ページに対して中間者攻撃を実行し、攻撃者のWebサイトにiframeをレンダリングさせる可能性があります。ブラウザーはiframeのURLまたはhttpsステータスを示さないため、ユーザーは不正なユーザーと通信している方が賢明ではありません。