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.
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.
tar -xf boxes2x.tar.bz2 -C /scratch/studentDon'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.)
tar cf - Boxes2.vmwarevm | bzip2 > ~/boxes2x.tar.bz2Now 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 iceweaselIceweasel is the debain 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:
The fictional "Zoobar Foundation" has set up a simple web application at zoobar.org, 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 zoobar.org 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.
We will run your attacks after wiping clean the database of registered users (except the user named "attacker"), so any data you submitted to zoobar.org while working on the assignment will not be present during grading. We reserve the right to delete users from the zoobar.org database at any time if it gets too large, so please keep local copies of any important data you submit there.
zoobar.orgbefore loading your URL.
users.php. No changes to the site appearance or extraneous text should be visible. Avoiding the red warning text is an important part of this attack. (It's ok if the page looks weird briefly before correcting itself.)
zoobar.orgbefore loading your page.
www-cse.ucsd.edu/classes/fa08/cse127as soon as the transfer is complete (so fast the user might not notice).
zoobar.orgat any point.
zoobar.orgbefore loading your page.
http://zoobar.org/. The grader will enter a username and password and press the "Log in" button.
htmlspecialchars()to sanitize the reflected username, but something is not quite right.
usernameis the user whose profile is being viewed. The visitor should not see any extra graphical user interface elements (e.g. frames), and the user whose profile is being viewed should appear to have 10 zoobars.
Create files named
containing each of your four attacks.
You may include a separate
(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 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.
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,
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:
Include the usual
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.
READMEfile and source code to ensure that all cross-site request forgery attacks are prevented. (2 points)
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.