Kenneth Downs wrote:
> Richard Huxton wrote:
>> 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.
>>
> I think this is the answer that I need. This goes to the heart of how
> the user connects to PG. The key concept that I'm taking away from your
> answer is that instead of connecting as a powerful user, connect as a
> severely limited user who can do only one thing: make that insert. The
> rest should be conducted from there.
Ah, that's exactly what I was trying to say. Apologies if I phrased it
badly, but you seem to have the gist anyway.
> I can put some rules on the receipts table that require the row to
> contain various hashes and verification codes obtained from the invoice
> table, and the user who inserts to this table must have no ability to
> read any other table in the system, so they cannot obtain the codes by
> any means. In converse, I believe normal users should not be able to
> read or write this table, it would be completely invisible to your
> average Joe.
You might want to allow inserts and have a "validated" flag that you can
check. Failing that, make sure you log the values on a failed insert -
always useful to have an audit trail if there are problems.
--
Richard Huxton
Archonet Ltd