Cross-Site Scripting Attack Lab 1
1 Overview
Cross-Site Scripting (XSS) Attack Lab (Web Application: Elgg)
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, attackers can steal a victim’s credentials, such as session cookies. The access control policies (i.e., the same origin policy) employed by browsers to protect those credentials can be bypassed by exploiting XSS vulnerabilities.
To demonstrate what attackers can do by exploiting XSS vulnerabilities, we have set up a web application named Elgg in our pre-built Ubuntu VM image. Elgg is a very popular open-source web application for social network, and it has implemented a number of countermeasures to remedy the XSS threat. To demonstrate how XSS attacks work, we have commented out these countermeasures in Elgg in our installation, intentionally making Elgg vulnerable to XSS attacks. Without the countermeasures, users can post any arbitrary message, including JavaScript programs, to the user profiles.
In this lab, students need to exploit this vulnerability to launch an XSS attack on the modified Elgg, in a way that is similar to what Samy Kamkar did to MySpace in 2005 through the notorious Samy worm. The ultimate goal of this attack is to spread an XSS worm among the users, such that whoever views an infected user profile will be infected, and whoever is infected will add you (i.e., the attacker) to his/her friend list. This lab covers the following topics, make sure that you look at further tutorials to have a good understanding of it.
2
• Cross-Site Scripting attack
• XSS worm and self-propagation
• Session cookies // https://www.w3schools.com/php/php_cookies.asp
• HTTP GET and POST requests
• JavaScript and Ajax // https://www.w3schools.com/js/js_ajax_intro.asp • Content Security Policy (CSP) // https://content-security-policy.com/
Recommended to look at for coursework
https://www.w3schools.com/php/php_form_validation.asp
Solution scripts are in XSS lecture slide and provided in Canvas as well.
Lab Environment
This lab can only be conducted in our Ubuntu 16.04 VM, because of the configurations that we have performed to support this lab. We summarize these configurations in this section.
The Elgg Web Application. We use an open-source web application called Elgg in this lab. Elgg is a web- based social-networking application. It is already set up in the pre-built Ubuntu VM image. We have also created several user accounts on the Elgg server and the credentials are given below.
Cross-Site Scripting Attack Lab 2
User
UserName
Password
Admin Alice Boby Charlie Samy
admin alice boby charlie samy
seedelgg seedalice seedboby seedcharlie seedsamy
DNS Configuration. We have configured the following URL needed for this lab. The folder where the web application is installed and the URL to access this web application are described in the following:
The above URL is 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 (127.0.0.1). You may map any domain name to a particular IP address using /etc/hosts. For example, you can map http://www.example.com to the local IP address by appending the following entry to /etc/hosts:
127.0.0.1 www.example.com
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 127.0.0.1.
Apache Configuration. In our pre-built VM image, we used 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 000-default.conf in the directory “/etc/ apache2/sites-available” contains the necessary directives for the configuration:
Inside the configuration file, 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. The following examples show how to configure a website with URL http://www.example1.com and another website with URL http://www.example2.com:
URL: http://www.xsslabelgg.com Folder: /var/www/XSS/Elgg/
ServerName http://www.example1.com DocumentRoot /var/www/Example_1/
ServerName http://www.example2.com 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 http://www.example1.com can be changed by modifying the sources in the /var/www/Example_1/ directory. After a change is made to the configuration, the Apache server needs to be restarted. See the following command:
$ sudo service apache2 start
Cross-Site Scripting Attack Lab 3
3 Lab Tasks
Preparation: Getting Familiar with the “HTTP Header Live” tool
In this lab, we need to construct HTTP requests. To figure out what an acceptable HTTP request in Elgg looks like, we need to be able to capture and analyze HTTP requests. We can use a Firefox add-on called “HTTP Header Live” for this purpose. Before you start working on this lab, you should get familiar with this tool. Instructions on how to use this tool is given in the Guideline section.
Task 1: Posting a Malicious Message to Display an Alert Window
The objective of this task is to embed a JavaScript program in your Elgg 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:
If you embed the above JavaScript code in your profile (e.g. in the brief description field), then any user who views your profile will see the alert window.
In this case, the JavaScript code is short enough to be typed into the short description 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 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
Task 3: Becoming the Victim’s Friend
In this and next task, we will perform an attack similar to what Samy did to MySpace in 2005 (i.e. the Samy Worm). We will write an XSS worm that adds Samy as a friend to any other user that visits Samy’s page. This worm does not self-propagate; in task 6, we will make it self-propagating.
In this task, we need to write a malicious JavaScript program that forges HTTP requests directly from the victim’s browser, without the intervention of the attacker. The objective of the attack is to add Samy as a friend to the victim. We have already created a user called Samy on the Elgg server (the user name is samy).
To add a friend for the victim, we should first find out how a legitimate user adds a friend in Elgg. More specifically, we need to figure out what are sent to the server when a user adds a friend. Firefox’s HTTP
Cross-Site Scripting Attack Lab 4
inspection tool can help us get the information. 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. Section 4 provides guidelines on how to use the tool.
Once we understand what the add-friend HTTP request look like, we can write a Javascript program to send out the same HTTP request. We provide a skeleton JavaScript code that aids in completing the task.
The above code should be placed in the "About Me" field of Samy’s profile page. This field provides two editing modes: Editor mode (default) and Text mode. The Editor mode adds extra HTML code to the text typed into the field, while the Text mode does not. Since we do not want any extra code added to our attacking code, the Text mode should be enabled before entering the above JavaScript code. This can be done by clicking on "Edit HTML", which can be found at the top right of the "About Me" text field.
Questions. Please answer the following questions:
• Question 1: Explain the purpose of Lines 1 and 2, why are they are needed?
• Question 2: If the Elgg application only provide the Editor mode for the "About Me" field, i.e., you cannot switch to the Text mode, can you still launch a successful attack?
Task 4: Modifying the Victim’s Profile
The objective of this task is to modify the victim’s profile when the victim visits Samy’s page. We will write an XSS worm to complete the task. This worm does not self-propagate; in a later task, we will make it self-propagating.
Similar to the previous task, we need to write a malicious JavaScript program that forges HTTP requests directly from the victim’s browser, without the intervention of the attacker. To modify profile, we should first find out how a legitimate user edits or modifies his/her profile in Elgg. More specifically, we need to figure out how the HTTP POST request is constructed to modify a user’s profile. We will use Firefox’s HTTP inspection tool. Once we understand how the modify-profile HTTP POST request looks like, we can write a JavaScript program to send out the same HTTP request. We provide a skeleton JavaScript code that aids in completing the task.
Cross-Site Scripting Attack Lab 5
Similar to Task 3, the above code should be placed in the "About Me" field of Samy’s profile page, and the Text mode should enabled before entering the above JavaScript code.
Questions. Please answer the following questions:
• Question 3: Why do we need Line À? Remove this line, and repeat your attack.
Task 5 - Optional : Writing a Self-Propagating XSS Worm
To become a real worm, the malicious JavaScript program should be able to propagate itself. Namely, whenever some people view an infected profile, not only will their profiles be modified, the worm will also be propagated to their profiles, further affecting others who view these newly infected profiles. This way, the more people view the infected profiles, the faster the worm can propagate. This is exactly the same mechanism used by the Samy Worm: within just 20 hours of its October 4, 2005 release, over one million users were affected, making Samy one of the fastest spreading viruses of all time. The JavaScript code that can achieve this is called a self-propagating cross-site scripting worm. In this task, you need to implement such a worm, which not only modifies the victim’s profile and adds the user “Samy” as a friend, but also add a copy of the worm itself to the victim’s profile, so the victim is turned into an attacker.
Cross-Site Scripting Attack Lab 6
To achieve self-propagation, when the malicious JavaScript modifies the victim’s profile, it should copy itself to the victim’s profile. There are several approaches to achieve this, and we will discuss two common approaches.
Link Approach: If the worm is included using the src attribute in the
Ã
It should be noted that innerHTML (line Á) only gives us the inside part of the code, not including the surrounding script tags. We just need to add the beginning tag (line Â) to form an identical copy of the malicious code.
When data are sent in HTTP POST requests with the Content-Type set to application/x-wwwform- urlencoded, which is the type used in our code, the data should also be encoded. The encoding scheme is called URL encoding, which replaces non-alphanumeric characters in the data with %HH, a percentage sign and two hexadecimal digits representing the ASCII code of the character. The encodeURICom ponent() function in line à is used to URL-encode a string.
Note: In this lab, you can try both Link and DOM approaches, but the DOM approach is required, because it is more challenging and it does not rely on external JavaScript code.
3.1 Elgg’s Countermeasures
This sub-section is only for information, and there is no specific task to do. It shows how Elgg defends against the XSS attack. Elgg does have built-in countermeasures, and we have deactivated and commented out them to make the attack work. Actually, Elgg uses two countermeasures. One is a custom built security
Cross-Site Scripting Attack Lab 7
plugin HTMLawed, which, on activation, validates the user input and removes the tags from the input. This specific plugin is registered to the \function filtertags" in the elgg/engine/lib/input. php file.
To turn on the countermeasure, login to the application as admin, goto Account->administration (top right of screen) →plugins (on the right panel), and click on security and spam under the filter options at the top of the page. You should find the HTMLawed plugin below. Click on Activate to enable the countermeasure.
In addition to the HTMLawed 1.9 security plugin in Elgg, there is another built-in PHP method called \htmlspecialchars()", which is used to encode the special characters in user input, such as "<" to \<", ">" to \>", etc. Please go to /var/www/XSS/Elgg/vendor/elgg/elgg/views/ default/output/ and find the function call \htmlspecialchars" in text.php, url.php, dropdown.php and email.php files. Uncomment the corresponding "htmlspecialchars" function calls in each file.
3.2 optional Task 7: Defeating XSS Attacks Using CSP
The fundamental problem of the XSS vulnerability is that HTML allows JavaScript code to be mixed with data. Therefore, to fix this fundamental problem, we need to separate code from data. There are two ways to include JavaScript code inside an HTML page, one is the inline approach, and the other is the link approach.
The inline approach directly places code inside the page, while the link approach puts the code in an external file, and then link to it from inside the page.
The inline approach is the culprit of the XSS vulnerability, because browsers do not know where the code originally comes from: is it from the trusted web server or from untrusted users? Without such knowledge, browsers do not know which code is safe to execute, and which one is dangerous. The link approach provides a very important piece of information to browsers, i.e., where the code comes from. Websites can then tell browsers which sources are trustworthy, so browsers know which piece of code is safe to execute. Although attackers can also use the link approach to include code in their input, they cannot place their code in those trustworthy places.
How websites tell browsers which code source is trustworthy is achieved using a security mechanism called Content Security Policy (CSP). This mechanism is specifically designed to defeat XSS and ClickJacking attacks. It has become a standard, which is supported by most browsers nowadays. CSP not only restricts JavaScript code, it also restricts other page contents, such as limiting where pictures, audio, and video can come from, as well as restricting whether a page can be put inside an iframe or not (used for defeating ClickJacking attacks). Here, we will only focus on how to use CSP to defeat XSS attacks.
Run a web server. CSP is set by the web server. Let us use a web page to see CSP in action. Although we can use the Apache server (already installed in our VM) to host the web page, we decide to write a simple HTTP server to do this job. The following Python program runs an HTTP server that listens to port 8000. Upon receiving a request, it loads a static file and return it to the client. In the response, the server adds a CSP header, setting the policy on the JavaScript code inside the page.
Listing 1: A simple HTTP server httpserver.py
Cross-Site Scripting Attack Lab 8
#!/usr/bin/env python3
from http.server import HTTPServer, BaseHTTPRequestHandler from urllib.parse import *
class MyHTTPRequestHandler(BaseHTTPRequestHandler):
def do_GET(self):
o = urlparse(self.path)
f = open("." + o.path, ’rb’) self.send_response(200) self.send_header(’Content-Security-Policy’,
"default-src ’self’;"
"script-src ’self’ *.example68.com:8000 ’nonce-1rA2345’ ") self.send_header(’Content-type’, ’text/html’) self.end_headers() self.wfile.write(f.read()) f.close()
httpd = HTTPServer((’127.0.0.1’, 8000), MyHTTPRequestHandler) httpd.serve_forever()
Please download the zip file csp.zip from the lab’s website, unzip it, and then enter the csp folder. Make httpserver.py executable, and then run this server program inside the csp folder.
The web page for the experiment. To see how the CSP policies work, we wrote the following HTML page, which contains six areas, area1 to area6. Initially, each area displays "Failed". The page also includes six pieces of JavaScript code, each trying to write "OK" to its corresponding area. If we can see OK in an area, that means, the JavaScript code corresponding to that area has been executed successfully; otherwise, we would see Failed.
Listing 2: The experiment web page csptest.html
Cross-Site Scripting Attack Lab 9
CSP Test
1. Inline: Correct Nonce: Failed
2. Inline: Wrong Nonce: Failed
3. Inline: No Nonce: Failed
4. From self: Failed
5. From example68.com: Failed
6. From example79.com: Failed
Set up DNS. We need to set up the DNS entry, so the above web server can be accessed via three different URLs. Add the following three entries to the /etc/hosts file. You need to use the root privilege to change this file (using sudo).
Lab tasks. Please complete the following tasks.
1. Point your browser to the following URLs. Describe and explain your observation.
2. Change the server program (not the web page), so Fields 1, 2, 4, 5, and 6 all display OK. Please include your code in the lab report.
4 Optional task
4.1 : 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
127.0.0.1 www.example32.com
127.0.0.1 www.example68.com
127.0.0.1 www.example79.com
http://www.example32.com:8000/csptest.html http://www.example68.com:8000/csptest.html http://www.example79.com:8000/csptest.html
Cross-Site Scripting Attack Lab 10
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.
We can do this by having the malicious JavaScript insert an 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 (with IP address 10.1.2.5), where the attacker has a TCP server listening to the same port.
A commonly used program by attackers is netcat (or nc) , which, if running with the "-l" option, becomes a TCP server that listens for a connection on the specified port. This server program basically prints out whatever is sent by the client and sends to the client whatever is typed by the user running the server. Type the command below to listen on port 5555:
$ nc -l 5555 -v
The ”-l” option is used to specify that nc should listen for an incoming connection rather than initiate a connection to a remote host. The ”-v” option is used to have nc give more verbose output.
The task can also be done with only one VM instead of two. For one VM, you should replace the attacker’s IP address in the above script with 127.0.0.1. Start a new terminal and then type the nc command above.
5 Guidelines
5.1 Using the "HTTP Header Live" add-on to Inspect HTTP Headers
The version of Firefox (version 60) in our Ubuntu 16.04 VM does not support the LiveHTTPHeader add-on, which was used in our Ubuntu 12.04 VM. A new add-on called "HTTP Header Live" is used in its place. The instruction on how to enable and use this add-on tool is depicted in Figure 1. Just click the icon marked by À; a sidebar will show up on the left. Make sure that HTTP Header Live is selected at position Á. Then click any link inside a web page, all the triggered HTTP requests will be captured and displayed inside the sidebar area marked by Â. If you click on any HTTP request, a pop-up window will show up to display the selected HTTP request. Unfortunately, there is a bug in this add-on tool (it is still under development); nothing will show up inside the pop-up window unless you change its size (It seems that re-drawing is not automatically triggered when the window pops up, but changing its size will trigger the re-drawing).
3
2
1
Cross-Site Scripting Attack Lab 11
Figure 1: Enable the HTTP Header Live Add-on
5.2 Using the Web Developer Tool to Inspect HTTP Headers
There is another tool provided by Firefox that can be quite useful in inspecting HTTP headers. The tool is the Web Developer Network Tool. In this section, we cover some of the important features of the tool. The Web Developer Network Tool can be enabled via the following navigation:
We use the user login page in Elgg as an example. Figure 2 shows the Network Tool showing the HTTP POST request that was used for login.
To further see the details of the request, we can click on a particular HTTP request and the tool will show the information in two panes (see Figure 3).
The details of the selected request will be visible in the right pane. Figure 4(a) shows the details of the login request in the Headers tab (details include URL, request method, and cookie). One can observe both request and response headers in the right pane. To check the parameters involved in an HTTP request, we can use the Params tab. Figure 4(b) shows the parameter sent in the login request to Elgg, including
Figure 2: HTTP Request in Web Developer Network Tool
Figure 3: HTTP Request and Request Details in Two Panes
username and password. The tool can be used to inspect HTTP GET requests in a similar manner to HTTP POST requests.
Font Size. The default font size of Web Developer Tools window is quite small. It can be increased by focusing click anywhere in the Network Tool window, and then using Ctrl and + button.
Click Firefox’s top right menu --> Web Developer --> Network or Click the "Tools" menu --> Web Developer --> Network
Cross-Site Scripting Attack Lab 12
5.3 JavaScript Debugging
We may also need to debug our JavaScript code. Firefox’s Developer Tool can also help debug JavaScript code. It can point us to the precise places where errors occur. The following instruction shows how to enable this debugging tool:
Once we are in the web console, click the JS tab. Click the downward pointing arrowhead beside JS and ensure there is a check mark beside Error. If you are also interested in Warning messages, click Warning. See Figure 5.
If there are any errors in the code, a message will display in the console. The line that caused the error appears on the right side of the error message in the console. Click on the line number and you will be taken to the exact place that has the error. See Figure 6.
(a) HTTP Request Headers (b) HTTP Request Parameters Figure 4: HTTP Headers and Parameters
Figure 5: Debugging JavaScript Code (1)
Please also list the important code snippets followed by explanation. Simply attaching code without any explanation will not receive credits.
Click the "Tools" menu --> Web Developer --> Web Console or use the Shift+Ctrl+K shortcut.
Cross-Site Scripting Attack Lab
13
Acknowledgement/Reference
Figure 6: Debugging JavaScript Code (2)
Copyright © 2006 - 2020 Wenliang Du, All rights reserved.
Free to use for non-commercial educational purposes. Commercial uses of the materials are prohibited. The SEED project was funded by multiple grants from the US National Science Foundation.