Show me how you'd combine common web bugs — say SQL injection and XSS — into impact beyond a single finding.
Short answer
Individually, SQLi exposes or modifies data and can reach RCE; stored XSS hijacks sessions in victims' browsers. Chained, you can use SQLi to plant a stored XSS payload that fires in an admin's session, steal their session, and escalate to full application control.
A great web pentester thinks in attack chains, not checklists. A scanner reports "reflected XSS, medium" and "SQLi, high" as two rows. A tester shows how, together, they become "full admin takeover, critical." That story is what drives remediation.
What each bug gives you alone
- SQL injection lets you read, modify, or delete data the app trusts. Depending on the database and privileges, it can escalate further: dumping password hashes, reading files (
LOAD_FILE), writing a web shell, or even RCE via features likexp_cmdshell(MSSQL) or stacked queries. - Cross-site scripting, especially stored XSS, runs attacker JavaScript in another user's browser — letting you steal session tokens, perform actions as that user, or keylog the page.
The chain
Consider an app where customer "notes" are stored via a SQL backend and later rendered in an admin review panel without proper output encoding:
- Inject via SQLi or a stored field: you place a stored XSS payload into a record — directly through the form, or by using SQL injection to write the malicious string into a column the app trusts and renders.
- Fire in a privileged context: an admin opens the review panel; your JavaScript executes in their authenticated session.
- Steal the session / act as admin: the payload exfiltrates the admin's session cookie (or, if HttpOnly, makes authenticated requests on their behalf via the app's own API) to create a new admin user or change settings.
- Deepen via SQLi: with admin access, you revisit the SQLi to dump the full user table, crack hashes, and pursue RCE on the DB host — pivoting from web app to infrastructure.
Each step is modest; the chain is a critical compromise.
Why this matters in reporting
Showing the realistic chain reframes risk from "two web bugs" to "an attacker takes over the admin and the database," which is the language that gets things fixed.
What interviewers look for
Chained thinking, accurate mechanics for each bug (stored XSS in a privileged context, SQLi-to-RCE paths), and the instinct to translate the chain into business impact rather than reciting OWASP categories.
Likely follow-ups
- How does a stored XSS in an admin panel lead to full account takeover?
- When can SQL injection escalate to remote code execution on the database server?
- Why is demonstrating a realistic chain more persuasive in a report than listing two separate findings?