Published on 29th January 2013 – 18 Shevat 5773. Last updated on January 21, 2019.
Today I am going to write about something I have noticed on so many websites and then for it to work and honestly I am so surprised that when I contacted the webmaster of those websites they had NO idea it was even possible. With this in mind I have decided to write this article so if you do not know if you have this issue you are able to check.
First of all for this exploit to work the programmer behind the website needed to have not done any checks when it comes to confirming payments. Normally a payment script works like this.
Website â€“> Cart Page (Takes price from database) â€“> Payment Processor â€“> Website (With PP confirming payment)
So as you can see all that happens is the cart page on the website takes the pricing information and places it into a form on the website (often simply just as a hidden field) which then passes all that on via POST to a payment processor such as PayPal or 2checkout. Once on the payment processor they fill in all their details and then afterwards the payment processor sends it back to the website (often via POST).
Now we are back on the website it is up to a script to decide what to do. Most payment processors tend to send the following information back.
Price of the order (very important but widely overlooked as you will see shortly).
Order ID (so the database is updated).
Transaction ID (so you can link the order ID to a transaction log).
Other important crap that I am not listing.
So as you can see from the bullet points, the first thing I listed is price. What ideally should happen is when the user comes back to the website the script that first check if the order was finished, then check if it was a fraud order and THEN check to make sure the amount they paid compared to how much the order was and it is this step that I have noticed so many people ignore as they seem to expect when someone comes back from the payment processor it must mean they paid.
The problem with this is they did indeed pay but it never the amount you expect. This happens due to the person that is running this exploit is changing the HTML form. This can easily be done by using software but an easy and quick example is Google Chrome.
Now while the example does not show a real payment processor code such as from 2checkout, it shows you how simple it is to edit a bit of HTML and if the website is not checking those values â€“ they will accept it regardless and in this case it would allow people to set their own prices and with your website accepting it and unless you physically check up on those transactions you would never know it happened.
Now if your website is affected by this then you really need to fix it very quickly and fixing it is very easy. All you need to do is check every POST and GET data that is sent to your website. So if your website in these examples records the order price in the database then you want to check that value with the value the checkout gives you (making sure that the request actually comes from the payment processor but that is a different article altogether)
And that is how by changing a simple value that the website is not expecting to be changed will allow you to order products for a cheaper price. It also allows you to mess around with things you are not meant too which ultimately means that if you own a website â€“ MAKE SURE TO CHECK EVERY POST AND GET VARIABLE NOW.