BugForge - Daily - Cafe Club

Daily - Cafe Club

Vulnerabilities Covered:
Broken Access Control - Business Logic Flaw

Summary:
The Cafe Club application contains a Business Logic Flaw in its PUT /api/profile endpoint. The endpoint accepts a user-controlled JSON body and applies all supplied properties directly to the user record without validating which fields are permitted to be updated. By injecting a points property into the profile update payload, an authenticated user can arbitrarily set their own loyalty point balance, bypassing the intended earn-per-purchase logic entirely.

Reference:
Bugforge.io

Solution

Step 1 - Application Reconnaissance

We’ve analysed the basic functionality of the cafe-club application. Which includes purchasing of products, gift cards and account management.

When completing the checkout process we notice a hint Free shipping on all orders! Earn 1 point per euro spent.

This led me to look into how the point system works.

---

Step 2 - Probing the Points System

We’ve attempted to manipulate the points in the checkout & order functionality but we were unable to abuse the current logic.

Next we looked at the account update functionality. We’ve triggered an original Profile update request to see what the payload looks like.

---

Step 3 - Attempting Role Escalation

First we tried to update our role to admin as our current role was returned as user.

We used the api/verify-token endpoint to verify whether our role had been updated to admin.

The role update was not successful, however notice that the verify-token response also returns our current points balance. This reveals that points are stored as a user attribute.

---

Step 4 - Exploiting the Points Parameter

We’ll add a points property to the profile update payload and attempt to manually set our points balance.

Manually updating our points via the PUT /api/profile endpoint we receive the flag in the response.

---

Impact

• Any authenticated user can set their loyalty points balance to an arbitrary value by injecting a points property into a standard profile update request
• The points system is rendered meaningless as the earn-per-purchase mechanism can be bypassed entirely without making any purchases
• A user could accumulate unlimited points and redeem them for discounts, free products, or other rewards, resulting in direct financial loss for the business
• No elevated privileges are required; the vulnerability is exploitable by any registered user
• If points are tied to tiered rewards or status levels, an attacker could also escalate their account standing without meeting the legitimate criteria

---

Vulnerability Classification

• OWASP Top 10: A01:2021 - Broken Access Control
• Vulnerability Type: Business Logic Flaw / Mass Assignment
• Attack Surface: Profile update endpoint (PUT /api/profile), user-controlled JSON body
• CWE: CWE-915 - Improperly Controlled Modification of Dynamically-Determined Object Attributes (Mass Assignment)
• CWE: CWE-20 - Improper Input Validation

---

Root Cause

The PUT /api/profile endpoint binds the incoming request body directly to the user model without restricting which properties are permitted to be updated. There is no allowlist of writable fields, so any property present in the JSON payload - including points, role, and other sensitive attributes - is accepted and persisted. The absence of a strict field allowlist on the update operation is the fundamental root cause, allowing clients to manipulate fields that should only be modified by server-side business logic.

---

Remediation

• Define an explicit allowlist of fields that users are permitted to update via the profile endpoint (e.g., name, email, password); strip or reject any properties not on the allowlist before processing the update
• Never bind raw request bodies directly to data models; use a Data Transfer Object (DTO) or equivalent pattern that only exposes the permitted fields
• Enforce server-side ownership of sensitive fields such as points, role, and balance; these should only ever be modified by trusted internal logic, not by client-supplied input
• Add integration tests that verify supplying unexpected fields (e.g., points, role) in update payloads has no effect on the persisted record
• Audit all other update endpoints in the application for the same mass assignment pattern

---