1

Introduction

In payment gateways such as Coinbase or G2A Pay, the typical payment flow goes as follow:

  1. POST to the gateway with the secret API key and metadata (price etc) to generate a payment URL.
  2. Redirect the client to the payment URL.
  3. Server receives payment notification through webhook and verify the payment (through the signature attached to the payload).

Question

Step 1 is typically performed by the server to avoid leaking the API key to the client.

However, if I were to generate the payment URL on the client's side (for performance -- eliminate one RTT to server), the API key will be leaked to the public.
What would be the security implications of that?

Step 3 security

For Coinbase, the webhook signature uses a different API key so I can still verify the authenticity of the payment notification through the signature.
For G2A Pay, I can perform a GET to the payment gateway with the transaction id to verify the payment.

Potential vulnerabilities considered

With the API key, any user will be able to make a payment and attribute it to another user (by specifying the other user's id in the metadata). However, there would be no incentive for any user to do so.

riwu
  • 113
  • 3

1 Answers1

2

It is really important to start with the mindset of an attacker, rather than an engineer. As an attacker there could be a litany of reasons I may want to leverage your private key to meet my own desires. Lets start with your eCommerce information.

By having your eCommerce information, I can start racking up a bill on other people's accounts. I can even create my own form to order what I want, use someone else's card, and have it shipped to a location I choose. The best part is you don't have to be in this conversation at all so you wont even see the activity occur.

Going even further, say I have this person I REALLY hate because they keep waking me up in my apartment in the middle of the night with loud music. If I happened to get their payment information, I could make a bunch of bogus purchases that will cause them to cancel their card, deal with fraudulent activity, and it will look like your commerce account is to blame. I feel happy knowing they've been inconvenienced and you might not ever figure out it was me. Win win.

Lastly, many API keys perform more than just eCommerce approvals. Account changes can be made through many APIs so changing the business name, address, even customer information. Worse, you can start stealing client information through an API so I could start spamming your customers with viagra ads or worse; and again still be connected to your service. It's a big security risk.

Your secret, be it a password, certificate, or API key must ALWAYS be protected. You should never underestimate the lengths people will go to screw other people over. As a developer or systems administrator, it is your responsibility to think about this and ensure that your clientele are protected.

Finally, I never advise to do anything illegal, amoral, or otherwise maliciously. However, it can be a very good practice to look at anything you build and see how you could misuse it. View your work through an attackers eyes and try to exploit the very tools you create. The attackers mindset is best learned through application, and if you're attacking your self you will learn more about your own projects than you would have ever known otherwise.

Connor Peoples
  • 1,421
  • 5
  • 12
  • Thanks for the detailed response! I realized that the API key can be used for querying all transaction data, which will be a huge privacy vulnerability. Will keep the `secret` secret then. – riwu Jan 14 '19 at 08:53