web-dev-qa-db-ja.com

HTTPサイト内のHTTPS iframeでクレジットカード情報を収集する

slate.comの有料メンバーシッププログラムは、プレーンHTTP上でHTTPS iframe内のクレジットカード情報を収集します。 HTTPSのURLは https://my.slate.com/subscriptions/manage/ です。 Screenshot of credit card form

article では、これは安全であると主張しています:

クレジットカードデータが送信されると、それらはサードパーティの支払いプロバイダーに送信され、クレジットカードデータはスレート自体によって保存されません。クレジットカードデータは常にHTTPS経由で送信されます。スレートでクレジットカード情報を入力することは非常に安全なことです。スレートプラスをお楽しみください。

ただし、それらはプレーンHTTPを介してユーザー名/パスワードも取得するため、私は懐疑的です。 screenshot of username and password form

彼らが説明した方法でクレジットカード情報を安全に取得することが可能であるかどうか誰かが私に言うことができますか?

14
mcranston18

警告、IANAQSA

更新:スレートは実際にはSAQ Aではありません-彼らはiframeを使用しておらず、たとえば にカード情報を送信していますhttps://profile.slate.com/widget/traditional_register .jsonp ...ただし、以下のほとんどはまだ精神に当てはまります。

彼らが説明した方法でクレジットカード情報を安全に取得することが可能であるかどうか誰かが私に言うことができますか?

はい、可能です。ただし、接続が安全であること、およびアクセス先の支払いサイトが正当な支払い処理業者であることを確認するという、暗黙の責任があなたに移されます。

とはいえ、この構成は(PCIに従って)許容可能であり、(セキュリティのベストプラクティスに従って)少しお勧めできません。

すべてのカード処理をiframe経由でプロセッサーにアウトソーシングする販売者に適用されるSAQ Aの読み取りは、これが正当な構成であることを示唆しています。これは、ページに明示的な要件を課さないことに注意してください含むサービスプロバイダーの支払いページを囲む支払いページ(iframe)。 SPのページだけがSPから取得され、[〜#〜] sp [〜#〜]はPCI DSSに準拠しています(これは、暗号化):

SAQ A Eligibility Requirements

さて、言われているように、 [〜#〜] mitm [〜#〜] などの問題があり、Slateによる外部暗号化の欠如はお勧めできません。多くの組織がこのこぶを乗り越え、最終的にはサイト上のすべてを暗号化することがperceptionの不安を処理するよりも望ましいと判断しました。しかし、組織がそこに到着するまでには、通常、時間と苦情がかかります。だから、これについて文句を言ってください。

8
gowenfawr

彼らがやっていることは、httpsをまったくやらないよりも確かに優れています。ただし、外部のhttpページは、「安全な」iFrameが置き換えられたり、他の方法で侵害されたりする可能性のあるMan-In-The-Middleのような攻撃の影響を受けやすくなります。この方法では、エンドユーザーが自分で判断することも難しくなります。ロックアイコンは役立ち、ブラウザはサイトが安全かどうかを判断する方法をユーザーに教えるために一生懸命働いています。

現在のhttpsの最小コストと、一般的に提供されるセキュリティの追加量を考えると、これを防御する理由はありません。彼らはそれを修正して、どこでもhttpsにアクセスする必要があります。

39
crovers

サイト全体を暗号化すると、トラフィックを変更せずに読み取るだけのパッシブな攻撃と、積極的に情報を取得してセキュリティ対策を回避しようとするアクティブな攻撃者から保護されます。暗号化されたiframeを使用すると、支払いデータが転送中に暗号化されるため、パッシブな攻撃者から保護されます。ただし、元のページは暗号化されていないため、アクティブな攻撃者(別名:真ん中の男)は、セキュアなiframeを自分のサイトを指すものに置き換えるだけで、そこにあるはずのサイトと同一に見えるようにすることができます。または、保護されていない接続を介してiframeを強制的にロードして送信します(HTTPSを介して強制的にロードするためにHSTSを使用していない場合)。その後、支払いの詳細など、入力したすべての情報を取得できます。さらに、iframeにはプロトコルやOriginインジケーターがないため、入力内容が傍受されていることを通知するブラウザー通知はありません。つまり、このような攻撃を検出する唯一の方法は、フォームの要素を検査することであり、ほとんど誰もそうしません。

HTTPS iframeを使用することは、何もしないよりはるかに優れていますが、それが安全であると言うのは間違っています。個人的には、URLバーにhttpsが表示されていないページに支払いの詳細を入力することはありませんが、信頼できる接続(つまり、パブリックwifiではない)の場合、リスクはごくわずかです。

7
JackW

Slate.comは(まだ)slate.comにリダイレクトしているため、httpからhttpsへのプロトコル切り替えですが、slate.comをカード会員データ環境がないと見なしません。はい、ユーザーのブラウザとslate.comの間のセキュリティが強化されています(たとえば、TLS 1.2を想定)。しかし、それはそれだけです。

0
Grant