Project #3, 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.

Part 1. Attacks

The fictional "Zoobar Foundation" is 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: source code is available. You won't actually need to look at the site's source code until Part 2, but it's there if you get stuck.

Your attacks will run in a restricted network environment that can only connect to and We will run your attacks after wiping clean the database of registered users (except the user named "attacker"), so any data you submitted to while working on the assignment will not be present during grading. We reserve the right to delete users from the database at any time if it gets too large, so please keep local copies of any important data you submit there.


Mozilla Firefox. We will grade your project with default settings using the latest official release of the Mozilla Firefox 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 in Internet Explorer (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.

Email script. For Attacks A and C, 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 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.

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 pp2.part1.tar by e-mail to


Each attack is worth up to 3 points.

Beware of Race Conditions: Depending on how you write your code, all four of these attacks 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.


Web server. You will need a web server that can run PHP scripts while you are working on the second part of the assignment. We'll be testing your attacks on the grader's ieng6 web space, so we recommend that you use the same configuration to ensure that your web site will work.

Further instructions will appear here soon.

You can need to enable CGI on your ieng6 account by following these instructions.

Project files. Once you have CGI-enabled your personal web space, run the following command on ieng6 to install the project website on your personal web space.

rsync -r /home/linux/ieng6/cs127w/cs127w/public_html/zoobar ~/public_html

Your site can now be accessed at



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 in the root directory of your site: 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 pp2.part2.tar by e-mail to


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, and choose non-obvious usernames on so that other groups will not accidentally stumble upon your work.

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. Do not connect to the websites that other groups have set up for Part 2.


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