Kenneth Downs wrote:
> The last one left that I have is the sticky issue of a paypal IPN
> transaction coming in. I believe it applies generally to financial
> transactions. The user is sent by our application to the Paypal site.
> When they pay, paypal sends a POST with various information that we
> need. The user does not see this, it is behind the scenes. The POST
> request must run as an anonymous user because I have no state
> whatsoever. But the request must also commit financial data. This
> creates a vulnerability, at least in theory.
Well, your POST will be authenticating as some sort of PG user,
presumably. Give it its own account and make sure the only permissions
it has is to insert into the paypal_rcpt table (or call a function that
does it for you). Obviously it will only connect from the webserver(s)
and only from the apache user account (or IIS/whatever). So, you can use
the ~/.pgpass password file to keep that password protected.
Most of these payment systems pass back a reference number you give
them. So if you say this is ref# 123456789 that should come back in the
paypal POST. You'll be checking that this ref and amount match your
order, no?
So - the only danger is that I can post a fake paypal response to your
database. Provided your reference numbers are big enough and not
predictable, it should be straightforward enough to weed out any fakes.
Of course, if you were processing credit-card details yourself, you'd
want to think about it a bit harder, but with PayPal handling the cash
side of things, your customers can't be compromised via your site, only
you can.
--
Richard Huxton
Archonet Ltd