---
name: co-fita-green-mile
type: analysis
title: "The Green-Mile Case Study: Systemic Authorization Failures and Layered Remediation"
description: "Deep-dive into the Green-Mile penetration test at RD Saude: 6 vulnerability classes, structural diagnosis, the 5-layer fix model, retest, and control encoding."
tags: [green-mile, appsec, authorization, idor, api-security, layered-fix, rd-saude, security-by-design, sdlc]
timestamp: 2026-07-22
---

# The Green-Mile Case Study

> **Source:** `SDLC_PROTOCOL_REPORT.md` (2026-07-22), `playbook_bairesdev_appsec_alefita.md`
> **Cross-references:** [[co-fita-sdlc-protocol]], [[co-fita-red-team-blue-team]], [[co-fita-harness]], [[clickfix-attack-chain]]

---

## What Was Found

The Green-Mile penetration test at RD Saude uncovered systemic authorization failures across the API proxy and mobile-to-backend architecture. These were not isolated bugs -- they were symptoms of missing architectural controls.

### The Six Vulnerability Classes

| Finding | Type | Impact | OWASP Category |
|:---|:---|:---|:---|
| IDOR-style access to address resources | Authorization bypass | Personal data exposure (delivery addresses, customer PII) | A01:2021 Broken Access Control |
| Insufficient protection of payment-card response data | Data leakage | PCI DSS violation, fraud potential | A02:2021 Cryptographic Failures |
| Unauthorized modification of billing addresses | Authorization bypass | Account manipulation, billing fraud | A01:2021 Broken Access Control |
| Exposed or inconsistently protected customer-login routes | Authentication weakness | Account takeover | A07:2021 Identification and Authentication Failures |
| Hardcoded secrets and weak client-side assumptions | Secret management | Credential exposure via APK decompilation | A02:2021 Cryptographic Failures |
| Proxy-level SSRF and cache poisoning conditions | Infrastructure abuse | Lateral movement, data manipulation | A10:2021 Server-Side Request Forgery |

### What These Findings Could Enable

An attacker chaining these vulnerabilities could:
1. Extract delivery addresses of any customer via IDOR (personal data exposure)
2. Access payment card data in API responses (PCI DSS violation)
3. Modify billing addresses to redirect shipments or manipulate invoices
4. Take over customer accounts via weak authentication routes
5. Extract hardcoded secrets from mobile binaries to impersonate legitimate clients
6. Exploit SSRF conditions to access internal services or poison caches

The regulatory exposure was significant: LGPD (Brazilian data protection law) violations for PII exposure, PCI DSS violations for payment card data handling, and reputational damage from account manipulation.

---

## The Structural Diagnosis

### The Core Finding

The server-side authorization model could not rely on the mobile client behaving honestly.

**The mobile client is an untrusted presentation layer.** Authorization must be enforced where the protected object and business action are actually owned -- at the service layer.

### Why "Mobile Client Is Untrusted"

This diagnosis is rooted in a fundamental architectural truth: any code running on a device the user controls can be:

- **Decompiled** -- APKs are trivially decompilable with JADX; IPA files can be decrypted and inspected
- **Instrumented** -- Frida hooks can intercept and modify any function call, network request, or return value at runtime
- **Bypassed** -- Certificate pinning can be bypassed with objection or custom Frida scripts
- **Replaced** -- A modified client can make any request the original client could, plus requests the original client never intended

This means:
1. Any client-side validation is advisory, not authoritative
2. Any secret embedded in the binary is extractable
3. Any assumption that "the client will only request its own data" is false
4. Any authorization decision delegated to the client is absent

The Green-Mile findings demonstrated all four of these principles in practice.

### The Chain of Failures

The IDOR vulnerability in the address proxy was not a bug in one endpoint. It was evidence of a chain of missing controls:

```mermaid
graph TD
    A["Mobile client sends request<br/>with address_id parameter"] --> B["Gateway authenticates user<br/>(validates token)"]
    B --> C["Gateway forwards request<br/>to address service"]
    C --> D["Service returns address<br/>by address_id"]
    D --> E["No ownership check:<br/>does this user own this address?"]

    style E fill:#ff6b6b,color:#fff

    E --> F["Any authenticated user<br/>can access any address"]
```

The failure was architectural: the service assumed that if the gateway authenticated the user, the user was authorized to access the requested resource. Authentication and authorization are different concerns. The gateway authenticated identity; nobody verified ownership.

---

## The 5-Layer Fix Model

The remediation was not a list of patches. It was a layered architectural intervention where each layer addresses a different aspect of the security failure.

### Layer 1: Client

