Shared Infrastructure Mid-Assessment: Whose Host Is It Anyway?

Do not let the scanner's payload stand and do not run sqlmap.

Reasoning:

1. Blast radius is unconfirmed. The ALB serves two other companies. A time-based payload holds a database connection open; on shared infrastructure that is someone else's availability risk, and 'no DoS on third-party systems' is explicit in the RoE.
2. Ownership is unconfirmed. dev.engco.com is probably EngCo's, but 'probably' is not a scope. Confirm with certificate SANs, RDAP/WHOIS, and a written question to the client before touching it again.
3. Confirm without sleeping. Send a single quote and look for a SQL grammar error or a differential response. If you need a boolean pair, use AND 1=1-- - versus AND 1=2-- - at baseline latency - one request each, no SLEEP().
4. Preserve evidence now: raw request/response, timestamps, scanner name and version, and an explicit note that the finding is unvalidated.

What goes in the report tonight: 'Potential SQLi on shared hosting infrastructure - exploitation deferred pending scope confirmation, request issued 23:52.'

In scope: EngCo's application. Out of scope without written approval: the Okta tenant itself.

The identity provider is a third party under the RoE. So:

• Do not password-spray Okta, attempt MFA fatigue, test Okta's own endpoints, or enumerate the tenant's directory.
• Do test how the application handles the federated flow: session fixation after the callback, tokens leaked in Referer headers or URLs, missing state/PKCE, logout not invalidating the session server-side, open redirect in the post-login returnUrl, and whether the app trusts an unverified email claim to grant role.
• redirect_uri validation is configured inside the Okta app registration but is owned and changeable by the client, so flag it as a question rather than an exploit until approved.
• Request, in writing, a dedicated test account pair (two tenants if multi-tenant) - you need it to test authorisation later anyway.

If asked for a one-liner: 'Identity provider is out of scope per RoE §3; application-side federation logic is in scope and tested.'

Freeze anything that could reach outside confirmed EngCo scope; spend the window on work that cannot surprise you later.

Concretely:

• Log the call attempt: time, number, voicemail, and a follow-up email to the security lead plus the engagement's distribution list asking the two open questions (dev.engco.com ownership; Okta test accounts).
• Continue only on assets whose ownership is confirmed: app.engco.com authentication logic, TLS/cookie/header review, and passive recon on the staging IP.
• Do not 'just be careful' on the shared ALB. Being careful is not the same as being authorised, and the person who could authorise it is asleep.
• Close the window at 02:00 and re-plan; a deferred test costs a day, an outage on two other companies' shared load balancer costs the engagement.

Report wording: 'Scope ambiguity identified at 23:40; testing of shared infrastructure suspended pending written confirmation. Escalation attempted x3, unacknowledged.'