If you multiply the amount parameter in a POST /api/v1/order/checkout request by -1 and the server returns a 200 OK, your entire security architecture has effectively remained on paper. Congratulations, you're no longer just a developer; you've become a 'financial risk.'
Hey folks, Sedat here. Today we’re diving into a topic that causes the most headaches in the field—especially within modern microservices architectures—one that automated tools mostly miss, but whets my appetite the most as a Red Teamer: Business Logic flaws and advanced IDOR scenarios. If your coffee is ready, let's start with some fictional (yet very real-world based) scenarios on 'testCompany.'
IDOR: Much More Than Just Changing Numbers
Most people still think IDOR (Insecure Direct Object Reference) is just about changing id=123 to id=124. Guys, it's 2024. We are dealing with UUIDs, hashed IDs, and JWTs now. But does that mean IDOR is dead? Absolutely not. It has simply evolved.
For example, consider a profile update request:
PUT /api/users/me/settings
Payload: {"email": "[email protected]", "role": "USER"}
Here, the first thing an attacker will try is changing the role parameter to ADMIN. If the backend takes this parameter and pushes it directly to the database via 'mass assignment,' congrats; you've just achieved Privilege Escalation with a single request.
Defensive Recipe: Use DTOs (Data Transfer Objects). Never map data coming from the user directly to your database model. Define which fields are updatable using an allowlist.
SSRF: The Trojan Horse Inside
Server-Side Request Forgery (SSRF) is one of the most dangerous vulnerabilities in the modern cloud (AWS, Azure, GCP) world. Every point where your application takes an external URL and makes a request (profile picture uploads, URL previews, webhook definitions) is a potential bomb.
Commonly, we see this mistake:
GET /generate-pdf?url=http://example.com/invoice/1
What happens if an attacker manipulates it like this?
GET /generate-pdf?url=http://127.0.0.1:80/admin/status
Or if you are in a cloud environment, they might try to reach the metadata services:
GET /generate-pdf?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
An IAM role leaked from here could give the attacker full control over your entire infrastructure.
Defanged Payload Example:
# Attempting to fetch AWS credentials from the metadata service (Defanged)
curl -X GET "http://example.com/proxy?url=http://169.254.169.254/latest/meta-data/"
How Do We Stop It?
- Implement proper URL parsing. Only allow requests to an allowlist of trusted domains.
- Block access to internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and loopback) at both the application level and the network layer.
Business Logic: The Moment Code Becomes Illogical
Business logic flaws begin the moment a developer says, "The user wouldn't do that anyway." My favorite scenario: Race Conditions.
In an e-commerce site (testCo...