ブラウザを使用AJAXプロセッサでクレジットカードトランザクションを開始するには？

Question

購入や寄付などができるウェブサイトがあるとします。

ウェブサイト全体はhttpsで提供されます。

購入に関する情報（アイテム、数量、価格）とユーザー（名前、住所、電子メール）をデータベースに保存しています。ユーザーがクレジットカード情報を入力する最後のページは、AJAX呼び出しを送信して、この購入のデータとAPIキーを取得します。これが返されたら、クレジットと一緒に送信します。ユーザーがこのページでAJAX=を介して支払いプロセッサに送信したカード情報（Authorize.netなど））。

クレジットカード情報がサーバーにアクセスすることはありません。

これは安全でしょうか？それは私には思えませんが、攻撃ベクトルを特定することはできません。

Bobson · Accepted Answer

クライアントブラウザを信頼しないでください。

このモデルに基づいて私が見ることができる4つの主要な攻撃ベクトルがあります。

1）漏洩した認証情報

まず、@ JuliePelletier コメントのように、これが機能するためには、Authorize.Netへの「このカードへの請求」呼び出しを行うために必要なすべての情報が、顧客のWebブラウザーで利用できる必要があります。これには、プロセッサーに対してユーザーを識別するために必要な安全な資格情報が含まれます。それらを手に入れれば、誰でも同じAJAX Authorize.Netに投稿してカードに請求できます。さらに悪いことに、アカウントからカードにrefund）できます。

2）変更された注文データ

第2に、@ Jay コメントのように、このスキームでは、プロセッサーに到達する前にユーザーのブラウザーを通過する注文に関するすべての情報が必要です。ユーザーが「注文データの取得」の返却から「支払いデータの送信」の呼び出しまでの間にJavaScriptにブレークポイントを設定し、送信される変数を変更するのは簡単です。（すべての最新のブラウザーは、組み込みの開発者ツールでこれをサポートしています。）これにより、ユーザーは5000ドル相当のものを注文し、カードを0.01ドルで正常に請求できます。承認された金額を明示的に確認しない限り、支払いが正常に行われ、4999.99ドルであることがわかります。承認済みの金額チェックを追加した場合でも、トランザクションを無効にし（追加料金が発生する可能性があります）、システムで注文をキャンセルし、何らかの形でユーザーにそれを通知する必要があります。

また、改ざんチェックがあっても、そのためのアルゴリズムはAuthorize.Netの公式ドキュメントの一部になります。 not Javascriptで使用できるようにする秘密キーが関係しない限り（ポイント1を参照）、変更を加えた後でチェックを再計算するだけで十分です。また、改ざんチェックがカードデータが変更されていないことも検証することになっている場合、JavaScriptで利用できるようにしない限り、これを行う方法はありません。

3）なりすましの応答

ポイント2からの承認された金額チェックに関連して、あなたのAJAX呼び出しは、システムの注文を更新する前にAuthorize.Netからのある種の「承認された」応答を期待することになります。支払済み。ユーザーがプロセッサへの呼び出しをスキップしてその応答を完全に偽装することを妨げるものは何もありません。そうすると、あなたは支払われたと思いますが、今ではその記録はなく、失敗した試みもありません。

4）ハイジャックされた通話

最後に、これらのいずれも、ユーザーのデータを乗っ取る悪意のあるブラウザープラグインに対する保護を提供しません。ユーザーがカードデータを入力するときにカードデータをスクレイピングしてロシア（またはどこでも）のサーバーに送信することを防ぐことはできませんが、AJAXをインターセプトするものに対する保護はありません。 = POST、すべてをそのサーバーにリダイレクトし（資格情報とカードデータを含む）、それをAuthorize.Net自体に渡すか、ユーザーが再試行できるようにエラーをシミュレートします。

これは別の攻撃方法によるものですが、この記事は、同様の影響を与えた最近の違反について説明しています。その場合、サーバーは悪意を持って変更されたスクリプトを処理していたため、最初にカードデータがサーバーにPOSTされ、thenがプロセッサに送信されました。

消費者の観点から見ると、iFrameに入力されたデータは消え、顧客は空のiFrameを残して、再び完了します。お客様は、Webページに問題があると想定し、2回目の試行で支払いサービスプロバイダーに直接送信される支払いの詳細を再入力して送信すると予想されます。

あなたのサイトは同様の振る舞いをします-悪意のあるスクリプトはPOST他の場所にあり、Authorize.Netの「再試行してください」というエラーを表示してからそれ自体を削除します。疑わしいユーザーは再送信します。、そしてそれは通り抜け、あなたや彼らに何か不都合なことが起こったという兆候はありません。

安全な方法

これらすべての問題（4の一部を除く）に対処する安全な方法は、代わりにユーザーにPOST彼らのカードデータをサーバーに送信することです。その後、サーバーはAuthorize.Netにリクエストを送信します。これは、次のようにすべてのポイントに対処します。

