HTTPページにHTTPS iframeを埋め込むことの特定のリスク

Question

HTTPページの内部でクレジットカードのチェックアウトを可能にするHTTPS iframeを埋め込むことの特定のリスクをリストする手助けが必要です。 HTTPページにHTTPS iframeを埋め込むことでセキュリティの問題はありますか？は、いくつかの高レベルの懸念を提供しますが、私は潜在的な攻撃ベクトルについて可能な限り具体的に考えています。安全でないページ内の安全なiframeの良い例として今すぐ購入をクリックしてください。今日はクレジットカード取引に使用されています。ここに私がこれまで持っているものがあります：

教育を受けたユーザーは、ブラウザーのクロムのURLに緑色の鍵が表示されない限り、クレジットカード番号を入力しないようにするため、コンバージョンはおそらく低くなります。（知識の少ないユーザーは、上記の例のように、ブラウザーフレーム内に表示されるロックを信頼してはならないことを知らない可能性があります。）
ユーザーがこの方法に慣れている場合でも、URLバーにSSLロックの確認が表示されないときにクレジットカード番号を入力するようにユーザーに勧めることは一般的に悪い考えです。それはユーザーに悪いセキュリティ習慣を教えています。この投稿は、SSLは単なる暗号化と認証以上のセキュリティに関連していると主張しています。
真ん中のアクティブな男が、スヌープをキーストロークできる不正なスクリプトを親ページに挿入する可能性があります。私はこれがチュニジア政府が盗む反体制派Facebookの資格情報にしたことだと信じています（悪意のあるスクリプトは、安全なiframeからユーザー名とパスワードにアクセスできなくなりますが、それでもキーストロークにはアクセスできます）。もちろん、より明確な政府機関がDNSを覆し、SSL証明書を偽造する可能性もあります。これはイラン政府が行ったようであり、その場合、安全な親ページは役に立ちません。

私もこの非現実的な懸念のリストを持っています：

安全でない親ページ上の別のJavascriptオブジェクトが安全なiframeのコンテンツをスヌープする可能性があります。 IE8以上のブラウザーのみがサポートされている限り、これは不可能だと思います。
親ページの不正なJavaScriptオブジェクトがキーストロークロギングを実行して、ユーザーのクレジットカード番号を取得する可能性があります。これは可能かもしれませんが、親ページがSSL経由で提供されているかどうかによってリスクが影響を受けることはありません。悪意のあるスクリプトがスヌープをキーストロークする可能性があります
ユーザーは、セキュアなiframeが提供されているURLを見ることができません。 保護されたまたは保護されていない親ページの場合、iframeソースURLを表示するには、技術的に高度なユーザーである必要があります。

他にどのような現実的および非現実的な脆弱性がないのか教えていただけませんか？安全なiframeを安全な親ページに埋め込むことが常に最善の方法であることは間違いありません。私が決定しようとしているのは、安全なページ内で安全なiframeを有効にすることの相対的なリスクとメリットです。

bobince · Accepted Answer

今すぐクレジットカード取引に使用されている、安全でないページ内の安全なiframeの良い例については、[今すぐ購入]をクリックしてください。

言及されたすべての技術的理由は別として、これは壊滅的に悪いことであり、これは明示的にPCI-DSS要件に違反しています。「ナビゲートDSS 2.0」要件4.1を参照してください。

When using SSL secured websites, ensure “https” is part of the URL

リンクされたインターフェースは、加盟店が銀行との契約の一部としてサインアップするPCI条件に違反しています。 ShopLocketは、明らかにPCIに準拠していないだけでなく、カード処理に対する深く疑わしいアプローチを提供/奨励しているようです。

Tom Leek · Answer

不正なスクリプトを親ページに埋め込むことができる攻撃者は、iframeのURLを変更して任意の場所にリダイレクトすることもできます。この時点で、あらゆる種類のフィッシングや中間者の設定が簡単になります。そのレベルでDNSトリックをプレイする必要はありません。これがこのようなHTTPS iframeの主な問題です。本物かどうかを簡単に知ることはできません（ブラウザーのデバッグモードを起動して本当に確実にする必要があります。ページのソースをざっと見るだけでは、スクリプトが読み込まれるため、最終的には十分ではありません。ページからDOMレベルで自由に操作できるため、ソースコードに表示されるように見えるものは、必ずしも取得したものとは限りません。

結局のところ、iframeのURLバーがないことが原因です。 HTTPSサイトの場合、URLバーは適切なSSLが有効であり、有効なサーバー証明書とがサーバーの名前を示していることを示しますあなたは実際に話している。バーを取り除くと、あらゆる種類の厄介なトリックが可能になります。

明るい面、HTTPページのログインフォームのHTTPSターゲットURLのようなHTTPS iframeは、パッシブのみの攻撃者（すべての交換されたバイトをリッスンする攻撃者の種類に対して優れています）自分で何かを注入することはありません）。ほとんどの攻撃者がパッシブのみであると信じることは、今日、非常にナイーブになっています。

ユーザーエクスペリエンスについては、通常、サイト全体をHTTPSにすることをお勧めします。計算の観点からは、通常考えられているよりもはるかに安価です。一般的に、人間はパフォーマンスの問題を予測するのが得意ではありません。パフォーマンスは測定の問題であり、推測ではありません。ぜひお試しください。

また、ユーザーとして（必ずしもtypicalユーザーである必要はありません）、 HTTPからHTTPSへの目に見える移行が好きです。チェックアウトはお金についてであり、決定的に、myお金についてです。したがって、重要です。