3

I'm using the standard php paypal form for payments on my e-commerce app.

I noticed that people with just firebug can change the paypal form data before sending the request for paying by the "PAY NOW" button.

So I'm wondering, is it a "standard" to have a payment's form that can be "edited" by a newbie :/ ?

What we can do to prevent this?

itsme
  • 48,972
  • 96
  • 224
  • 345

2 Answers2

4

I disagree; I do think it's something you should prevent in the first place. The amount a buyer should pay shouldn't be publicly sent over the internet. The time where we could get away with that is long past.

Additionally, a check will not prevent the transaction from going through for a different amount. It'll only prevent any post-transaction drama.
And yes, you should definitely run checks after the transaction has completed, but that should happen even if someone weren't able to manipulate the amount theoretically.

There are several options, you can choose what suits you best depending on your requirements,

  1. Do nothing and only implement a post-transaction check (e.g. with IPN).
    The easiest. Your PayPal integration will look shabby from a code point of view, and you'll still get all those $0.01 fraudulent transactions.

  2. Tick the 'Host button with PayPal' option in the button generator, and use PayPal's BMUpdateButton API to dynamically alter the amount of the button.
    An example request for BMUpdateButton would look as follows:

    USER=Your API username
    PWD=Your API password
    SIGNATURE=Your API signature
    METHOD=BMUpdateButton
    VERSION=82.0
    HOSTEDUBTTONID=The value of
    BUTTONTYPE=The type of button. E.g. BUYNOW
    BUTTONCODE=The type of code you want to get back. E.g. HOSTED
    L_BUTTONVAR0=amount=The new amount with a period as separator
    L_BUTTONVAR1=item_name=Optional: a new item name if you wish

  3. Use both the BMCreateButton and BMUpdateButton API's to both create and update your buttons with PayPal.
    You could also use the BMCreateButton API to create a new button, or use the BMButtonSearch API to search through a list of all your stored hosted buttons (to find the hosted_button_id of your button automatically, for example).

  4. Implement PayPal Express Checkout instead
    It may be the 'hardest' to implement as it consists of 2-3 API calls for a single transaction, it's also the most flexible. Where with Website Payments Standard (the 'buttons') the transaction is finalized as soon as the buyer clicks on 'Pay now', Express Checkout lets the buyer 'agree' to the transaction on the PayPal website, and you can finalize it at any time 0 - 3 hours after the buyer initially agreed to the payment by calling the DoExpressCheckoutPayment API call.
    For a quick rundown on integrating Express Checkout, see my answer on Checkout my order basket with PayPal

Community
  • 1
  • 1
Robert
  • 19,326
  • 3
  • 58
  • 59
1

This isn't a huge security risk, as you should be checking what was actually paid anyway! Anyone can post data to anything. It has little to do with your form, or even Firebug.

You can store that button information on PayPal's server, but then it cannot be dynamically generated. There is an option for this when you use their wizard to create the button code for you.

Brad
  • 159,648
  • 54
  • 349
  • 530
  • well i think too it's not a big security risk , is just to be more comfortable and you're right ! thx – itsme Nov 14 '11 at 15:45
  • Why the downvote? How is my answer wrong? – Brad Nov 14 '11 at 20:16
  • downvote? i instantly voted up and checked answer :O – itsme Nov 14 '11 at 23:30
  • @Brad: Sorry, that was me, figured my answer below would explain why. The reason I downvoted it, is because it's bad advice, plain and simple. You're basically promoting the sending of transactional data in plain sight. That's not only bad advice, it also creates a dangerous mindset if that's how a merchant / developer starts to think about the payment solution on his eCommerce website. It's like saying "oh, that Steam leak isn't so bad, all card data was encrypted", but it's the removal of one barrier (access to the data in the first place) that is the first disaster. – Robert Nov 15 '11 at 00:03
  • Oh, and don't forget the potential problems with your PayPal account, when scammers start processing hundreds of $0.01 transactions through your account with stolen cards. To recap; in short, I downvoted because I am a strong believer of checking both input as well as output, rather than just output (post-transaction paid amount) – Robert Nov 15 '11 at 00:06
  • And "You can store that button information on PayPal's server, but then it cannot be dynamically generated." is plainly wrong, as can be seen in option #2 and #3 in my answer below. – Robert Nov 15 '11 at 00:08
  • @Robert, Fair enough, but your method won't stop anyone from sending payments to his PayPal account. They don't have to use his forms to do it. – Brad Nov 15 '11 at 00:55
  • @Brad: Profile > Payment Receiving Preferences > Block payments initiated from the 'Send money' tab. But you're correct; you can never stop anyone from sending you money. The key difference, is that with an insecure form, you're inviting people to try and run fraudulent orders, whereas if they would send you $0.01 payments via a manually crafted form, you are personally being targeted. – Robert Nov 15 '11 at 17:00