6.858 Fall 2014 Lab 5: Browser security

Handed out: Monday, October 27, 2014
Due: Friday, November 14, 2014 (5:00pm)

Introduction

This lab will introduce you to browser-based attacks, as well as to how one might go about preventing them.

When working on the exercises, you may find the following hints and tools useful:

Network setup

For this lab, you will be crafting attacks in your web browser that exploit vulnerabilities in the zoobar web application. To ensure that your exploits work on our machines when we grade your lab, we need to agree on the URL that refers to the zoobar web site. For the purposes of this lab, your zoobar web site must be running on http://localhost:8080/. If you have been using your VM's IP address, such as http://192.168.177.128:8080/, it will not work in this lab.

If you are using KVM or VirtualBox, the instructions we provided in lab 1 already ensure that port 8080 on localhost is forwarded to port 8080 in the virtual machine. If you are using VMware, we will use ssh's port forwarding feature to expose your VM's port 8080 as http://localhost:8080/. First find your VM IP address. You can do this by going to your VM and typing ifconfig. (This is the same IP address you have been using for past labs.) Then configure SSH port forwarding as follows (which depends on your SSH client):

The forward will remain in affect as long as the SSH connection is open.

Setting up the web server

Before you begin working on these exercises, please use Git to commit your Lab 3 solutions, fetch the latest version of the course repository, and then create a local branch called lab5 based on our lab5 branch, origin/lab5. Do not merge your lab 2 and 3 solutions into lab 5. Here are the shell commands:

httpd@vm-6858:~$ cd lab
httpd@vm-6858:~/lab$ git commit -am 'my solution to lab3'
[lab3 c54dd4d] my solution to lab3
 1 files changed, 1 insertions(+), 0 deletions(-)
httpd@vm-6858:~/lab$ git pull
Already up-to-date.
httpd@vm-6858:~/lab$ git checkout -b lab5 origin/lab5
Branch lab5 set up to track remote branch lab5 from origin.
Switched to a new branch 'lab5'
httpd@vm-6858:~/lab$ make
...

Note that lab 5's source code is based on the initial web server from lab 1. It does not include privilege separation or Python profiles.

Now you can start the zookws web server, as follows.

httpd@vm-6858:~$ ./zookld

Open your browser and go to the URL http://localhost:8080/. You should see the zoobar web application. If you don't, go back and double-check your steps. If you cannot get the web server to work, get in touch with course staff before proceeding further.

Crafting attacks

You will craft a series of attacks against the zoobar web site you have been working on in previous labs. These attacks exploit vulnerabilities in the web application's design and implementation. Each attack presents a distinct scenario with unique goals and constraints, although in some cases you may be able to re-use parts of your code.

We will run your attacks after wiping clean the database of registered users (except the user named "attacker"), so do not assume the presence of any other users in your submitted attacks.

You can run our tests with make check; this will execute your attacks against your server, and tell you whether your exploits seem to be working correctly or not. As in previous labs, keep in mind that the checks performed by make check are not exhaustive, especially with respect to race conditions.

Exercises 1, 3, and 4, as well as the challenge exercise, require that the displayed site look a certain way. The make check script is not quite smart enough to compare how the site looks like with and without your attack, so you will need to do that comparison yourself (and so will we, during grading). When make check runs, it generates reference images for what the attack page is supposed to look like (answer-XX.ref.png) and what your attack page actually shows (answer-XX.png), and places them in the lab5-tests/ directory. Make sure that your answer-XX.png screenshots look like the reference images in answer-XX.ref.png.

To view these images from lab5-tests/, either copy them to your local machine, or run python -m SimpleHTTPServer 8080 and view the images by visiting http://localhost:8080/lab5-tests/. Note that SimpleHTTPServer caches responses, so you should kill and restart it after a make check run.

We will grade your attacks with default settings using the current version of Mozilla Firefox on Ubuntu 12.04 (as installed on, e.g., the Athena workstations) browser at the time the project is due. We chose this browser for grading because it is widely available and can run on a variety of operating systems. There are subtle quirks in the way HTML and JavaScript are handled by different browsers, and some attacks that work or do not work in Internet Explorer or Chrome (for example) may not work in Firefox. In particular, you should use the Mozilla way of adding listeners to events. We recommend that you test your code on Firefox before you submit, to ensure that you will receive credit for your work.