| Action | Purpose |
|:---|:---|
| Remove hardcoded secrets from binaries | Eliminate extractable credentials |
| Harden transport (SSL pinning) | Resist passive interception |
| Route clients through safer endpoints | Reduce attack surface |
| Acknowledge: client-side controls are friction, not boundary | Set correct mental model |

**Principle:** Client-side controls are useful friction. They slow down casual attackers and prevent accidental misuse. They are NOT an authorization boundary.

### Layer 2: Gateway/Proxy

| Action | Purpose |
|:---|:---|
| Enforce authentication on every request | No anonymous access to any endpoint |
| Propagate authorization context | Pass user identity, roles, permissions to services |
| Input validation at the edge | Reject malformed requests before they reach services |
| Rate limiting per endpoint and per user | Prevent abuse and enumeration |
| Safe header handling | Prevent header injection attacks |
| SSRF mitigation | Restrict outbound destinations from proxy |

**Principle:** The gateway is the control plane. It encodes security decisions once and enforces them for all services behind it.

### Layer 3: Service

| Action | Purpose |
|:---|:---|
| Verify object ownership server-side | Before returning data or allowing modification |
| Action-level authorization | Different permissions for read, create, update, delete |
| Never trust client assertion about object ownership | Always verify against the database |

**Principle:** The service layer is where authorization actually lives. The service owns the data model and therefore owns the authorization decision. An IDOR cannot exist if the service verifies ownership before every data access.

This is the most critical layer. Layers 1 and 2 are defense-in-depth; Layer 3 is the actual control.

### Layer 4: Data

| Action | Purpose |
|:---|:---|
| Minimize response payloads | Do not return fields the client does not need |
| Mask sensitive fields | Payment card numbers, CVV, PII |
| Field-level access control | Based on caller authorization |

**Principle:** Even if authorization is correctly enforced, response payloads should be minimized. An API returning full payment card numbers when the client only needs the last four digits creates unnecessary exposure surface.

### Layer 5: Process

| Action | Purpose |
|:---|:---|
| Document authorization rule as a standard | "The server always verifies ownership" |
| Train teams on the ownership verification pattern | Make the pattern a default, not a decision |
| Retest after remediation | Verify the fix works and has not introduced new issues |
| Create repeatable review pattern for new APIs | Prevent recurrence in future endpoints |

**Principle:** Fixing the endpoint without fixing the architecture means the next endpoint will have the same flaw. The process layer encodes the lesson so it prevents the entire class of vulnerability.

---

```mermaid
graph TB
    subgraph "Layer 1: Client"
        C1[Remove secrets]
        C2[SSL pinning]
        C3[Use safer endpoints]
        C4["Friction, not boundary"]
    end

    subgraph "Layer 2: Gateway"
        G1[Enforce authn]
        G2[Propagate authz context]
        G3[Input validation]
        G4[Rate limiting]
        G5[SSRF mitigation]
    end

    subgraph "Layer 3: Service"
        S1["Verify ownership (CRITICAL)"]
        S2[Action-level authorization]
        S3["Never trust client assertion"]
    end

    subgraph "Layer 4: Data"
        D1[Minimize payloads]
        D2[Mask sensitive fields]
        D3[Field-level access control]
    end

    subgraph "Layer 5: Process"
        P1[Document standard]
        P2[Train teams]
        P3[Retest]
        P4[Repeatable review]
    end

    C1 & C2 & C3 --> G1
    G1 & G2 & G3 & G4 & G5 --> S1
    S1 & S2 & S3 --> D1
    D1 & D2 & D3 --> P1
    P1 --> P2 --> P3 --> P4
```

---

## Retest and Verification

The retest phase confirmed that the layered fix model produced durable results:

### Verification Approach

| Layer | Verification Method | Evidence |
|:---|:---|:---|
| Client | APK decompilation with JADX | No hardcoded secrets found in rebuilt binary |
| Gateway | Traffic capture via Burp Suite | Authn/authz headers correctly propagated; rate limits enforced |
| Service | Frida instrumentation + manual testing | IDOR conditions eliminated; ownership verification on every data access |
| Data | Response payload inspection | Sensitive fields masked; minimal payloads |
| Process | Code review of new API endpoints | Ownership verification pattern consistently applied |

### Regression Testing

The retest was not limited to the fixed endpoints. It extended to:
- New endpoints added during the remediation period
- Edge cases in the authorization model (e.g., shared addresses, admin override flows)
- Cross-role access patterns (customer, delivery driver, support agent)
- Mobile client behavior with modified requests (Frida hooks)

---

## The Architectural Lesson

### Flaws Are Structural, Not Local

The Green-Mile story demonstrates the playbook's core claim: **security flaws are rarely single-point failures. They are symptoms of missing architectural controls.**

