1 Overview

The overview of this lab is to help you understand Cross-Site Scripting (XSS) and cross-site-request forgery (CSRF or XSRF) attacks.

A CSRF attack involves a victim user, a trusted site, and a malicious site. The victim user holds an active session with a trusted site and simultaneously visits a malicious site. The malicious site injects an HTTP request for the trusted site into the victim user session compromising its integrity.

Cross-site scripting (XSS) is a type ofvulnerability commonly found in web applications. This vulnerability makes it possible for attackers to inject malicious code (e.g.,  JavaScript programs) into the victim’s web browser. Using this malicious code, the attackers can steal the victim’s credentials, such as cookies. The access control policies (i.e., the same origin policy) employed by the browser to protect those credentials 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 and CSRF vulnerabilities, we have set up a social networking web application Elgg, which has already been installed in our VM. We modified the software to introduce XSS and CSRF vulnerabilities. You need to exploit these vulnerabilities and implement your own CSRF and XSS attacks.

NOTE: The original application has implemented several countermeasures for avoiding XSS and CSRF attacks.

2 Lab Environment

This lab can only be conducted in our Ubuntu 16.04(32bit) VM, because of the configurations that we have performed to support this lab. The VM can be downloaded from the following link:

https://drive.google.com/file/d/1VU-UckX08C2ZLXpY8jbAhXhToKgez0pV/view?usp=sharing

Root password: “1”

If you encounter an error saying, “Kernel Panic - not syncing: Attempted to kill the idle task” while trying to install the VM using VirtualBox on Windows, please assign more than two processor cores in “Settings - > System -> Processor” .

The ElggWeb 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 UbuntuVM image. We have also created several user accounts on the Elgg server and the credentials are given below:

DNS Configuration. This lab involves two websites, the victim website and the attacker’s website. Both websites are set up on our VM. Their URLs and folders are described in the following:

The above URLs are 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

Ifyour 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.comand another website with URLhttp://www.example2.com:

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:

3 Background of CSRF Attacks

A CSRF attack always involved three actors: a trusted site, a victim user, and a malicious site. The victim user simultaneously visits the malicious site while holding an active session with the trusted site. The attack involves the following sequence of steps:

1.  The victim user logs into the trusted site using his username and password, and thus creates a new session.

2.  The trusted site stores the session identifier for the session in a cookie in the victim user’s web browser.

3.  The victim user visits a malicious site.

4.  The malicious site’s web page sends a request to the trusted site from the victim user’s browser.

5.  The web browser automatically attaches the session cookie to the malicious request because it is targeted for the trusted site.

6.  The trusted site processes the malicious request forged by the attacker web site.

The malicious site can forge both HTTP GET and POST requests for the trusted site. Some HTML tags such as img, iframe,frame, andform have no restrictions on the URL that can be used in their attribute. HTML img, iframe, andframe can be used for forging GET requests. The HTML form tag can be used for forging POST requests. The tasks in this lab involve forging both GET and POST requests for a target application.

Note: We have included some warm-up tasks so that you get used to the vulnerability concepts. These warm-up tasks are NOT gradable, and therefore MUST NOT be submitted as part of your solution. However, it is recommended that you try them out so that you get familiarized with the attack mechanisms, in case you’re not.

4 CSRF Lab Tasks

For the lab tasks, you will use two web sites that are locally setup in the virtual machine. The first web site is the vulnerable Elgg site accessible atwww.csrflabelgg.com inside the virtual machine. The second web site is the attacker’s malicious web site that is used for attacking Elgg. This web site is accessible via www.csrflabattacker.com inside the virtual machine.

NOTE: The source for the webpage www.csrflabattacker.com is present at /var/www/CSRF/Attacker/.

Warm-up: Attack using HTTP GET request

In Cross-Site Request Forget attacks, we need to forge HTTP requests. Therefore, we need to know what a legitimate HTTP request looks like and what parameters it uses, etc. We can use a Firefox add-on called "HTTP Header Live"for this purpose. The goal ofthis task is to get familiar with this tool. Instructions on how to use this tool is given in the Guideline section (§ 6. 1). Please use this tool to capture an HTTP GET request and an HTTP POST request in Elgg. In your report, please identify the parameters used in this these requests, if any.

In this task, we need two people in the Elgg social network: Alice and Boby. Boby wants to become a friend to Alice, but Alice refuses to add him to her Elggfriend list. Boby decides to use the CSRF attack to achieve his goal. He sends Alice an URL (via an email or a posting in Elgg); Alice, curious about it, clicks on the URL, which leads her to Boby’s web site: www.csrflabattacker.com. Pretend that you are Boby, describe how you can construct the content of the web page, so as soon as Alice visits the web page, Boby is added to the friend list of Alice (assuming Alice has an active session with Elgg).

To add a friend to the victim, we need to identify what the legitimate Add-Friend HTTP request (a GET request) looks like. We can use the "HTTP Header Live"Tool to do the investigation. In this task, you are not allowed to write JavaScript code to launch the CSRF attack. Yourjob is to make the attack successful as soon as Alice visits the web page, without even making any click on the page (hint: you can use the img tag, which automatically triggers an HTTP GET request). You may expect to see something similar to the following in the file Task1.html (your attack html):

To implement the html, you need to copy this file into Attacker’s website floder :/var/www/CSRF/

Attackers.

Elgg has implemented a countermeasure to defend against CSRF attacks. In Add-Friend HTTP requests,    you may notice that each request includes two wired-looking parameters , elgg ts and elgg token.     These parameters are used by the countermeasure, so if they do not contain correct values, the request will not be accepted by Elgg. We have disabled the countermeasure for this lab, so there is no need to include these two parameters in the forged requests.

Task 1: Attack in HTTP POST request (4 marks)

After adding himself to Alice’s friend list, Boby wants to do something more. He wants Alice to say “Boby is my Hero” in her profile, so everybody knows about that. Alice does not like Boby, let alone  putting that statement in her profile. Boby plans to use a CSRF attack to achieve that goal. That is the  purpose of this task.

One way to do the attack is to post a message to Alice’s Elgg account, hoping that Alice will click the URL inside the message. This URL will lead Alice to your (i.e., Boby’s) malicious web  site www. csrflabattacker.com, where you can launch the CSRF attack.

The objective of your attack is to modify the victim’s profile. In particular, the attacker needs to forge a request to modify the profile information of the victim user of Elgg. Allowing users to modify their profiles is a feature of Elgg. If users want to modify their profiles, they go to the profile page of Elgg, fill out a form, and then submit the form—sending a POST request—to the server-side script                       /profile/edit.php, which processes the request and does the profile modification.

The server-side script edit.php accepts both GET and POST requests, so you can use the same trick as that in Warm-up to achieve the attack. However, in this task, you are required to use the POST request. Namely, attackers (you) need to forge an HTTP POST request from the victim’s browser, when the victim is visiting their malicious site. Attackers need to know the structure of such a request. You can observe the structure of the request, i.e., the parameters of the request, by making some modifications to the profile and monitoring the request using the "HTTP Header Live" tool. You may see something similar to the following. Unlike HTTP GET requests, which append parameters to the URL strings, the parameters of HTTP POST requests are included in the HTTP message body (see the contents between the two symbols):

After understanding the structure of the request, you need to be able to generate the request from your attacking web page using JavaScript code. To help you write such a JavaScript program, we provide a sample code in the following You can use this sample code to construct your malicious web site for the CSRF attacks. This is only a sample code, and you need to modify it to make it work for your attack.