0
votes

As many of us did, I am implementing PayPal solution. Reading through the developer documentations, I understand that IPN is the asynchronous message protocol, that triggers payment fulfillments.

PayPal has a official way how to respond to these messages and how to verify the origin of the IPN messages on your IPN listener. Every IPN message the listener receives from PayPal includes a User-Agent HTTPS request header whose value is PayPal IPN ( https://www.paypal.com/ipn ) They highlight that do not use this header to verify that an IPN really came from PayPal and has not been tampered with. Rather, to verify these things, you must use the IPN authentication protocol outlined below, which consists four steps.

  1. PayPal HTTPS POSTs an IPN message to your listener that notifies it of an event.
  2. Your listener returns an empty HTTP 200 response to PayPal.
  3. Your listener HTTPS POSTs the complete, unaltered message back to PayPal; the message must contain the same fields (in the same order) as the original message and be encoded in the same way as the original message.
  4. PayPal sends a single word back - either VERIFIED (if the message matches the original) or INVALID (if the message does not match the original).

Steps 2, 3, 4, and 5 in the diagram below show this protocol.

PayPal IPN Authentication flow

As you can see above, they recommend something, that responds with a single [VERIFIED] of [INVALID] message, to prevent fraud.

My thought is that any fake IPN simulator can post back the "VERIFIED" status message to the listener, so it makes no sense. Therefor, my questions are:

  • Is that solution really safe?
  • if not, what approach could really prevent fraud and make sure payment fulfilment?

I wonder, if we could exchange a secret-key, it would be more reliable.

Every thoughts are welcome. Thanks.

2

2 Answers

0
votes

The safety of the protocol depends on the verification of the TLS certificate of PayPal.

As some CAs have failed to check to whom they issued certificates you can not rely on checking via CA. You should keep a list of PayPal certificates that you trust. Then verify that the used certificate is in the list when connecting. Further choose an encryption method of sufficient strength.

0
votes

The security of this process depends on you sending the verification request to PayPal, rather than to the attacker: which you can accomplish simply by hard-wiring the URL concerned, rather than deriviing it from the request.

Why they didn't just ask you to rely on client certificate authentication is another question, but it's all 20 years old and poorly designed even then.