FAO Ben - Shopping Cart Payment

[osgood_]

You may be able to throw some light or want to throw some on light on the rather interesting thread/s going on in the Wappler forum about 'shopping carts' - data store, etc

Some posters have quite correctly highlighted the issue of sending the 'product price' via the client-side generated js form, as it's been well known for years it is open to manipulation.

Other posters have said you should get and check the price from your database BUT that, as far as I know, makes zero difference as you will always end up with a client-side generated form containing prices BEFORE  it gets sent to your payment gateway - same problem - form prices can be easily manipulated.

The only secure way I know is to send the data from the payment form to the payment gateway of your choice and then get the form variables back from the payment gateway THEN check the prices in your database. If the prices match then you send the variables back to the payment gateway for processing. If the prices don't match then the variables are not sent back to the payment gateway and the payment is rejected, quite a more complex workflow to consider.

Brad seemed to be particularly alarmed by this raised  'security' issue BUT currently his ticket website uses the 'unsecure' process of sending the initial js form data, which anyone can manipulate by looking at the source code or using the browser inspection tools, where the form data can easily be altered.

Obviously this posses issues and makes the whole process far more complex. I've seen developers (including myself) try to disguise the process by inserting the payment form on a 'self-sending' page with just a processing message appearing in the browser but its still easy to stop the browser and gain access to the form code, especiallly in cases where there is a time lag contacting the gateway provider.

Which brings me to the point. How much of an issue is this. Should the seller not be checking their end that they are only sending goods out which match with the orders coming in? I can see a big issue if the product being sold is a digitally download but if the order needs manual overseeing and distributing how much of an issue is it. I mean if I went to a shop and tried to pass over a fiver for something which cost a tenner and the cashier didnt check I'd provided the correct money..........how is the web different, apart form in a few unique circumstances.

Just trying to kick around a few thoughts to be considered on the subject, any thoughts from yourself?

If anyone else wants to chime in please do so.

[BenPleysier]

Hi Os, thank you for sharing this. I was quite amused when I showed an example of a manipulated local storage and the result. I received a barrage (exaggerated) of do's and dont's when it was my intention to illustrate the problem.

I totally agree that the seller should be checking at their end. Problem is that the payment has already gone through and it is a hassle to undo this.

