XSS-TUNNELING

Archived educational proof-of-concept (2013). Not maintained.

A small "reverse shell over XSS" I built in 2013 to demonstrate, to developers and students, just how much damage a single cross-site scripting bug can do. Drop the payload into a vulnerable page and the attacker's console can drive the victim's browser: read accessible cookies and localStorage, watch the current page, log keystrokes, and push messages back.

It is deliberately simple and was only ever meant as a teaching aid. There are two interchangeable server implementations of the same idea: a Java / Spring MVC version and a smaller Python (Flask) version.

What it could do

• Retrieve non-HttpOnly cookies
• Retrieve the current URL and render the current page in an iframe
• Read localStorage contents
• Force the victim's browser to visit a page
• Show a message box
• Start / stop a keylogger

How it worked

The operator runs the local server and opens two pages: localhost:8080 (the console) and localhost:8080/victim (a stand-in target). A new victim connection shows up in the console, which can then queue commands that the injected hack.js polls for and executes in the victim's browser. In a real scenario the server is hosted somewhere reachable and hack.js is delivered through an actual XSS sink in a vulnerable site.

Does this still work today? (mostly not, and that is the point)

This is a time capsule. Twelve years of browser and platform hardening have quietly retired most of what it relied on:

• Delivery - Content-Security-Policy, which barely existed in 2013, now blocks injecting inline script and loading an attacker-hosted hack.js in most serious apps.
• Cookies - it only ever read non-HttpOnly cookies; SameSite=Lax is now the browser default and HttpOnly is standard practice, so there is far less to grab.
• The iframe trick - X-Frame-Options / CSP frame-ancestors stop a page being framed for spying.
• Exfiltration - tightened CORS and cookie handling make phoning home to a localhost:8080 console much harder.

The concept (XSS leads to an attacker-controlled JavaScript payload leads to a command-and-control channel) is still completely valid and still taught. If you want a maintained, modern take on the same idea, look at BeEF.

The code itself is a period piece too: the Python server targets Python 2 and the Java server is built on Spring 3.2 and the javax.* servlet APIs, so neither runs on a current stack without a port. It is kept here as-is for reference, not for use.

Disclaimer

Built purely as an educational proof-of-concept to show the impact of XSS. Only ever use techniques like this against systems you own or are explicitly authorized to test.