1

支払いを受け取るためのシンプルなストアを実装しています。ホスト型ストアソリューションを使用しています。それが機能する方法は次のとおりです。

  • 私のページは、ショッピングカートの作成を処理します。お金を稼ぐ時間になると、私のページはホストされているストアにリダイレクトされます。
  • ホストされたストアがトランザクションを処理します。
  • ホストされているストアは、結果とともに私にリダイレクトします。

トランザクションができるだけスムーズかつ安全に実行されるようにしたいと思います。ストアのドキュメントにより、プロセスは非常に単純に見えます。ストアプロバイダーに実際に送信する必要があるものはすべて、ドキュメントから取得した以下のとおりです。

<FORM METHOD="POST" ACTION="https://www.fakehostedstore.com/xxx/index.php">
    <INPUT TYPE="HIDDEN" NAME="store_id" VALUE="abcdefg">
    <INPUT TYPE="HIDDEN" NAME="store_key" VALUE="hijklmnop">
    <INPUT TYPE="HIDDEN" NAME="charge_total" VALUE="100.00">

    <!--MORE OPTIONAL VARIABLES CAN BE DEFINED HERE -->

    <INPUT TYPE="SUBMIT" NAME="SUBMIT" VALUE="Click to proceed to Secure Page">
</FORM>

これは私にいくらか心配しています。たとえば、Firebugのようなものを開いた場合、フォームを送信する前に「charge_total」を好きなように変更できます。非常に迅速に、店舗に送金する料金を「100.00」から「10.00」に減らすことができました。請求を行う店舗は賢明ではなく、誤った請求を続行します。

ストアでトランザクションが完了すると、ストアは正常に請求された金額を送り返します。その後、予想される料金と照合できます。たとえば、私は100ドルの請求を期待していましたが、10ドルしか請求されませんでした、WTF！

改ざんされにくいようにこのフォームを保護する方法はありますか？

4

2 に答える 2

1

彼らが支払いの処理方法を変更しない限り、あなたはそれで何もできないと思います（たとえば、あなたが彼らのサービスに固定価格で製品を登録し、彼らがあなたに製品IDを返し、ユーザーが番号を入力するなど）彼女が購入したいアイテムの数、そして彼らは彼らの側で合計価格を計算します）。

彼らはあなたにサービスからいくつかのデータ（取られた量のような）を送り返しますか？銀行口座にお金が表示されるのを待つ以外に、ユーザーが支払った金額（応答値、一部のAPI呼び出しなど）を確認する可能性はありますか？そうでない場合、それらの設計には重大な欠陥があります。

改ざんに関しては、パワーユーザーが値を変更するのを防ぐために実際に何もすることはできません。必ずしもブラウザレベルで実行する必要はありません。彼女はFiddlerのようなプロキシを使用してHTTPリクエストを改ざんすることができます。

しかし、それを心配する必要があるかどうかは、何をどのように販売するかによって異なります。それが（インターネットリソースへのアクセスを提供するなどの）即時販売プラットフォームである場合、それは悪いことです。ショップが郵便で物を送る金物店の場合、受け取った金額を毎回確認して、予想された金額と比較することができます（銀行口座での入金を調べるための自動化されたツールがあると思います。通常、アカウントにお金があることがわかるまで、ユーザーに送金することはありません）。

いつかどこかで（おそらくSOで）読んだ同じようなことをすぐに思い出しました。初期のインターネットショップでは、「数量」フィールドに0.01のようなものを入力でき、サーバーでは価格を入力できることがありました。数量が整数に丸められている間に乗算することによって計算されました（したがって、0.01の実際の価格を支払いました！）。

編集：彼らは彼らが与える応答に関する文書を持っていますか？偽の取引を試みましたか？

編集2：店はあなたに請求された金額を返すので、それは良いことです。ただし、これでもショップに問題（技術的ではない）が発生する可能性があります。これは、引き続き料金が請求されるためです。次の画面に情報を表示して、受け取った金額が10分の1になったことを示すことができますが、それでもそのお金を詐欺師に返還する必要があります（そうでない場合は違法になります）。

ショップがメッセージ認証コードのある種の処理を提供していないのは残念です。実際、この種のチートを正確に防ぐ良い方法があります。ただし、両方のサーバーがこれに協力する必要があります。

HMACを見てください。複雑に見えますが、考え方は単純です。簡略化したアルゴリズムで説明します。

たとえば、入力がありますprice=100。あなたはそれをサードパーティに渡します。現時点では、改ざんされやすいです。ただし、追加のフィールドを送信するとしますprice_verification。これは、事前に合意されたソルトを使用した事前に合意されたハッシュ関数を使用して計算できます（ユーザーと支払いサーバーの両方がそれを知っている必要があります）。次に、計算して言いprice_verification=SHA1(price + someLengthySalt)、支払いサーバーに送信します。彼らはアルゴリズムとソルトを知っているので、を計算しSHA1(received_price + someLengthySalt)ます。2つが異なる場合、ユーザーは詐欺師であり、トランザクションを中止します。もちろん、これは、ユーザーがアルゴリズムやソルトを知らない限り安全であるため、簡単に計算することはできませんprice_verification。

ただし、塩は非常に強力である必要があり、アルゴリズムはおそらくもっと複雑SHA1(SHA1(price)+salt)です。価格の入力スペースが非常に小さいことを考慮する必要があります（小数点以下2桁の数字のみ、塩がない場合は簡単にブルートフォース攻撃を受ける可能性があります）。

これは、任意の数のパラメーターを検証するために簡単に拡張できます（データのシリアル化方法について合意する必要があります）。

于 2012-08-16T21:01:24.227 に答える
0

私は、ストアがこの潜在的なセキュリティ問題の処理をどのように提案したかについて言及したいと思いました。おそらくこれは、安全なホスト型ストアページを実装している他の人にも当てはまります。

ストアでは、支払いを行う2つの方法を提供しています。最初の「購入」は、すぐにクレジットカードからお金を受け取ります。これが私が使っていた方法でした。実装は簡単でしたが、カードに適切な金額が請求されたという保証はありませんでした。

2番目の「preauth」はカードのお金を保留しますが、追加の「キャプチャ」トランザクションが実行されるまでお金を受け取りません。このステップを追加することにより、カードを正式に請求する前に、事前承認された請求を確認することができます。請求が無効な場合は、カードの保留を解除することもできます。

私の場合、「キャプチャ」トランザクションをすぐに実行していますが、会計士が1日の「事前認証」をすべてまとめて「キャプチャ」することは可能です。

于 2012-08-29T17:39:46.880 に答える