0

I'm pretty new to JS and I am currently making a simple step-wise checkout system using purely JS and some Ajax and PHP. I have been wondering about the possible security issues that might pose with such a system.

The way it works is as follows:

  1. Select item, press Next(Hide current div, show next div)
  2. Use increment/decrement and pick the amount for the item, press Next(Hide current div, show next div)
  3. Same as 2 just with another item
  4. Same as 2 and 3 with another item
  5. Generate invoice
  6. Proceed to payment(fill in card details and pay using external credit card gateway API)

Now, the thing that bothers me is number 6. What is someone edits the JS and sends different values to the external payment processor? Is that possible? And if it is, how to I securely make sure this does not happen?

Withing my Javascript I make use of several values that I fetch from a simple table from my database, such as price for the items and shipping cost. But I use these values straight in my Javacsript file for the computations and generating the invoice. I have a feeling that I'm approaching the problem in a wrong way. Is there a possibility that the "client" can change the computations as well?

How do I make sure that once the invoice is generated, the correct values are used in calculating the total price so the proper price is sent through the payment gateway, no matter if someone simply messes up with the "front-end" numbers that show up?

Note I have been told that this would be the best place to post this question, please let me know if it's not and I will remove it.

If you want to see the checkout I made, here it is(I haven't put the payment gateway API yet as I'm worried about the security): http://goo.gl/jdN4T0

Thanks :-)

  • 5
    I don't want to sound too mean, but if you do not know how to properly design such an application, should you be doing it? The fact that you ask about this and want to learn is good. It just really send shivers down my spine imagining that you run an actual website (both for your own security and the one of your client). – John Apr 8 '16 at 20:04
  • 2
    Recommended read to understand why it is a bad idea to handle everything at the (untrusted) client side: Domino's: Pizza and Payments. – Steffen Ullrich Apr 8 '16 at 20:07
  • @John I also got that shiver when I looked back at what I did. Website isn't really published, it's just a test server to see my code(I know I can run it locally). I just want to get the security down so I can fix is properly before actually sending it live :-) – nTuply Apr 8 '16 at 20:28
  • @John if everyone waited until they thought they were qualified to do anything, nothing would ever happen. Let the new guy learn - he's obviously aware of his shortcomings and working to improve. – SomeKittens Apr 8 '16 at 20:31
  • @nTuply alright have fun learning. I would still recommend to learn a lot till you take it live. – John Apr 8 '16 at 20:32
2

The user's client should submit only the order's list of items (and quantities) to the server. Anything else about the order -- especially how much the entire order costs -- should be computed on the server, based on the list of items that were ordered. If the user mucks around with the JavaScript that submits which items the user has ordered, there's nothing really wrong with that: it is equivalent to the user having normally ordered some different items.

Optionally, you may have the client also compute the order total, purely as a UX convenience for the user. This value should be thrown away when submitting the order to the server, since the user may have altered it after it was calculated by your script.

0

What is someone edits the JS and sends different values to the external payment processor? Is that possible? And if it is, how to I securely make sure this does not happen?

It's possible. Here is a way that PayPal handles it: Payment button code is encrypted before it is displayed on the merchant website. You could do the same or use a shopping-cart and payment gateway provider that offers this functionality.

Withing my Javascript I make use of several values that I fetch from a simple table from my database, such as price for the items and shipping cost. But I use these values straight in my Javacsript file for the computations and generating the invoice. I have a feeling that I'm approaching the problem in a wrong way. Is there a possibility that the "client" can change the computations as well?

Yes this is possible. I was at a conference last weekend were a developer was discussing how he revealed the vulnerability to a client on their server. Here is an article I found online talking about the same issue fyi: Price manipulation vulnerability in e-commerce platforms

How do I make sure that once the invoice is generated, the correct values are used in calculating the total price so the proper price is sent through the payment gateway, no matter if someone simply messes up with the "front-end" numbers that show up?

I'm not sure how to make sure it's correct the first time the invoice is generated beyond using payment buttons that send encrypted information to the server for invoice generation. If you use strong enough encryption, it will be difficult for an attacker to use invalid information to generate an order.

It doesn't really become a problem until something is delivered. So If you don't know how to setup an encrypted shopping system, an easier task is making orders pending by default and running a server side script that runs on the order database after the transaction to check that the prices paid match the actual price for each item. You could run this script against information generated from your merchant account order history after payment has been processed. How to write the script is beyond the scope of security.stackexchange.

Here are some related links on JavaScript security and e-commerce vulnerabilities:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.