Project #3, Web Security

Due: Friday, February 23rd, 11:59 PM

For clarifications and hints, see the FAQ.

How to set up the environment

For this project, as in previous projects, you are going to use a VirtualBox virtual machine.

Setting up pp3 on your own machine: Download the pp3 virtual machine image, pp3.ova (warning: 1.6 GB!). Note that this is not the same VM image as the one in previous projects, so you should not use those VMs. The ova file should load into VirtualBox.

Setting up port forwarding

The easiest way to access your VM from the host computer is with SSH. VirtualBox’s networking rules do not by default allow incoming connections to the VM, but you can set up a port forwarding rule, as follows. In the settings window for the pp3 VM, choose the “Network” tab, then show the “Advanced” options, and click the “Port Forwarding” button to bring up the port forwarding rules dialog.

In this dialog, you should create a rule binding Host IP, port 8024 (or another port of your choice) to Guest port 22 on the VM. Then click OK.

With port forwarding enabled, you can SSH into your VM using a command like “ssh bitbar@localhost -p 8024”.

Backing up your work

As with any project, you will want to make and keep frequent backups of your work. If you are developing your code in the bitbar home directory inside the VM, then an easy way to back this directory up is with the rsync command.

Suppose you have set up port forwarding so that port 8024 on the host forwards to port 22 on the VM. And suppose you’d like to back up into a directory called bkp123 in your home directory. Run the following command on the host:

rsync -av -e "ssh -p 8024" bitbar@localhost:pp3/ ~/bkp123/
If you run this command again later it will update the contents of bkp123 to match the contents of pp3 inside bitbar’s home directory.

To restore from backup, run the following command, again from the host:

rsync -av -e "ssh -p 8024" ~/bkp123/ bitbar@localhost:pp3/

Project Overview

The fictional “Bitbar” service has set up a simple Web application at http://localhost:3000 (inside the pp3 VM), allowing registered users to post profiles and transfer “bitbars” between each other. Each registered user starts with 200 bitbars.

You will craft a series of attacks on the Bitbar website that exploit vulnerabilities in the website’s design. Each attack presents a distinct scenario with unique goals and constraints, although in some cases you may be able to reuse parts of your code.

Although many real-world attackers do not have the source code for the websites they are attacking, you are one of the lucky ones: you can find the source code under ~/pp3/bitbar/app/ in the pp3 VM.

The Bitbar server is actually run locally on your VM. We will run your attacks after resetting our own local database of registered users. Of course this means that any data you have added while working on the assignment will not be present during grading.


This will make the Bitbar application available in the browser at the URL http://localhost:3000. You can close the server by pressing Ctrl + C in the terminal.

Browser: We will grade your project within the pp3 VM, using the Chromium browser. Therefore, you should test your code in the VM on this browser.

Attack X. Cookie Theft

Attack Y. Cross-Site Request Forgery

Attack Z. Profile Worm


Do not run the turnin script found in ~/pp3/attacks/; this script expects you to have solved four problems whereas this quarter we assigned only three. We will supply you with an updated turnin script to run. The script will look for the following files, but will pack everything in the attacks directory and send them to our server.

  1. Attack files x.txt, y.html, and z.txt.
  2. A filled out GROUP file, as in pp1 and pp2.

The last attack is substantially harder than the first two. We encourage you to start early!

Beware of Race Conditions: Depending on how you write your code, all four of these attacks could potentially have race conditions that affect the success of your attacks. Attacks that fail on the grader’s browser during grading will receive less than full credit. To ensure that you receive full credit, you should wait after making an outbound network request rather than assuming that the request will be sent immediately.


This is Project 2 from Stanford’s CS 155, Computer and Network Security. Thanks to Dan Boneh, John Mitchell, Collin Jackson, and the 155 TAs.

Navigation: CSE // CSE 127 // Project 3