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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
