Slide 7 of 28
Part 1 · What Is It?Slide 7
Slide 7 · Impact
What attackers achieve when a trusted third-party becomes their delivery mechanism.
The impact mirrors what direct attacks achieve — but through a vector the target didn’t defend.
💳
Payment card data theft (skimming)
A compromised CDN script on a payment page intercepts card data as users type it — before it reaches the API. The API’s payment processing is never touched. The skimmer operates entirely in the user’s browser, leveraging the trust established by a script tag on the checkout page. Ticketmaster, British Airways, Newegg, and hundreds of other organizations experienced this between 2018 and 2020.
🗄️
Database compromise via injection
A third-party address, name, or description field containing SQL injection is stored directly in the database. The attacker then triggers the stored payload by making the application execute the stored SQL. Result: data exfiltration, row deletion, or privilege escalation — originating from a trusted data source that bypassed parameterized query enforcement.
💻
Remote code execution via Log4Shell pattern
A JNDI lookup string embedded in a third-party API response is passed to Log4j for logging. Log4j evaluates the string, initiates an outbound LDAP connection, and loads an attacker-controlled class — executing arbitrary Java code on the server. The impact is full server compromise. The entry vector was a field in a geolocation enrichment response, not a user-submitted request.
🌎
Access to internal systems via SSRF redirect
A third-party API response contains a redirect to an internal URL. The consuming API follows it server-side, reaching the AWS metadata endpoint, an internal admin interface, or an internal database management console. The attacker gains cloud credentials or internal access — through a redirect that came from a trusted source.
← Back Why is this #10? →