Security: enforce payment ownership in the status-polling AJAX endpoint#1372
Security: enforce payment ownership in the status-polling AJAX endpoint#1372vuckro wants to merge 1 commit into
Conversation
ajax_check_payment_status() looked a payment up by its hash and then disclosed its status and called the gateway's verify_and_complete_payment() with no ownership check. The payment hash is a reversible identifier and the 'wu_payment_status_poll' nonce is a single static value localised into every checkout/thank-you page, so neither restricts which payment a caller may target. Any logged-in user could therefore poll arbitrary payments and trigger gateway verification on them. Require the current customer to own the payment (or be a network admin) before proceeding, returning the same generic "not found" response on mismatch to avoid leaking which payment ids exist. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe pull request adds authorization enforcement to the payment status AJAX handler. After validating the nonce and loading the payment, the handler now retrieves the current customer and verifies ownership by comparing customer IDs. Unauthorized requests receive a "Payment not found" error response. ChangesPayment Ownership Authorization
🎯 2 (Simple) | ⏱️ ~12 minutes
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Gateway_Manager::ajax_check_payment_status()looked a payment up by its hashand then disclosed its status and called the gateway's
verify_and_complete_payment()with no ownership check. The payment hash isa reversible identifier, and the
wu_payment_status_pollnonce is a singlestatic value localised into every checkout/thank-you page, so neither restricts
which payment a caller may target — any logged-in user could poll arbitrary
payments and trigger gateway verification on them (IDOR).
Changes
Require the current customer to own the payment (or be a network admin) before
proceeding, returning the same generic "not found" response on mismatch so the
endpoint doesn't reveal which payment ids exist.
Compatibility
The legitimate caller is the customer who just checked out, polling their own
payment — unaffected. No API/DB changes.
Part of a small series of focused security hardening PRs. Full technical detail
is available privately to the maintainers on request (coordinated disclosure).
Summary by CodeRabbit