バックエンドからプロセッサにリクエストを送信することにより、資格情報がユーザーに公開されることはありません。これには、2の改ざんチェックに必要な秘密データも含まれます。
データベースから直接データをプルして送信することにより、クライアントがデータを変更する可能性がないため、送信したいデータであることが確実になります。
エンドユーザーが表示または傍受できない方法でAuthorize.Netを呼び出しているため、偽の応答が返されることを心配する必要はありません。
自分のサーバーにPOSTしても、悪意のあるプラグインがユーザーのデータを入力するときに、ユーザーのデータをこすり落とすのを防ぐことはできません。そのためにできることは何もありません。さらに、悪意のあるプラグインがあなたのページをPOSTインターネット上の他のランダムなサーバーに変更する）を防ぐ良い方法はまだありません。しかし、あなたはcanサーバーにデータをポストするIPアドレスが、最初に作成された注文と同じであることを確認します。偽造防止/ XSS防止トークンを使用して、他のサーバーがPOST =あなたに。

カードデータをサーバーに送信しているので、すべてのことはPCIスコープの下にあるはずです。これが要約ですですが、基本的にはA-EP（Direct POST）からD-Merchantに移行しています。カードのデータをすぐに渡し、それを保存しない場合でも、その範囲内にいます。つまり、認定に合格するのが簡単になります。

代替

範囲外の安全な方法としては、支払い画面全体を別のサイト（Paypalなど）に外部委託する方法があります。これは実際にはreduceカードのデータとのやり取りがさらに少ないため、PCIレベルであり、これらすべてのセキュリティ問題の処理も外部委託します。

Bryan Field · Answer

問題の一部は、ユーザーが最初の呼び出しからの応答を2番目の呼び出しの前に傍受できるかどうかです。

その答えは絶対です、はい。

この設定を安全にするには、暗号化スキームが必要です。

金額およびトランザクションアクション（販売、払い戻しなど）は、暗号化されるか、変更を防ぐために秘密の値と組み合わせて上記の情報のチェックサムを伴う必要があります。
APIキーは暗号化する（秘密に保持する）必要があります。そうでない場合、プロセッサには、補足の秘密値の安全なハッシュを添付する必要があります。（つまり、長いランダムを組み合わせたハッシュPIN量とアクションおよびその他の識別情報と）
プロセッサ（Authorize.Netなど）は、リプレイ攻撃から保護する必要があります。
プロセッサは、使用を検討する前に、これを推奨アプローチとしてサポートする必要があります。 プロセッサのドキュメントを確認してください。また、テクニカルサポートへの問い合わせについて、いくつかの質問をまとめて入手することもできます。

彼らがこのアプローチをサポートしている場合、Access-Control-Allow-Originを応答ヘッダーとして使用することで、WebサイトのJavaScriptがAJAX要求の応答を確認し、請求が承認されたかどうかをユーザーに通知できます。

これらの条件が満たされていれば、データの完全性とデータのセキュリティの観点から、ブラウザにプロセッサへのリクエストを開始させることができます。

ただし、注文を完了する前に、何らかの方法で請求が行われたかどうかを確認するを行う必要があります。 1つのオプションは、ブラウザがプロセッサの応答を受け取り、次にanother AJAX Webサイトへのリクエストを実行して、トランザクションが成功したことを通知することです。この新しいAJAXリクエストでは、適切な暗号化またはチェックサム検証がプロセッサーによって書き込まれ、ブラウザーレベルで変更されていないことを確認するためにWebサイトによって検証される必要があります。

これはさらに別のAJAXリクエストであるため、Webサイトによってこれは受信されない可能性がありますです。この場合、販売者に入金されます。確認済みの注文が関連付けられていないアカウント。

プログラマの間違い
インターネット接続が悪い
ウェブサイトでのサーバーエラー（データベースのクラッシュなど）
ユーザー改ざん

1つの解決策は、受け入れた注文で入ってくる資金を調整することです。（とにかくこれを行う必要があります）

サーバー機器にクレジットカード情報を渡す（保存しない）ことである、より一般的なアプローチをとる場合、

上記の不十分なインターネット接続とユーザー改ざんの警告を解決します（間違いやエラーが発生した場合でも調整する必要があります）
使用しているプロセッサの詳細を非表示にします
暗号化/ハッシュおよびリプレイアタック防止スキームをあまり確認する必要がないため、セキュリティの考慮事項が簡素化されます。
（侵害された場合）偽造トランザクションを許可する暗号化スキームを妨害するために使用される可能性のある秘密値の数と公開使用を減らすことにより、責任を軽減します。

両方の場合（通過するがストアではないおよびサーバーは決してアクセスしない）、適切に実装されている（およびシークレットが侵害されていない）場合、次の条件が当てはまります。

何も保存されていなかったためにハッカーがサーバーに違反した場合、潜在的なハッカーはすぐにデータにアクセスできません。
潜在的なハッカーは、サーバー機器のソフトウェアを調整して、機密のクレジットカードデータのロギングを開始する可能性があります。（つまり、AJAXリクエストを開始するJavaScriptファイルは、クレジットカードデータに触れていなくても変更される可能性があります）

つまり、カード情報に触れないことで得られるセキュリティゲインは非常に小さい（おそらく存在しない）です。どちらの場合も情報をログに記録しないためです。このため、パスを使用し、ストアを使用しないことをお勧めします。もちろん、それは最終的にあなたが決める決断です。