Due: Part 1 Friday, May 12th. Part 2 Thursday, May 18th (Note: CGI activation may take up to 24 hours)
Further clarifications and hints will be posted in the FAQ. Also, slides from section are available.
The fictional "Zoobar Foundation" is hosting 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: source code is available here. You don't actually need to look at the site's source code until Part 2.
Your attacks will run in a restricted network environment that can only connect to zoobar.org and crypto.stanford.edu. 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 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.
http://crypto.stanford.edu/cs155/as soon as the transfer is complete (so fast the user might not notice).
zoobar.orgat any point.
transfer.phpis not properly authenticated.
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 should include the
ID file the submit script asks for,
and you may also include a separate
(we would appreciate any feedback you may have on this assignment).
Submit your project
Each attack is worth 3 points.
In the second part of the project, you will modify the website to 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 CGI-enabled Stanford personal web space, so we recommend that you use the same configuration to ensure that your web site will work. You can need to enable CGI on your Stanford account by following these instructions. Activation may take up to 24 hours, so be sure to get a head start.
Project files. Once you have CGI-enabled your personal web space, run the following command from a Leland machine to install the project website on your personal web space.
cp -r /usr/class/cs155/projects/pp2/zoobar ~/cgi-bin
SQL database. The website uses a flat file SQL database
to manage persistent user state.
The database engine
needs to be able to write to your
db folder, so
run this command to give it access:
fs setacl ~/cgi-bin/zoobar/db system:cgi-servers write
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 sites hosted on cgi.stanford.edu, database race conditions, buffer overflows, vulnerabilities in PHP itself, or lack of HTTPS.
Do not worry about 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:
Include the usual
Also include a
README file (required) with a
one-sentence description of each
change you made, and any assumptions you are making about
valid user input.
READMEfile and source code to ensure that POST requests by logged-in users are properly authenticated. (2 points)
READMEfile and source code, and throw some short, malicious requests at your site, to check for other cross-site scripting vulnerabilities. (1 point)
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
zoobar.org so that
other groups will not accidentally stumble upon your work.
Do not connect to the websites that other groups have set up for Part 2.
Please check the FAQ for further clarifications and hints on this assignment.