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:

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.

---

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.