Hi everyone,

i don't know if i'm missing something here but i think this could but a really big problem with the paypal.module.

as the paypal.module passes the transaction details to paypal via the URL it means that users can change details, [ie. the price]. I've tried it and i was able to change the price and the transaction was marked as complete.

possible solutions:
1. Send the vars to paypal via POST not in the url [i noticed the paypal framework does this].
2. Check the payment gross matches the gross var sent back from paypal [in the paypal_ipn function] and only mark transaction as complete if it does.

i'm gonna have a go at the POST method.

cheers
Tom

Comments

cybermalandro’s picture

cybermalandro commented

You could still modify POST vars through something like Temper data.

thomjjames’s picture

thomjjames commented

People maybe able to hack POST vars too, but surely that would be harder than simply changing the price in the URL!??

does anyone out there have experience of encrypting the data that is sent to paypal??

i've experimented with the POST method. I can get the info sent to paypal but it doesn't want to redirect to paypal after, which is essential.

i think this is a major fault with paypal, but hopefully we can fix something to make it harder to hack payments.

cheers
Tom

neclimdul’s picture

neclimdul
He/Him
commented

To me, the proper fix is just to confirm the amount prior to marking the payment complete. The payment confirmation is done by communicating directly to the paypal server when we get an IPN so this is the only place we can avoid user interaction(sure internet traffic isn't 100% safe but the user doesn't have easy access to it). So if the payment amount is less than the transaction amount we don't complete the transaction. In this case, if the user is trying to cheat the system we can flag the transaction.

thomjjames’s picture

thomjjames commented

Thanks neclimdul,

i'd pretty much come to that conclusion too, i just wanted to see how other people handled this.

you said you flag the potentially bad payments, what measures do you take when you get one??
I was thinking of emailing the user saying that the payment was not completed and also inserting a watchdog message for admin.

also do you give the customer a chance to complete the payment or just delete the transaction as they tried to cheat the system??

thanks
Tom

neclimdul’s picture

neclimdul
He/Him
commented

I would do the watchdog and email. Deleting it would be bad because you have taken money. I would probably also email the site admin so they can check paypal and confirm the discrepency and follow up with the user to correct the problem.

Briang’s picture

Briang commented

Don't trust Post! There is a firefox toolbar that can change posts into gets, so any security risk in Get is the same in Post.

here's the tool bar I'm talking about:

https://addons.mozilla.org/firefox/60/

deadmalc’s picture

deadmalc commented

I am still bemused how people consider POST "more secure" than GET, it isn't any different AT ALL from a security point of view.
POST is better simply from the point of view that it looks neater.
I hack payment forms at least 10 times a day, and alter the POST values for testing purposes, I'll have to get that firefox plugin - it will make my life a whole lot easier.

The only way to make this better would be to use tokens or a hash to verify data at both ends, as you can always fake the result coming back from paypal!

And just in case anyone thinks https is secure, it is not. HTTPS _only_ secures data transmission, it does not secure anything else.

budda’s picture

budda
Primary language English
Location Cheshire
commented

To add security to online payments, merchants can create Encrypted Website Payment (EWP)
button code using standard public-key encryption. With public and private keys, merchants
can dynamically encrypt payment information before it is sent to PayPal.

Why not use this?

Integration deails are provided in the standard guide - https://www.sandbox.paypal.com/en_GB/pdf/PP_WebsitePaymentsStandard_Inte...

gordon’s picture

gordon commented

I have taken a look, and I think that we can't use it because it required a tool that we cannot run at the time of the transaction to encrypt the post.

Please let me know if I am wrong.

I was thinking about making a small change that will check the payment amount of the IPN, and make sure that the payment is equal to or greater than the transaction price.

If the payment is not equal to the transaction amount it will send the admin a email telling them this.

neclimdul’s picture

neclimdul
He/Him
commented
Component: paypal.module » -- other --

It might be nice to look at the EWP stuff in the future (postponed feature request?) but a simple fix for right now would be the IPN amount comparison email thing. I'd say this would be wanted in either case.

From what I can tell the only requirements are openssl support in php(and maybe curl. still digging through sdk to see if that's for PPP). You can generate openssl certs easy enough without access to a shell on your webhost. Linux distro's almost always come with openssl installed I believe and a quick google search came up with this.
http://www.openssl.org/related/binaries.html
So I think its definetly something to look at as an option for the paypal module in the future.

sime’s picture

sime
any/any
Location Melbourne
commented
Component: -- other -- » paypal
Status: Active » Closed (won't fix)

looking dicey Dr Nick.