What I have done is to compare the local storage value with that in the database (https://github.com/Wappler/wCart/blob/master/_checkout.html lines 3-7). If there is a discrepancy, the checkout page does not show; instead there is a warning message (lines 23-30). I have also multiplied the amounts by the value of varCheckoutCheck so that, in the case of a manipulation, the sum payable is 0. If in some underhanded way, they still manage to submit the form, the amount paid does not have to be refunded. In this case, as an added bonus, the server action will redirect them to https://bunchoblokes.org/(which needs attention regarding the SSL certificate - tomorrow) (https://github.com/Wappler/wCart/blob/master/dmxConnect/api/orders/checkout.php line 265).

Having fun all the way.

[osgood_]

I guess that would be one option - checking the value in local storage against the price in the database and then not displaying the checkout form if there is some mis-match. Never thought of that, no matter how long you think, always miss the bloomin obvious. I'll have a go at that next time I require a cart on a website. 

Lots of posts/opinions but a lot don't really make many clear suggestions. If prices can be checked before handing them off to the payment gateway then thats going to be a lot simpler than trying to get information back from a payment gateway provider to check against a local database.

[osgood_]

I can't quite get my head around this after thinking upon it.

Even if you check the prices in local storage against the prices in the database and they are correct surely a form containing any variables which need to be passed over to the payment gateway will need to be generated somewhere on the website? What's to stop access to that form at that point, when its passed the price check 'validation'?

What Im saying is either client-side or server-side checking must generate a 'static' html form to send to the payment gateway at some stage in the process, which means that form is accessible at some point before it leaves the website where it was generated.

Which brings me back to the point - I'm of the opinion that the only safe way is to pass the form variables to the payment gateway and then have them passed back to check against the local database information. If correct the local server passes them back to the payment gateway for processing. Paypal IPN is (or was when I used it) a classic example of this kind of workflow. The payment is only processed if certain critera are met but all the checking goes on out-of-reach' of the end-user, no form is generated, so no manipulation can happen.

[pziecina]

Not really a problem Os.

Save the users order in a 'holding' database table. Then once the form is submitted to say paypals ipn, do a comparison of the returned total payment data from paypal with the total cost, (and any other info you wish) using sql transactions. Finally using the same transaction, transfer the clients info, (etc) to the actual orders table, and delete the 'temp' info using the same transaction.

MySQL supports transactions, but as transactions are a database engine function, the db engine must be one that supports them, (2 of the most popular engines do have support).

This is an ideal use of transactions, simply because, if one sql process fails, they all fail, and a reason for the failure is stored in the db log file, so you can trace the problem, (eg. price miss-match).

I know many will not wish to use transactions, as they also require stored procedures, but both are the way forward. Which is why I asked if the team plan on support when the 'planned' database functions are returned to Dw.

[osgood_]

Hi Paula,

Well yes, that's my opinion - you need to send the form data to the payment gateway FIRST before its sent back to check locally NOT check it BEFORE its sent to the payment gateway.

As far as I can see, whatever you do client-side OR server-side BEFORE the information is sent to the payment gateway is still vulnerable to manipulation.

But then Im not really onboard (up-to-date) with all these new API options which have sprung up. Maybe some of them have a more secure way of handing the data so it cant be manipulated BEFORE it gets to the payment gateway.

I've just had a quick look at one Stripe option, which uses js but the price is 'exposed' in the script, so its no more safer than just sending variables in a form. Thats just one option though, it has several, as does Paypal.

[pziecina]

That's why I said to use transactions.

No matter what happens transactions are a db function, so the user can manipulate anything they like client side.

Even if they order multiple items, and manipulate multiple costs, one can do a check using transactions on every single item, so any 'cheating' is immidiately exposed.

Stored procedures with transactions are how banks, enterprises, etc do it, and with good reason. If any discrepencies are found then the db can remove all data from the db that the user has stored, keeping the db structure clean. Plus if a single sp in a transaction fails, for any reason, then the entire transaction rolls back everything, as if it had never happened.

[osgood_]

Well after spending a couple of hours researching the issue it seems its a bigger problem than what it appears to be. I think using db/mysql transactions would most likely require more expertise than your average 'all 2 hands to the pump' developer has at their disposal.

I'm begining to understand why the 'average' product website seems to 'fake' the check-out process by trying to quickly submit the information by auto-submiting a form containing data.

I've done some minor research on stuff like Stripe and watched a couple of 2 year old tutorials where the data is submitted via php, not server-side, which seem easy enough to follow but then when you go out to the Stripe website to gather the required scripts and code its all changed......hmmmm. There doesnt seem to be many up-to-date tutorials and when you do find them they are for node, or python or some other bloody language, which seems to appear on the scene weekly.

Most of the websites I've produced in the past dont require carts, the products are bespoke. I have a handful which just submit the client-side form information and havent had any reports to-date from clients where prices have been manipulated. I guess its a case of them being vigilant as to what orders come in and if they correspond with the money being sent. Small clients probably check and it doesnt pose much problems, whereas bigger clients with more volume of customers and products arent so careful, but then bigger clients can afford to employbetter developers to negate any potential issues.

Digital downloads I see as a major issue as they usually dont go through any manual checking BUT the good news is usually smaller clients selling digital downloads may have only one or two products in which case Paypals 'buy now' button encrypts the payment information, which unfortuanetly you cant do when the information is coming out of a database, unless you want to create 500 unique encrypted buttons and store them in the database, not managable.

Hey, no wonder I've largely given developing websites up these days. It just doesnt interest me any longer now the whole industy is fractured into small groups pulling in different directions, using copious amounts of dubious products and languages - all claiming they have found the ultimate workflow. Dream on! Im looking forward to summer where I'll be out sitting by a lake drinking beer, not sweating blood over a computer.

[pziecina]

As someone who often sits by the lake, drinking beer, (prefer white wine though) I can recommend it Os. After a while one even starts to wonder what was so important or difficult about web development. After all with so many people saying how easy it should be to develop a web site, why bother.

[osgood_]

It becomes a drug. The more you take the more you need. I've been weaning myself off of it over the last 18 months. I still update previous websites I've built over the years but  unless something comes along that interests me I probably won't be building any more from scratch. The last one I built was for a company that produced CNC machine milling/turning, styling metal for high end use in F1, Aerospace, etc - by god did it bore the crap out of me. I guess the company gets a high from it (each to their own) but not really my thing, it has to float my boat these days otherwise - bye-bye.