Your Reconciliation Nightmare - How Attackers Target Payment Flows
Payment Flows. Thanks to platforms like Stripe, they are incredibly simple to implement and manage.
However, even with platforms like Stripe raising the bar for security overall, the ease of implementation can lead to 1) a false sense of security and 2) features getting implemented without understanding the security and availability implications.
Think of the OWASP Top Ten vulnerabilities. Time and time again, we find different forms of injection or broken access control during a payment flow. Technically, most of the vulnerabilities mentioned from this point will belong to various OWASP categories.
Let's break it down.
Parameter Manipulation
Discounts, trials, prices, currency, user id's, cart id's. The payment process likely has numerous parameters that are involved in tracking, setting, and fulfilling your purchase.
What happens if those parameters can be influenced?
Changing the trial may lead to an unlimited free product. Price modification may lead to the price of items being modified, or even leading to a discount if a negative price is set.
Setting a different user ID can lead to a different customer paying for a product.
With the complexity of 3rd party payment platforms, this can get complicated.
We've all used Google or Apple pay for online services before. If we consider how that communication works, we can begin to poke potential holes in the flow process.
When the commerce site redirects you to Google for example, how is it telling Google how much the product is? If an attacker can modify those values, they may be able to adjust things like the cost, or amount of a product purchased.
All of these come back to one vulnerability. Inappropriately placing trust in the client. As always, all parameters should be controlled on the server-side, or checked for validation before processing the payment.
Signing up with an email tied to the organization.
Say acme.com has a products page. Before you purchase a product, you need to sign up for an account. I sign up with [email protected] for my email address. As a result, Acme automatically provides me with elevated access or applies an employee discount based on my email address.
This also may apply to parameter manipulation, if a customer can enter a discount code for an employee discount without further checks, this may lead to a loss of revenue.
Replay Attacks
You've just made a purchase online. But there's a twist, you're an attacker. After you made your purchase, you were redirected to a page that confirms your shipping details. Looking at the HTTP request that took place when you were redirected, you modify several parameters. Now when you make that request, you're redirected to a shipping page for a purchase that hasn't been paid for.
This is typically how a replay attack occurs. By re-sending old requests with some modifications, an attacker may be able to perform actions that are supposed to be done in a specific order, bypassing payment pages and receiving free products.
Exposed API Keys.
Likely one of the most prevalent issues on this list. API keys are the keys to the kingdom - and that's no hyperbole. Many times, developers give API keys full permissions to everything. Primarily because it's easy, but also because it's not always clear what permissions an API key will need.
Where are they exposed? We've seen API keys exposed in the web page itself, hidden away in the source code, sitting in GitHub accounts, and even on StackOverflow!
You might need to sign into GitHub to follow the link below, but trust us, it's worth it.
Race conditions
What is a race condition?
Think of your web app as a ticket counter, you have five agents, each working a different window. Now imagine five different people approaching the windows simultaneously. They all request a refund for a product all at once for the same customer. Unknowing, each agent provides a refund to each individual before the computer system can tell them that a refund has already been processed.
With web applications, what happens if someone sends one hundred transfer funds requests within several milliseconds of each other? If it leads to a vulnerability, then you have a race condition.
Accepting test data.
What happens when a customer enters a test credit card number on your payment flow? Most platforms have support for this type of testing. For example https://stripe.com/docs/testing
Ideally, customers can't make purchases with test payment details. However, this may even extend to your non-production environment. Can an attacker access your staging commerce platform? Can they make test orders that are actually fulfilled?
Improper Credit Card Exposure
Have you ever signed into a web application, only to see your stored credit card number shown to you in clear text? We have.
It's a bad idea. And, it's against PCI DSS Compliance. PCI DSS is the Payment Card Industry Data Security Standard. According to PCI DSS, primary account numbers must be masked when shown anywhere unless there is a strong business justification.
Sensitive details such as credit card numbers should never be returned to a client's web browser. If it is returned, but the web application stars it out, it is still retrievable by an attacker. Next time you're on a website, and you see your credit card starred out, right-click, select inspect and see if your credit card number shows up in the side/bottom bar.
Recap
So what can you do about this? For starters, just ask! Ask your developers and web admins how they secure your customer's transactions. Following the best practices gets you 90% of the way, the remaining 10% comes from threat modeling, penetration testing, and asking the right questions.
And as always, Adversis can help! Not only do we have passionate security personnel, but we've also been assessing commerce and payment flows for years.
Get in touch today!
Contact: [email protected]
Adversis: https://adversis.io
Adversis ACS: https://acs.adversis.io
