クレジットカードフォームのあるWebページにサードパーティのJavaScriptを読み込まない理由に必要なデータ
私の会社では、eコマースサイトが自分のページに埋め込むことができるJavaScriptウィジェットを作成しています。お客様への現在の指示では、サイトのすべてのページにJSを読み込み、クレジットカードフォームのあるページに含めても、ほとんどの場合、このアドバイスに従ってください。私は、「クレジットカードフォームのあるページ以外のすべてのページにロードする」という指示を変更するように要請してきましたが、まだ成功していません。
私の会社の主な懸念は、お客様が私たちをさらに精査するか、そうでなければ私たちの製品は安全ではなく、その結果としてビジネスを失うと結論付けることです。また、クレジットカードページにJSを表示することには大きなリスクがあるとは考えていません。
更新：BrianAdkinsが以下で説明するように、URLをチェックするJavaScriptの短いスニペットをクライアントに送信し、URLがチェックアウトページと一致しない場合にのみ<script>要素を追加することをすでに提案しました。しかし、以前と同じ反対があった。また、URLが変更された場合や、URLからCCページであるかどうかを判断できない場合の対処方法についても懸念がありました。 （この場合、少なくとも1人の顧客がいます。）したがって、元の要求はまだ残っています。
私が探しているのは：
事実：この方法で侵害されたビジネスの例はありますか？結果はどうでしたか？
- または、代わりに、私が間違っていること、およびこれは実際には発生しない理論上の問題にすぎないことを示すデータはありますか？
認識：セキュリティについて懸念していることは安全性が低いことを示しているという考えに対抗するために、お客様と何を共有できますか？
- たとえば、CCページにサードパーティのJSを含めることは PCI-DSS に違反しますか？ 「要件7：知っておくべきビジネスニーズによるカード会員データへのアクセスの制限」のように聞こえますが、この状況について明確に説明しているところはどこにもありません。
ほとんどのeコマースサイトには、支払いページにGoogleアナリティクスコードが含まれています。支払いページは、optimizelyまたはvisual-website-optimizerなどのJSツールを使用したa/bテストの主要な候補でもあります。
JSがカートからCCデータをhttpsを介してサービスの母船（Ordergrooveなど）に戻すことに依存するサードパーティ製品サブスクリプションエンジンへの統合もあります。
多くのeコマースプラットフォームでは、テンプレートシステムを介してすべてのページにウィジェットを簡単に組み込むことができますが、コンバージョンプロセスで1つのページだけを除外することは困難です。
1つのオプションは、URLが特定のパターンに一致するインスタンスにリモートコードを含まない、少しのJSでウィジェットをラップすることです。これにより、特定のページでのコードの実行を簡単に防止しながら、顧客がコードをどこにでも（すべてのテンプレートで）配置できるようになります。これは、代替のインストール手順として配信できます。
私が正しく理解している場合は、特定のページで独自のコードを実行しないように提案することにより、潜在的なリスクの認識からクライアントを予防的に保護しようとしています。あなたの努力は必要ないかもしれません。
クライアントが自分で選択できるようにして、クライアントを保護します。ドキュメントを変更して、「すべてのページにインストールしますが、CCプロセスのあるページは安全に省略できます。」
「個人/クレジットカードデータをWebページに表示する場合は、すべてのJSスクリプトを省略する必要がある」というセキュリティのベストプラクティスにまだ遭遇していません。
ウィジェットと顧客のクレジットカードデータが同じページにある場合に脅威をもたらすような方法でJSウィジェットをハッキングする方法はありますか？多分。ウィジェットと、それがどのように侵害される可能性があるかを実際に確認する必要があります。これは、包括的なルールというよりは設計上の問題です。
妥協の例に関しては-それらは常に少数であり、はるかに隔たりがあります-それらが悪名高いのでない限り、ほとんどの企業はそれらを公表しません。あなたの最善の策は、OWASPガイダンスと脆弱性公開サイトをチェックして、ウィジェット内の何かに接続されている特定のJSアラートがあるかどうかを確認することです。
準拠するルールの観点から-一般的なベストプラクティスは、実装とインターフェイスをシンプルで明確な状態に保ち、慎重にレビューすることです。 JSウィジェットを不要な場所に配置すると、不必要な複雑さが追加されて、その前提に違反する可能性があります。 OTOH-支払い/ログインページからのみそれを省略する方法を見つけるよう顧客に要求すると、顧客コードにリスクを引き起こす複雑さを引き起こす可能性があります。各顧客のアーキテクチャに腰を下にしないと、それを伝える方法はありません。
そのような「役立つ」ウィジェットの多くは、直接のクロスサイト<script>タグを使用して読み込まれることがよくあります。法的責任の問題を明確に確立するまで、これは実際には行いません。通常、すべての責任は、ウィジェット作成者エンティティではなく、カード処理エンティティ（Webマーチャントまたはカード処理ゲートウェイ）にあります。
マーチャントまたはPCIカード処理ゲートウェイとして、カードデータ処理ページでサードパーティのJSを許可するには、過去、現在、および将来のビジネス保険の証明を伴う完全な補償が必要であり、当社のビジネスに対する潜在的な責任がカバーされます。悪意のある従業員がJavaScriptで悪事を行うのを阻止するための「手順」を「発言」したかどうかは、実際には問題ではありません。重要なのは、企業間の法的問題です。これが、PCIが責任をカード発行者/カードネットワークから販売者/カードプロセッサに移す主な理由です。
別の戦略は、ウィジェットの作成者に静的データのダウンロードZipを提供するようリクエストすることです。これは、起こり得る問題や悪の活動についてマーチャントまたはPCIカード処理ゲートウェイの技術エンジニアが監査/チェックできるものです。次に、ウィジェットのこの静的バージョンは、マーチャント自身のシステムから提供されます。もちろん、これは、ウィジェットの作成者が長い下位互換性を確保する必要があるか、顧客の不快感を冒す必要があるため、更新するのは面倒です。多くの場合、費用のかかるWeb開発スキルを必要とする販売者によって更新されることはありません。
別の戦略は、ウィジェット作成者が実際にサポートされているAPIを提供することです。これにより、eコマースマーチャントは、制御されたコードを使用してウィジェット作成者システムと対話できます。これは静的JSに似ていますが、サーバー側で処理されます。ウィジェットの作成者は、<script>タグを追加して遅延してクロスサイトをロードするのに比べて、通常、商人がウィジェットを採用するには高額なオプションであるため、このソリューションを避けます。
代わりの方法は通常、はるかに簡単です。そのようなウィジェットを使用せず、リスクから身を守るためです。
攻撃ベクトルを説明すると、悪意のあるウィジェットの作者のホスティングシステムが、Refererヘッダー、ランダム性、国、時間帯などを使用して、さまざまなバージョンのJSをさまざまなユーザーに提供する可能性があります。 JSコードの邪悪なバージョンを取得します。しかし、すべてのカジュアルな検査は、JSコードの正しいバージョンを提供するように見えます。
すべてのJSコードと同様に、JSの悪意のあるバージョンは、ページのフォームに自身を添付することにより、送信プロセス中にすべてのフォームデータフィールドを読み取ることができます。フォームにあるすべてのデータ（CVV/CSC、住所情報、通常のカードデータを含む）は、知らない顧客（アラートや警告はありません）が送信アクションを実行すると、複数のWebサイトに中継されます。次に、データは、送信先のサイト（マーチャントまたはPCIカード処理ゲートウェイ）と、悪意のある目的でデータを収集する悪質なサイトの両方にコピーされます。
IFRAMEも完全に安全なカプセル化メカニズムではありません。過去に、邪悪なJSコードによって回避できないようなことを許可する問題が存在していました。誰もがブラウザを更新するわけではありません。
「役立つ」ウィジェットの作成者が二重に話す「安全な」手順がありますが、問題が発生したときにPCI準拠のエンティティを支援します。それ以外の場合はだまされません。
私は個人的に、セキュリティ（ユーザー名/パスワード）またはカードを提示または受信するページの直接の<script>サードパーティクロスサイトエレメントの、英国で運営されているPCI準拠のカードプロセッサを2つ注意しました。ホルダーデータ。彼らにとっての問題は、それが彼らのビジネスへのリスクと、無能による違反の結果としての悪い宣伝の価値がないということです。
これらのことは、販売者の会計部門が支払いデータにアクセスするための安全なシステムとネットワークを提供し、ファイアウォール/プロキシ経由のインターネット接続のみを許可し、ホワイトリストにアクセスできるのは、使用する特定のシステムのみである場合に、すぐに気が付きます。どれだけ多くのものが壊れてはいけないかが驚くほどです。
違反の例を求めるのは無益であり、そのようなことを宣伝する人はいません。
架空の技術修正（または見方によっては暴言）
HTMLに本当に必要なのは、元のOriginサーバーが1つ以上のチェックサム（MD5/SHA1/etc）とターゲットスクリプトの長さ情報を提供する機能です。このようにして、ブラウザーがサービスを提供するWebサイトから受け入れる正確なコピーを、消費するWebサイトが完全に制御することができます。
<script src="http://mostly.trusted-site.com/useful-script.js" security:checksum="md5:0123456789abcedf;sha1:0123456789abcdef0123;length:543" security:options="load-from-cache-from-anywhere-matching-checksum;no-send-referrer-header;no-use-cookies;no-use-etag;high-security"></script>
このスクリプトタグは架空のもの（使用しないでください）ですが、HTMLの方向に移動する必要があります。これは、問題のあるドメインにおける潜在的な将来のHTML5 +修正を示すのに役立ちます。
これで、ターゲットサイトはコンテンツを私たちの下から変更できなくなり、ヒットを確認してコンテンツを提供できるようになります。チェックサム値に関する信頼を築くことができるので、インターネット上の複数の当事者が同じコードを独立して監査し、悪質なものについて同じJSコードのピアレビューの多くの目を許可します。
複数のハッシュは、より安全な/より長い/広くサポートされているハッシュへの移行の重複をサポートすることを許可され、衝突の理論的な可能性も低減します。
同じチェックサムが一致する別のWebサイトからのキャッシュからの読み込みを許可します（ヒットが最も速いCDNであるヒットなしのCDNを許可し、最終的に再びサーバーに戻ります）。 jquery.jsの独自のローカルコピーを作成できますが、別のWebサイトからロードされた場合、クライアントブラウザーがキャッシュからスクリプトを完全に満たせるようにするためです。ほとんどのユーザーにとっては、キャッシュから解決されるため、jquery.jsがサーバーで（再検証することすらありません）ヒットすることはありません。
スクリプトをダウンロードするためにURLにアクセスするときに、クライアントのブラウザーがデフォルトで送信する識別可能な情報を制御します。あなたはリファラーヘッダーなしでそれを打つことができ、ETagなどと同じようにCookieを送信または保存しないでください。私はこれらのことのデフォルトが許可されていることを意味する「no-」の使用を示しています許可されない限り。 「いいえ」は、消費するWebサイトが取得できる情報制御の種類を示すためのものです。
これが発生するまで、JSをWebサイトにコピーしてください（監査した後）
私には、CC処理ページでウィジェットを許可することに固有のリスクはありません。これらのページにさまざまなスニペット（Googleアナリティクスなど）を使用しているサイトはたくさんあります。あなたのコードはnlessの形式のCC情報にアクセスできません。とにかくそうするようにコード化されています。加えて、コードは悪意を持って変更されないようにサーバーにある必要があります。