The Discovery

It all started with a routine reconnaissance session. I was looking into the digital infrastructure of several academic platforms when I came across a server belonging to IFERP (Institute For Engineering Research and Publication). For an organization that handles thousands of international conferences and high-level research papers, you'd expect their security to be rock solid.

However, I stumbled upon a classic, almost "rookie" mistake: an Open Directory.

Navigating through it felt like walking through a back door someone forgot to lock. Among the various files and logs, I found a database snapshot. While I didn't need to dig into the full schema to find what I was looking for, it was a clear signal that the platform's security philosophy was "trust by default."

The Hunt: Intercepting the Upgrade

I decided to move from passive observation to active testing. I wanted to see how the platform handled its most sensitive area: the money.

I went to the account upgrade page, where users can pay to become "Professional Members." This tier usually grants access to premium journals and conference discounts. I picked the highest tier, but before hitting "Submit," I fired up Burp Suite to intercept the request.

The "Aha!" Moment: "Name Your Price"

The moment the request hit my proxy, the vulnerability was staring me in the face. I was looking at a standard HTTP POST request, but there was one parameter that shouldn't have been there:

POST /api/membership/upgrade

...

user_id=8821&tier=professional&amount=15.00&currency=USD

I stared at that amount=15.00 for a second. In a secure system, the frontend should only tell the server which tier the user wants. The server should then look up the price in its own database. But here, the website was literally "asking" my browser how much I wanted to pay.

The Execution: A $0.01 Professional Membership

This is a textbook Business Logic Flaw, and it's incredibly easy to exploit but devastating in practice.

Here's exactly what I did:

  1. The Interception: I held the request in Burp Suite, preventing it from reaching the server.
  2. The Tampering: I deleted 15.00 and typed in 0.01.
  3. The Forward: I sent the modified request on its way.

The backend didn't blink. It didn't check if the "Professional" tier actually cost $15. It just saw a request to upgrade a user and an amount of $0.01, and it processed it. I didn't need to complete the payment to know I had won. The fact that the payment gateway was now asking me for a 0.01 dollar to unlock a professional membership confirmed the flaw. The server had completely failed to validate the price server-side.

The Fallout: Why This Matters

On a platform like IFERP, the implications go far beyond just saving a few dollars:

  • Intellectual Property: An attacker could get free access to a massive library of paid research papers.
  • Conference Access: You could essentially "spoof" your way into international conferences for free, causing massive financial headaches for the organizers.
  • Privilege Escalation: Combining this logic flaw with some of the weak administrative credentials I'd spotted earlier, the entire financial integrity of the member database was at risk.

Final Thoughts: Don't Trust the Client

If there's one lesson here for developers, it's this: The client (the browser) is in the hands of the enemy. You can never trust data that comes from the user's side when it involves prices, roles, or permissions. The server must always be the "Source of Truth." It should look up the price internally, and if the user tries to send a different amount, the system should flag it as a fraud attempt immediately.

In the world of security, trust isn't a policy — it's a vulnerability.