@hungltposted at 2024-09-24

署名なしで Pay.jp の 3D セキュアのコールバックを検証する方法は？

Q&A

現在、Pay.jp の 3D セキュアの実装を進めています。こちらのドキュメントを参考にしています: Pay.jp 3D セキュアドキュメント。- https://pay.jp/docs/charge-tds#redirect

ドキュメントに従って、back_url をセットアップし、3D セキュア認証後のリダイレクトを処理しています。しかし、ユーザーが back_url にリダイレクトされる際に、署名や検証用のトークンが含まれていないことに気付きました。

このリクエストが本当に Pay.jp からのものであり、偽装されたリクエストではないことをどのように確認すればよいのでしょうか？

このリクエストを検証する方法はありますか？それとも設定に何か足りない部分があるのでしょうか？charge_id を手動で Pay.jp の API で確認するべきでしょうか、それともコールバックの信頼性を確保するためのベストプラクティスは他にありますか？

このコールバックを安全に処理するためのアドバイスやヒントがあれば、ぜひ教えてください！

1Answer

張られたURLの

支払いを完了させる

の項目にまさにどうすればいいのか書かれているように見えます

0Like

@hunglt
Questioner
My concern is how I can securely verify that the request coming back to my back_url is indeed from Pay.jp and not from a forged request.
@amate

サーバーから 3D セキュア完了エンドポイントにリクエストします

これで確認するのはダメってことですか？
@hunglt
Questioner
forged request
@amate
https://pay.jp/docs/charge-tds#redirect
そもそもback_urlはJWS形式で署名が必須のようでした

ユーザーが back_url にリダイレクトされる際に、署名や検証用のトークンが含まれていない

なので、これが間違ってるってことになります
@hunglt
Questioner
I implemented the signature as instructed, but that was only for generating the payment URL. When Pay.jp redirects to the back_url, there is no signature included.
@amate
署名が必要ならback_urlに適当に追加すればいいんじゃないですか？
back_urlは秘密鍵を共有してるpay.jpとあなたのサーバーしか元のURLに復号化できませんから
@hunglt
Questioner
You shouldn't add signature to back_url when generating the payment URL, it still be forged.
@amate
偽造されても検証すればすぐに分かるでしょ？
一体どういうシナリオを心配しているのかさっぱり分かりません
back_urlはpay.jpしか元のURLに戻せないので、偽装されたリクエストにならない時点で話はもう終わっているのでは