Project #2, Web Security

For clarifications and hints, see the Stanford CS 155 FAQ. Also, slides from Stanford CS 155 sections covering web programming and this project specifically are available.

How to set up the environment

For this project, as in the first project, you are going to use the VMware virtual machine. Again, you can work on your own machine or you can use the machines in room B230 in the basement of EBU3B.

Setting up Boxes on your own machine

Download the updated VMware virtual machine tarball boxes2x.tar.bz2. (Note that this is not the same tarball as the one in the first project, so you cannot use that one!) Then you need to decompress this tarball, and run it with the VMplayer, exactly as you did it in the first project. Refer to the handout if you forgot how to do that. Once you have the Boxes set up, take a look at how you can run the iceweasel web browser within the box.

Using Boxes on the B230 machines

You need to perfrom the following:
  1. Login to any machine under Red Hat Linux using your CSE 127 username and password (if you don’t know your login information, you can find it here)

  2. Make a subdirectory (say named after your cse127 username, so that you can distinguish it from other direcotries) into the /scratch directory. Extract the Boxes virtual machine file /home/linux/ieng6/cs127s/public/boxes2x-2.1.tar.bz2 to that directory (assume you named it student), as follows.
    cd /home/linux/ieng6/cs127s/public/
    tar -xf boxes2x-2.1.tar.bz2 -C /scratch/student
    Don't try to extract the file to your ieng6 home directory because you will exceed your disk quota! (The /scratch directory is located on the local disk of the lab machine, which is why you have more space there.)

  3. Using the VMplayer run the Boxes2X.vmx located under /scratch/student/Boxes2X.vmwarevm. Now, take a look at how you can run the iceweasel web browser within the box.

  4. We recommend that you backup all of your work. But, if you want to save the state of your box (i.e. you want to have everything you created and saved within the box next time you run it), you can create a tarball of the Boxes2X.vmwarevm directory and copy it to your home directory on ieng6, as follows.
    cd /scratch/student
    tar cf - Boxes2X.vmwarevm | bzip2 > ~/boxes2x-2.1.tar.bz2
    Now if you want to run the saved box, in step 2 instead of extracting the box from the public/ directory, you will extract the one from your home directory.

How to run iceweasel

Iceweasel is the Debian version of firefox. Essentially it is the same browser, but it has a different name because of some licensing issues. To start iceweasel into the Boxes, login as user, and do the following:
  1. Type the startx command. This will start the X Window System, and a new window will be displayed with a xterm (shell) where you can enter commands.

  2. Type iceweasel within the new displayed shell. This will open the iceweasel browser.

Part 1. Attacks

The fictional "Zoobar Foundation" has set up a simple web application at, allowing registered users to post profiles and transfer "zoobar" credits between each other. Each registered user starts with 10 zoobars.

You will craft a series of attacks on 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 re-use parts of your code.

Although many real-world attackers do not have the source code for the web sites they are attacking, you are one of the lucky ones: you can find the source code under /var/zoobar in the Boxes. You won't actually need to look at the site's source code until Part 2, but it's there if you get stuck.

The zoobar server is actually run locally on each of your boxes. We will run your attacks after wiping clean our own local database of registered users (except the user named "attacker"). Of course this means that any data you have added while working on the assignment will not be present during grading.


Browser. We will grade your project within the box using debian's iceweasel, which is installed in the Boxes. Therefore, you should test your code in the boxes on this browser. Iceweasel is essentially the same browser as Mozilla's Firefox, but under different name. So, anything that works in iceweasel will work in Firefox as well. There are subtle quirks in the way HTML and JavaScript are handled by different browsers, and some attacks that work in Internet Explorer (for example) may not work in Firefox (and therefore in iceweasel). In particular, you should use the Mozilla way of adding listeners to events.

Email script. For Attacks A and C, you will need a server-side script to automatically email information captured by your client-side JavaScript to your user account within the Boxes. We have provided this script for you. Please review the instructions at (open this url from within the Boxes) and use that URL in your attack scripts to send emails. Again, this server is also being run locally on your own boxes machine. To check your local email use the mutt email client (type mutt in the shell to start the client, and follow the instructions).

Attack A. Cookie Theft

Attack B. Cross-Site Request Forgery

Attack C. Password Theft

Attack D. Profile Worm


Create files named a.txt, b.html, c.html, and d.txt, containing each of your four attacks. You may include a separate README file (we would appreciate any feedback you may have on this assignment). Submit your project as instructed in the turnin instructions.


Each attack is worth up to 3 points.

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.

Part 2: Defenses

Now that you've figured out how to hack the site, it's time to don your white hat and fix the vulnerabilities.



Do not add new files. Do not edit the files in the includes/ directory. Do not add new database tables or columns.

You will not receive credit for fixing any of the following issues: SQL injection vulnerabilities, attacks by other (non-zoobar) sites hosted on the same web server, database race conditions, buffer overflows, attacks that only work when register_globals is on, or lack of HTTPS.

There are no specific requirements for error messages on bad input. You can sanitize the input or simply die(), as long as you note your decision in the README file. Sanitizing is probably the more user-friendly option.


Submit the four files: index.php, users.php, transfer.php, and login.php. Include the usual ID file. Also include a README file (required) with a one-sentence description of each change you made, and what types of user input (if any) will cause your site to refuse requests or show error messages.

Submit your project as instructed in the turnin instructions.


Honor code

In Part 1 of this assignment, we are asking you to craft attacks to further your understanding of web application security and the consequences of poor input validation. It is highly illegal and unethical to send malicious code to unwitting recipients. Do not distribute your attacks outside your group.

An important aspect of the project is discovering the additional cross-site scripting vulnerabilities in Part 2, so we ask that you do not assist other groups in finding these vulnerabilities.


This is Project #2 from Stanford's CS 155, Computer and Network Security. Thanks to Collin Jackson for setting up and supporting the UCSD version. And thanks also to Dan Boneh, John Mitchell, David Mazières, and the 155 TAs.

Navigation: CSE // CSE 127 // Project 2