[Security] Webhook and response handler trust without signature/hash verification

[chromonav]

Branch

• dev

Evidence

• easebuzz/api.py#L3-L7
• easebuzz/easebuzz/doctype/easebuzz_settings/easebuzz_settings.py#L107-L127

webhook_handler accepts guest input and directly calls handle_response(data).
handle_response authorizes payment based only on fields like status, udf1, udf2, txnid and does not verify Easebuzz signature/hash.

Problem

Callback/webhook processing is missing authenticity checks. A forged payload with status=success can trigger payment authorization.

Risk/Impact

• Unauthorized completion of Payment Request.
• Financial reconciliation mismatch and fraud exposure.
• Replay attacks possible (same payload can be sent repeatedly).

Replication suggestion

1. Pick a valid Payment Request doctype/name pair.
2. Send guest request to webhook/success flow with:
   • status=success
   • udf1=<Payment Request Doctype>
   • udf2=<Payment Request Name>
   • txnid=<any value>
3. Observe on_payment_authorized(status="Completed") being executed.

Expected: callback should reject payload without valid gateway hash/signature and replay checks.
Actual: callback uses plain field values and proceeds.

Resolution suggestion

• Validate callback hash/signature using Easebuzz verification logic (server-side salt).
• Persist and enforce idempotency/replay protection (txnid + gateway reference uniqueness).
• Reject mismatched amount/currency/order references before state transition.
• Make handler return explicit failure for invalid payloads and log security event.

Acceptance criteria

• Invalid or unsigned callback payloads cannot authorize payment.
• Replayed callback payloads do not create duplicate state transitions.
• Authorization path validates transaction metadata (amount/order/reference) against stored request.
• Security tests cover forged and replayed callbacks.