序文
支払いの抜け穴についての誰もが理解しているのは、通常、価格を改ざんすることです。支払いの抜け穴の既存の要約も、いくつかの既存のケースの経験的な分類であり、オンライン支払いプロセスの詳細な分析のレベルには達していません。ここでは、オンライン決済プロセスとオンライン決済ベンダーのアクセス方法を分析し、オンライン取引プロセス全体で発生する可能性のあるセキュリティ問題の詳細なビジネス分析を試みます。
Alipay /オンライン支払いプロセス
Alipay即時支払いインターフェースの開発プロセス
オンライン支払いは機能的にAlipayの支払いチャネルを介して行われ、支払人はAlipayアカウントを持っている別の受取人に直接送金します。全体のプロセスは次のように説明されています：Alipayドキュメントからの引用。
(1)构造请求数据
商户根据支付宝提供的接口规则，通过程序生成得到签名结果及要传输给支付宝的数据集合。
(2)发送请求数据
把构造完成的数据集合，通过页面链接跳转或表单提交的方式传递给支付宝。
(3)支付宝对请求数据进行处理
支付宝得到这些集合后，会先进行安全校验等验证，一系列验证通过后便会处理这次发送过来的数据请求。
(4)返回处理的结果数据
对于处理完成的交易，支付宝会以两种方式把数据反馈给商户网站。
程序上自动进行重新构造URL地址链接，在用户当前页面上通过自动跳转的方式跳回商户在请求时设定好的页面路径地址（参数return_url，如果商户没有设定，则不会进行该操作）
支付宝服务器主动发起通知，调用商户在请求时设定好的页面路径（参数notify_url，如果商户没有设定，则不会进行该操作）。
(5)对获取的返回结果数据进行处理
商户在同步通知处理页面（参数return_url指定页面文件）或服务器异步通知页面（参数notify_url指定页面文件）获取支付宝返回的结果数据后，可以结合自身网站的业务逻辑进行数据处理（如：订单更新、自动充值到会员账号中等）。
ビジネス思考
あなたはこのプロセスを通して知ることができます。アプリケーション側には2つの重要なステップがあります。1つは支払い要求をつなぎ合わせてユーザーのブラウザに返すことです。ユーザーブラウザはAlipayインターフェースに支払いプロセスに入るように要求します。支払いリンク全体はAlipayと対話することです。支払いが完了すると、Alipayは通知を送信します。インターフェースは、支払いが成功したという通知をアプリケーションに送信します。アプリケーションは、Alipayの通知情報を使用して、支払いが成功したかどうかを判断します。
リスク分析
まず、2番目のステップはリクエストデータを送信することです。この手順はユーザーのブラウザ側で実行されますが。ただし、支払いインターフェースには整合性を確保するための必須の署名があるため、署名キーが漏洩しない限り、ここのデータを改ざんすることはできません。したがって、通常見られる支払いの脆弱性が最初のステップであり、アプリケーションがリクエストデータを作成するときに発生する欠陥です。
トランザクションのビジネス機能の場合、アプリケーションは、支払いに必要なすべてのデータを満たすために、ユーザーが製品IDと製品数量を提供するだけで済みます。この場所で発生しやすい主な問題は次のとおりです。
1.注文の合計金額をクライアントから直接取得し、作成されたリクエストトランザクションデータに入れます。
2.製品IDと数量のみが渡されますが、ホワイトリストによって数量が制限されないため、負の数または大きな数が入力され、計算オーバーフローが発生し、最終的な計算注文量にエラーが発生する可能性があります。
3.製品の数量と製品IDに加えて、貨物など、クライアントから取得した注文量の計算に関連する他のパラメーターがあります。
3番目と4番目のステップはAlipayによって処理されるため、問題はありません。5番目のステップであるAlipayは、支払いが成功したことをアプリケーションユーザーに通知します。ここで、Alipayはnotify_idサプライを設計して、通知情報が有効かどうかを確認します。ただし、このステップのデータも署名されているため、通常、人が使用することはめったにありません。アプリケーションがAlipayの通知情報に対して署名検証を実行する限り。ただし、この検証は、署名検証のためにAlipayによって制御される2番目のステップとは異なり、アプリケーション自体によって制御されます。したがって、アプリケーションがAlipay通知情報の署名を検証しないと、Alipayの偽造につながります。通知情報と成功した支払いの脆弱性のアプリケーションを欺く。この種の問題のケースは比較的少ないです。たとえば、私がテスラを1元で購入した方法。このタイプの問題も比較的一般的であるはずです。このロジックのテストでは十分な注意が払われていない可能性があります。
したがって、オンライン決済プロセス全体を分析すると、決済の抜け穴が発生しやすいポイントが2つあり、1つは決済リクエストを作成する段階であり、もう1つは返された結果データを処理する段階であることがわかります。署名を確認しないと、リクエストフォージェリ攻撃とリプレイ攻撃が発生します。ここでの分析は典型的な支払いプロセスです。さらに、注文を変更できる関数の設計など、より複雑なトランザクション設計がいくつかあります。関数が増えるにつれて、いくつかのセキュリティ問題が発生します。
安全な設計スキーム：
クライアントから製品IDと数量のみを取得し、数量範囲を制限します。Alipay通知を受け入れるインターフェースは、通知情報の署名検証を実行し、支払い金額を注文金額と比較し、リプレイ攻撃を回避するために支払い注文番号を検証します。これらの問題が考慮されている限り、比較的安全な支払いプロセスを設計できます。
Alipayが提供する検証方法
notifyid
total_fee
sign
order_no anti-replay