Price manipulation vulnerability in e-commerce platforms
The tremendous increase in online transactions and the development of e-commerce in the world has been accompanied by an equal rise in the number and type of attacks against the security of online payment systems. From SQL injection vulnerability that targets databases to XSS (Cross-Site scripting) flaws aiming to hijack users’ sensitive information (Session cookie, CSRF tokens etc.). However, this article will focus on another type of issus that I have came across multiple times in different platforms while doing security testings. We will essentially talk about price manipulation vulnerability that is almost completely unique to online shopping carts and payment gateways.
Paying 1$ for a product which in fact costs 200$ is a great opportunity for the customer but terrible for the business owner. In the absence of a fraud detection system, hackers are likely to exploit some web developers mistakes to purchase products at a very cheap price. This is most likely to occur when developers store the price in an HTML hidden field of a dynamically generated web page or in the cookies.
Hidden HTML form fields are a common mechanism for transmitting data via the client in a superficially unmodifiable way. If a field is flagged as hidden, it is not displayed on-screen. However, the field’s name and value are stored within the form and are sent back to the application when the user submits the form. Hence, web parameter tampering attack is possible by manipulating the price using a simple web proxy tool (Tamper data, burpsuite etc.) or by editing the amount using the browser’s web inspector tool.
<form name="send" target="paypal" action="https://www.paypal.com/cgi-bin/webscr" method="post"> <input type="hidden" name="cmd" value="_cart"> <input type="hidden" name="business" value="email@example.com"> <input type="hidden" name="currency_code" value="USD"> <input type="hidden" name="item_name" value="Marketing ebook"> <input type="hidden" name="price" value="24.99"> <input type="hidden" name="add" value="1"> </form>
Notice the form field called price, which is flagged as hidden. This field is sent to the server when the user submits the form and the value can be altered by intercepting this request.
POST /cgi-bin/webscr HTTP/1.1 Host: www.paypal.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:39.0) Gecko/20100101 Firefox/39.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate DNT: 1 Cookie: [REMOVED] Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 99 cmd=_cart&business=user%40example.com¤cy_code=USD&item_name=Marketing+ebook&price=24.99&add=1
Now, I would like to share a proof of concept illustrating how I managed to buy a premium licence that costs 16$ for as little as 0.10$ (Hilarious, isn’t ?) Well, I opted for this case because it’s not as simple as it looks and altering the price value via the source code does not change the real price when you order it.
I kept my burpsuite interception ON and I remarked that after the above request was sent another POST request to PayPal which contains information about the concerned purchase including the price. See:
Without any hesitation, I tampered the price value and put 0.10$ instead of 16.8o$ then forwarded the HTTP request. Next, I was redirected to PayPal payment page, entered my credentials and then completed the payment as you can see below.
Next, I recieved a confirmation via my email stating that my premium pass is activated. I had that DEVIL smile again :v !
Generally, this type of attack works best against high volume websites where each order isn’t getting carefully checked. On a website that gets ten orders a day, most likely someone’s going to look at each order at some point in the day. On the other hand, a site that gets 300 orders a day is much more likely to let the order through. Besides, some purchases cannot just be undo especially when it comes to purchasing a software, an application, digital books etc. while a premium licence may be revoked once the fraud is detected.
Securing your platform from this type of attack is quite simple once you know to look out for it. First, you must remove the price variable from the HTTP headers and cookies entirely. Just have the item number in the HTTP headers and pull up the price from your databse and setup some sort of double-check system, so the price is validated back by the server making sure that the price user paid was actually the price they’re supposed to pay.
PayPal offers some secure solutions for developers. For example, PayPal supports public-key button encryption, so that the relevant details can not be easily altered. This is the way it works:
- You generate a public/private key pair with an appropriate program such as OpenSSL.
- You log in to your PayPal account and submit the public key to PayPal, then store the private key securely on your Web server. You will also need to download PayPal’s certificate and store it on your server as well. It is also highly recommended to tell PayPal not to accept unsigned/unencrypted transactions.
- Each time you need to generate a PayPal button, you encrypt the data using PayPal’s public key and sign it with your private key, then you display the result on your Web page. When the user clicks the button, PayPal will decrypt the details and check they have not been tampered with since their generation on your server.
This way, as long as your private key is uncompromised, no one will be able to alter the transaction’s details.
For extra security of your protected and encrypted buttons, update your PayPal account profile to block unprotected and non-encrypted payments.
Also, you can detect and manage Fraud Management Filter results using IPN and the PayPal API. All merchants using IPN or the PayPal API must ensure that their systems can handle transactions pended by Fraud Management Filters.
Instant Payment Notification (IPN) is a message service that notifies you of events related to PayPal transactions. You can use IPN messages to automate back-office and administrative functions, such as fulfilling orders, tracking customers, or providing status and other transaction-related information. Source : https://developer.paypal.com/webapps/developer/docs/classic/ipn/integration-guide/IPNIntro/
I hope this article was helpful and covered all the aspects of the attack. For futher information, I selected some links that I believe will be of a great assistance.
Securing Your PayPal Payments Standard Buttons : https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/encryptedwebpayments/#id08A3I0N30Y4
PayPal Payments Standard Button Manager API Overview : https://developer.paypal.com/docs/classic/button-manager/integration-guide/NVP/ButtonMgrAPIExamples/
Customizing Websites to use Fraud Management Filters : https://developer.paypal.com/docs/classic/fmf/integration-guide/FMFProgramming/
Web Parameter Tampering : https://www.owasp.org/index.php/Web_Parameter_Tampering