As a red team member or pen tester, it is crucial to understand how web applications can be vulnerable to attacks. One common vulnerability is Cross-Site Scripting (XSS), where an attacker injects malicious code into a website that runs in a user’s browser. In this article, we will move beyond the basic <script>alert(1)</script> and explore how to weaponize XSS for full-scale network compromise.
1. The XSS Trifecta: Reflected, Stored, and DOM
Before we weaponize, we must classify.
- Reflected XSS: The payload is “reflected” off the web server to the victim (e.g., in a search query or error message). It requires a victim to click a link.
- Stored XSS: The most dangerous type. The payload is stored in the database (e.g., in a comment or profile field) and executed for every user who views the page.
- DOM-based XSS: The vulnerability exists entirely in the client-side code. The server never even sees the payload.
- Source:
location.hash,document.referrer,window.name. - Sink:
innerHTML,eval(),setTimeout().
- Source:
2. Weaponizing XSS: Beyond the Alert Box
An alert() box proves a vulnerability, but it doesn’t win an engagement.
Cookie Theft and Session Hijacking
The classic attack. If the HttpOnly flag is missing, you can steal the session cookie.
| |
The Power of BeEF (Browser Exploitation Framework)
BeEF is the primary tool for red teamers to manage hooked browsers. Once you “hook” a browser via XSS, you can:
- Enumerate the Internal Network: Use the victim’s browser as a pivot to scan internal IPs (e.g.,
192.168.1.1). - Social Engineering: Pop up fake “Session Timed Out” boxes to capture plaintext credentials.
- Browser Autopwn: Attempt to exploit browser-level vulnerabilities for RCE.
BeEF Hook Payload:
| |
3. Blind XSS: Hitting the Admin
Blind XSS occurs when your payload fires on a page you cannot see—typically an internal admin dashboard or log viewer.
Scenario: You submit an XSS payload in a “Contact Support” form or a User-Agent header. Two days later, an administrator opens their dashboard to review tickets, and your script executes in their high-privilege context.
Pro-Tip: Use XSS Hunter (or its open-source variant, XSS Hunter Express) to listen for these callbacks. It captures screenshots, DOM HTML, and cookies automatically.
4. Evasion and Filter Bypassing
Modern WAFs (Web Application Firewalls) look for <script> tags. We must be more creative.
Tag Obfuscation
| |
Polyglots
Payloads designed to break out of multiple contexts (attributes, scripts, comments).
| |
5. Bypassing CSP (Content Security Policy)
CSP is the “final boss” of XSS defense. It tells the browser which domains are allowed to execute scripts.
Common CSP Bypasses
- JSONP Callbacks: If the CSP allows a domain like
google.comand that domain has a JSONP endpoint, you can use it to execute code. - Unsafe-Inline: If the policy allows
'unsafe-inline', you can run scripts directly in the HTML. - Dangling Markup: If you can’t run scripts, you can sometimes use CSS or
<img>tags to exfiltrate data from the page by “dangling” an unclosed tag.
| |
This forces the browser to send everything up to the next quote (like a CSRF token) to your server.
6. XSS to RCE (Remote Code Execution)
In certain environments, XSS leads directly to full system compromise.
- Electron Apps: Many desktop apps (Slack, Discord, VS Code) are just browsers. XSS in an Electron app often allows you to access the
Node.jsAPI (require('child_process').exec(...)) and execute system commands. - Internal Management Panels: XSS in a tool like Jenkins or a router’s admin page can often be used to trigger features that execute code on the host via CSRF requests.
Conclusion
XSS is more than a nuisance; it is a gateway into the user’s digital identity and the internal network. By mastering BeEF, understanding Blind XSS, and learning to bypass modern defenses like CSP, you elevate your web exploitation skills from basic testing to advanced red teaming.
Always remember: if you can control the browser, you control the user.
Happy hunting!