For exercises 1 and 3, you will need a server-side script to automatically email information captured by your client-side JavaScript code to the TAs for grading. We have provided this script for you. Please review the instructions at http://css.csail.mit.edu/6.858/2014/labs/sendmail.php and use that URL in your attack scripts to send emails. You may send as many emails as you like while working on the project, but please do not attack or abuse the email script.

Exercise 1: Cookie Theft. Construct an attack that will steal a victim's cookie for the zoobar site when the victim's browser opens a URL of your choosing. (You do not need to do anything with the victim's cookie after stealing it, for the purposes of this exercise, although in practice an attacker could use the cookie to impersonate the victim, and issue requests as if they came from the victim.)

Please write your attack URL in a file named answer-1.txt. Your URL should be the only thing on the first line of the file.

For exercise 1, you will want the server to reflect back certain character strings to the victim's browser. However, the HTTP server performs URL decoding on your request before passing it on to the zoobar code. Thus, you'll need to make sure that your attack code is URL-encoded. For example, use + instead of space and %2b instead of +. Here is a URL encoding reference and a handy conversion tool. You can also use quoting functions in the python urllib module or the JavaScript encodeURIComponent function to URL encode strings.

Exercise 2: Cross-Site Request Forgery. Construct an attack that transfers zoobars from a victim to the attacker, when the victim's browser opens an HTML document that you construct. Do not exploit cross-site scripting vulnerabilities (where the server reflects back attack code), such as the one involved in exercise 1 above, or logic bugs in transfer.py that you fixed in lab 3.

For exercise 2, you should test if your attack works by opening your answer-2.html file in your browser, and seeing if you achieve the desired result while meeting the requirements for the attack.

For exercise 2, you will need to synthesize an HTTP POST request from your HTML page. To do so, consider creating an HTML form whose action attribute points to .../index.cgi/transfer, and which contains <input> fields with the necessary names and values. Look at the source of the HTML that's generated by index.cgi/transfer to get an idea of what this form should look like. You can submit a form by using JavaScript to invoke the click method on the submit button, or the submit method on the form itself.

Exercise 3: Side Channels and Phishing. Construct an attack that will steal a victim's zoobars, if the user is already logged in (using the attack from exercise 2), or will ask the victim for their username and password, if they are not logged in. The attack scenario is that the victim opens an HTML document that you constructed.

Exercise 4: Profile Worm. Create a worm that will transfer 1 zoobar from the victim to the attacker, and spread to the victim's profile, when the victim views the profile of another infected user. The scenario is that the first victim views the attacker's profile, and the worm spreads onward from there.

Please write your profile in a file named answer-4.txt.

For exercise 4, you may need to create an iframe and access data inside of it. You can use the DOM methods document.createElement and document.body.appendChild to do so. Getting access to form fields in an iframe differs by browser, and only works for frames from the domain (according to the same-origin policy). In Firefox, you can do iframe.contentDocument.forms[0].zoobars.value = 1;. Another approach may be to use XMLHttpRequest instead of an iframe.

Challenge: Password Theft. Create an attack that will steal the victim's username and password, even if the victim is diligent about entering their password only when the URL address bar shows http://localhost:8080/zoobar/index.cgi/login.

For this final attack, you may find that using alert() to test for script injection does not work; Firefox blocks it when it's causing an infinite loop of dialog boxes. Try other ways to probe whether your code is running, such as document.loginform.login_username.value=42.

Deliverables

Make sure you have the following files: answer-1.txt, answer-2.html, answer-3.html, answer-4.txt, and if you are doing the challenge, answer-chal.html, containing each of your attacks. Feel free to include any comments about your solutions in the answers.txt file (we would appreciate any feedback you may have on this assignment).

Run make submit to upload lab5-handin.tar.gz to the submission web site. You're done!

Acknowledgments

Thanks to Stanford's CS155 course staff for the original version of this assignment.