Homework #3

Due: Dec 7th, 11:45pm


I have some good news. For this assignment you get to take revenge on the teaching staff for all those frustrating hours of hacking we've subjected you to. You will play the clever, social engineering hacker, and we will play the poor, naive, click-happy user. It is your job to hack into our grades database through a cross-site scripting (XSS) vulnerability.

The story

Many moons ago, the teaching staff decided that they wanted in on the increasingly lucrative market for Internet search, and accordingly, they quickly cobbled together a rudimentary search engine implementation that they could peddle to venture capital in hopes of garnering some seed money. Our initial efforts resulted in a very simple search engine. It is so simple, in fact, that it returns no results. All it does is echo whatever search term you entered back to you. (The VC guys were also unimpressed).

In the process of developing our search engine, we went through several versions. In the first version, the search engine performed no filtering; it echoed verbatim whatever search term you enter. Unfortunately, our crack security team quickly discovered that this version of our search engine was vulnerable to a variety of cross-site scripting attacks. So, ever vigilant to security threats, we modified the search engine to filter any search terms that contain the <SCRIPT> html tag. We were convinced our search engine was now secure. Unfortunately, this too proved to be vulnerable. So, we developed yet a third search engine that filters requests that contain the word "script". We are convinced we are now 100% secure. Our security auditors tell us that even if we filter the word "script", a cross-site scripting attack is still possible. We don't believe them. (You will be proving us wrong). Additionally, you'll be testing our web site for a few other XSS vulnerabilities.

Since the VCs were uninterested in our search technology, we decided to expand our web offerings to include a database (used by us to store your project grades) and a bookmark manager called y.um.my. These services are all available with a Yoshoo! account, which uses cookies as an authentication token. We believe this is safe due to the same-origin policy.

In researching Yoshoo!, you heard from a disgruntled ex-TA that the beta version of y.um.my (which you can indicate to use) might be vulnerable to an SQL injection attack. He mentioned that some SQL attack detection is done, but he thinks you might be able to add yourself to Yoshi's Good List (Yoshi keeps a list of people he REALLY likes in a database table). After you buy the TA a coffee and a bagle (a great way to get information out of TAs), he also sends you the schema of Yoshi's Good List:

mysql> describe goodstudents;
| Field    | Type | Null | Key | Default | Extra |
| username | text | YES  | PRI | NULL    |       |

Your job

...should you choose to accept it (and we highly recommend that you do), is two fold:

Part 1:
to mount a cross-site scripting attack against all versions of the search engine, steal our login cookies, and change your project grade. Specifically, for each version, you will need to:
  1. Come up with a carefully crafted URL to exploit the cross-site scripting vulnerability,
  2. Extract our login cookie,
  3. Deliver it back to a location you control, and finally,
  4. Use this cookie to log in to Yoshoo! DB and change your grade.
To accomplish such feats, you will need to craft javascript that: You may also need to craft some javascript to set a cookie in the context of the Yoshoo! site. Obviously, you will also need a mechanism to collect the information the javascript gathers. To accomplish this, you will need to write a CGI (or PHP) script to collect information sent to it from your javascript code and store it in a file.

Part 1.5 (extra credit):
to mount an SQL injection attack to add yourself to Yoshi's Good List

The Specifics

Our search engine lives at:


It can be accessed through a simple interface we've set up at:


It is implemented as a PHP script that takes GET requests, and it takes two parameters: By way of summary, the versions of the search engine behave as follows:

The login cookie is stored under the name "authtoken" in the domain "yoshoo.cs.washington.edu".

The beta flag of y.um.my does "creative" SQL injection checking.

What you need to do

    Part 1:
  1. Construct the exploit URL for each version of the search engine (remember that the script must both read the cookie and somehow send it back to you!)
  2. Construct your CGI (or PHP) script to receive the cookie information sent by your scripts
  3. Set up your script from (2) to run on abstract.cs.washington.edu
  4. Upload your exploit URLs to Yoshoo!'s y.um.my service. Being idiots, we will visit all of your exploit links. Note: each of your links will be clicked on ONCE; we will check y.um.my for new links approximately once every minute or so.
  5. Put the cookies' contents you have retrieved in a file named "authtokens.txt"
  6. Put your exploit URLs in a file named "exploits.txt"
  7. Use the authentication cookie to change your grade on the project part from 0 to 8.
    Part 1.5 (extra credit):
  1. Use an SQL inject to add yourself to Yoshi's Good List.
  2. Add the inject you constructed to "exploits.txt" from Part 1.
Submit authtokens.txt, exploits.txt, and your CGI/PHP script(s), along with a README that tells us anything we should know about your implementation via Catalyst at https://catalyst.uw.edu/collectit/dropbox/kohno/24345 In the README, also give a short explanation of how each exploit works.

Note: for testing, you can use the authentication cookie set when you log into your Yoshoo! y.um.my account.
Also note: we will be loading your exploit URLs in Firefox 3.6.13

Useful resources

PHP tutorial
Javascript tutorial
Hackers.org cross-site scripting cheat sheet

FAQ and Errata

We will put answers to good questions and any errata for the project here.