Project 2: Web Application Security

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.

Part 1. Attacks

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.

Setup

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
http://crypto.stanford.edu/cs155/proj2/sendmail.php
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

Your solution is a URL starting with
http://zoobar.org/users.php?

The grader will already be logged in to zoobar.org
before loading your URL.

Your goal is to steal the document cookie and email it
to yourself and grader@zoobar.org using the
email script.

Except for the browser address bar (which can be different),
the grader should see a page that looks exactly
as it normally does when the grader visits
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.)

Attack B. Request Forgery

Your solution is a short HTML document that the grader will open
using the web browser.

The grader will already be logged in to zoobar.org
before loading your page.

Transfer 10 zoobars from the grader's account to the
"attacker" account. The browser should be redirected to
http://crypto.stanford.edu/cs155/ as soon as the
transfer is complete (so fast the user might not notice).

The location bar of the browser should not contain
zoobar.org at any point.

Hint: The POST data in transfer.php is not properly authenticated.

Attack C. Login Snooping

Your solution is a short HTML document that the grader will open
using the web browser.

The grader will not be logged in to zoobar.org
before loading your page.

Upon loading your document, the browser should immediately be
redirected to http://zoobar.org/. The grader will enter
a username and password and press the "Log in" button.

When the "Log in" button is pressed, send the username and
password (separated by a comma) using the
email script.

The login form should appear perfectly normal to
the user. No extraneous text (e.g. warnings) should be visible,
and assuming the username and password are
correct the login should work the same way it always does.

Hint: The site uses htmlspecialchars()
to sanitize the reflected username,
but something is not quite right.

Attack D. Profile Worm

Your solution is a profile
that, when viewed, transfers 1 zoobar from
the current user to a user called "attacker" and replaces the
profile of the current user with itself.

Your malicious profile may include a witty message to the grader
(optional, but it helps us see that it replicated).

To grade your attack,
we will cut and paste the submitted profile file
into the profile of the "attacker" user and view that profile
using the grader's account. We will then view the copied profile
with more accounts, checking for the transfer and replication.

The transfer and replication should be reasonably fast (under 15
seconds). During that time, the grader will not click anywhere.

During the transfer and replication process,
the browser's location bar should remain at
http://zoobar.org/users.php?user=username,
where username is 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.

Hint:
The site allows a sanitized
subset of HTML in profiles, but you can get around it.
This MySpace
vulnerability may provide some inspiration. (The
other MySpace attack
discussed in lecture will probably not work in Firefox.)

Deliverables

Create files named a.txt, b.html,
c.html, and d.txt,
containing each of your four attacks.
You should include the ID file the submit script asks for,
and you may also include a separate README file
(we would appreciate any feedback you may have on this assignment).
Submit your project
as pp2.part1 using /usr/class/cs155/bin/submit.

Grading

Each attack is worth 3 points.

Part 2: Defenses

In the second part of the project, you will modify the website
to fix the vulnerabilities.

Setup

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
called txt-db-api
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
http://cgi.stanford.edu/~yourusername/zoobar/.

Goals

Use input validation or escaping to prevent Attacks A, C, and D.

Implement a method for defending against cross-site request forgery requests by logged-in
users, preventing Attack B and a similar attack on index.php.

Secure the site against any other cross-site scripting
vulnerabilities you find.

Do not change the site's appearance or behavior on normal inputs.

Non-Goals

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.

Deliverables

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 any assumptions you are making about
valid user input.

Submit your project
as pp2.part2 using /usr/class/cs155/bin/submit.

Grading

We will copy your submission into the grader's web space. (To
avoid problems, avoid using absolute URLs on the site.)

We will also copy over a
fresh, unchanged version of the files in the
includes/ and db/ directories.

We will run the grader's solutions to Attack A, C, and D
against your site and check to make sure they don't work.
(1 point each)

We will look over your README
file and source code to ensure that
POST requests by logged-in users are properly authenticated.
(2 points)

We will look over your README
file and source code, and throw some short, malicious requests
at your site, to check for other
cross-site scripting vulnerabilities.
(1 point)

We will visit the site and verify that everything looks the same.
(possible penalty points)

Final notes

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.