An IDOR in an address proxy is not a bug in one endpoint. It is evidence that the system lacks:

1. **Object-ownership verification** as a service-layer invariant
2. **Authorization context propagation** at the gateway
3. **A standard** that encodes "the server always verifies ownership"
4. **A review process** that catches missing ownership checks in new endpoints

Fixing the endpoint without fixing the architecture means the next endpoint will have the same flaw.

### The Question That Produced the Finding

The Green-Mile diagnosis was produced by Question 4 from the Security by Design methodology:

> **"What happens when the client is modified or bypassed?"**

When the mobile client is treated as an untrusted presentation layer, the entire authorization model collapses. The client sends `address_id=12345` and the server returns the address -- without checking that the authenticated user owns address 12345. This is the fundamental error that the layered fix model addresses.

### Connection to CAMDOM

The [[camdom-architecture]] design embodies the same principle. CAMDOM's threat model starts with "what happens when the software is bypassed?" The answer: software-level protections (app locks, cloud services, single-device solutions) can all be killed, spoofed, or bypassed by software running on the same OS. The solution operates at the hardware layer (BLE proximity detection) where software manipulation cannot reach.

The through-line from Green-Mile to CAMDOM is the same: understand the threat model deeply enough that the control you build is structural, not reactive.

---

## Connection to Other Projects

### ClickFix

The [[clickfix-incident-response]] demonstrates the operations phase (Phase 6 of the [[co-fita-sdlc-protocol]]) applied to a real attack. The same layered thinking applies:

- **Layer 1 (Client):** Browser security (blocked clipboard paste to terminal by default)
- **Layer 2 (Gateway):** DNS monitoring for expired domain hijacking
- **Layer 3 (Service):** Repository link validation (expired domain detection)
- **Layer 4 (Data):** Minimize what the stealer can access (reduce `~` surface area)
- **Layer 5 (Process):** Encode the lesson as a monitoring protocol (18h cycles)

### Co-Fita Governance

The [[co-fita-governance]] system encodes Green-Mile's lesson at the meta-level. When the orchestrator encounters a failure (Phase III audit failure), the governance system creates a proposal, Congress debates it, and after chancela, the fix is deployed as a reusable control (skill, rule, or hook). This is Layer 5 (Process) automated and made recursive.

### Kaggle Agent Security

The [[kaggle-agent-security]] competition targets the same class of vulnerability -- trust boundary violations -- but in AI systems instead of API architectures. The four predicates (EXFILTRATION, UNTRUSTED_TO_ACTION, DESTRUCTIVE_WRITE, CONFUSED_DEPUTY) map to the Green-Mile finding categories:

| Green-Mile Finding | Kaggle Predicate |
|:---|:---|
| IDOR (accessing others' data) | EXFILTRATION |
| Unauthorized modification | DESTRUCTIVE_WRITE |
| Exposed login routes | CONFUSED_DEPUTY |
| Hardcoded secrets | UNTRUSTED_TO_ACTION |

---

## The 7-Requirement Finding Format

Applying the [[co-fita-sdlc-protocol]] Phase 7 requirements to the Green-Mile findings:

| Requirement | Green-Mile Evidence |
|:---|:---|
| 1. Clear affected asset and owner | Address proxy endpoints, owned by mobile backend team |
| 2. Reproducible evidence | Burp Suite captures, Frida scripts, JADX decompilation output |
| 3. Severity tied to exposure and business impact | LGPD violation (PII), PCI DSS violation (payment cards), account manipulation |
| 4. Root-cause diagnosis | Missing ownership verification at service layer |
| 5. Remediation or compensating control | 5-layer fix model |
| 6. Retest and regression evidence | Post-fix verification via Frida, Burp, manual testing |
| 7. Durable lesson | Ownership verification pattern documented as standard; review checklist for new APIs |

---

## Summary

The Green-Mile case study is Alefita's flagship security story because it demonstrates the complete Secure SDLC operating at its highest level:

1. **Symptom to system:** IDOR -> missing architectural controls
2. **Layered fix:** Not patches, but a 5-layer intervention from client to process
3. **Control encoding:** The ownership verification pattern becomes a reusable standard
4. **Verification:** Multi-method retest confirming the fix at every layer
5. **Feedback:** The lesson feeds back into design for every future API

This is the pattern that connects Green-Mile to ClickFix to CAMDOM to Co-Fita. The medium changes -- API endpoints, BLE protocols, AI governance -- but the methodology is the same: understand the threat model, fix at the right layer, encode the lesson, and make sure the next system starts with the control already in place.

---

*This document is alive. It evolves as the research evolves. Challenge it. Improve it. That is the protocol.*