How NOT to Secure Web Payment Systems

Since the tale laid here is real, I'll refrain from using specific names or locations. It might put me in some awkward situation. If you've been through something similar, it may sound familiar.

Disclaimer:

• I did not actually use what I got and reported the bug.
• I do not suggest scoring free services through exploitations of lousy systems. This is meant to help secure those that are exposed.
• I hope that developers become more vigilant with systems, especially those involving the personal and medical information of literally everyone that crosses their country's border.
• I do think, however, that testing at home for these kinds of bugs is .

Once upon a time

Throughout the last year, I've been traveling to my home country and had to take a free PCR test right at the airport. Scheduling the appointments in an online dedicated system using the same discount code every time:

Free1

*Wait, what?*

I retried the same code that used to work over the last year.

Free1

I did what any cybercriminal would do at that point - retried the same thing 3-5 times (genius). When that didn't work, I tried

Free2

Free80

When I checked the outgoing request, I found that it was being sent to

/api/validate-voucher

422 (Unprocessable entity)

{statusCode: 422, message: "Invalid Voucher or Appointment ID"}

I was trying to apply a discount code. Upon bad response, the UI deletes the code entered, effectively "preventing" the use of the code. The fact that it actually got deleted could have been a good user experience but a lousy prevention mechanism at the same time. "Why not test it myself?" I thought. 😈

to the rescue!
I fire up Firefox and everything through Burp.

Going through the outgoing requests, I see metrics and more metrics, 3rd party trackers, and whatnot. Sometimes I wish I haven't seen the pile of crap these websites make us send. Forwarding everything that's not interesting until WHOOPS, what's that?

A

POST

{
  appointmentId: "12345",
  voucher: ""
}

There we go - how about sliding the previously valid voucher through?
But wait, this sounds familiar.. earlier, when I just tried entering my old discount code, I got an "

Invalid appointmentId

It feels off. A hunch tells me I'm going to see something funny.
I edit the object on the fly and forward it with burp:

{
  appointmentId: "12345",
  voucher: "Free1"
}

And what do you know, a huge shiny green label appeared on the screen: "PAID". Five seconds later, the screen reloaded, and a new QR with an appointment was generated.

Moral of the story

Users are not dumb. Some of them may not have the skills or energy to dig in. But if a system that holds personal medical records and results is this easily exploited, what happens in other areas?

One must check each and every incoming request as if it's coming from the wild (it actually is!). Employ

Ways to handle

First and foremost, assume you're going to get exploited. Much like checking if the front door is locked, applications should make sure users can only do what they're intended to.

Checking whether a discount code is valid in the UI? Excellent, what about the backend? The browser lives in userland, where the developers don't have control over how the application is manipulated or misused. One must check each and every incoming request as if it's coming from the wild (it actually is...). Employ zero trust.

On the same note - rate-limit incoming requests; when I couldn't apply my old

Free1

Free2

Free3

• Servers are bombarded with requests. In case it was built correctly, it scales up to serve brute force attacks (funny on its own). In the worse case, it crashes.
• At some point, a valid discount code will pop up.

Another "discount code friendly" exploit (which I hadn't tried after getting a full price reduction), is a where a user can re-apply the same discount code, usually giving a discount percentage multiple times. .

Also published on .