Third-Party Widget Discovery in an Authorized Web Application Test
A consultancy is in day 9 of a 12-day authorized penetration test of a client's customer portal. The signed scope lists three hostnames owned by the client: portal.example-client.com, api.example-client.com, and static.example-client.com. The portal embeds a payment widget served from widget.payvendor.com; the client's CTO said at kickoff, "test the whole portal, including anything it calls." While testing checkout, a tester finds a SQL injection in a parameter sent to widget.payvendor.com. The parameter is built by the client's front end, but the vulnerable SQL executes on the vendor's server. The tester has a proof of concept that returns one row from a vendor database table containing masked card data. The client's contract states that third-party systems are out of scope unless the vendor provides written authorization. No vendor authorization is on file. The account manager wants a "critical" finding by Friday, and the client's security team asks whether it must notify regulators.
1. May the tester exploit the SQL injection further to determine the number of affected records? Explain the decision using the authorization, scope, and risk factors in the setup.
Read the worked answer
Decision: Do not exploit further until the vendor provides written authorization through the client.
The signed scope is limited to three client-owned hostnames. The contract's third-party exclusion is specific and overrides a general kickoff remark; 'anything it calls' cannot create authorization from a vendor that has not signed anything. The tester has already demonstrated the vulnerability with a one-row proof of concept, which is enough to establish existence without expanding access. Continuing would mean executing SQL against a system the consultancy has no permission to test, potentially retrieving unmasked card data, creating a reportable data incident, and breaching PCI DSS and privacy obligations. The masked row is still sensitive evidence and must be handled accordingly. The tester should stop active exploitation, preserve the request and response evidence, notify the engagement manager and client security contact in writing, and ask the client to obtain vendor authorization if deeper validation is required. If authorization is later granted, define a narrow validation method with the vendor, such as confirming the injection point and row count with a read-only query, rather than dumping tables. The Friday deadline must not drive this decision.
2. What should the tester do in the next 24 hours, and what should the report say about severity and evidence?
Read the worked answer
Immediate actions: document the exact request, timestamp, payload, response, and the one returned row; store it in the encrypted evidence repository; do not copy more data. Send a written escalation to the client security contact and engagement manager describing the third-party dependency and the limits of testing. Ask the client whether its incident-response or privacy team needs to assess the masked data exposure; the tester should not make the legal notification decision.
Rating and report language: rate the finding using the firm's methodology, but distinguish technical severity from exploitability confidence. A SQL injection that can return data from a payment vendor is potentially Critical; however, the report must state that exploitation was limited to one row, the vulnerable server belongs to the vendor, and no vendor authorization exists. Use a confidence label such as 'confirmed vulnerability, limited exploitation' and separate the client-side cause (unsafe parameter construction) from the vendor-side flaw. Recommend that the client require the vendor to patch and provide evidence, add input validation and allowlisting on the client side, and review the widget integration. Avoid claiming a data breach; state only what was observed. This gives the client accurate information without overstating the evidence.
3. How should the account manager's request for a critical finding by Friday influence the tester's work?
Read the worked answer
The account manager's request must not change the technical conclusion. Commercial pressure is not evidence. The tester should apply the same rating rubric used for every finding, document the compensating controls and the failed WAF bypass attempt where relevant, and explain why the rating is what it is. If the rubric says Critical, keep Critical; if the rubric reduces likelihood because of a verified control, a lower rating may be defensible, but the rationale must be written down, not negotiated. The tester should offer the account manager a factual briefing and, if pressure continues, escalate to the practice lead or quality reviewer. In the report, include a management response section if the client disagrees. That preserves the client's view without altering the finding. The integrity of the report is the product; inflating or deflating a rating to meet a deadline undermines the tester's credibility and could mislead decision-makers.