Project #3
Logistics
- Out: March 4
- Due: March 14, 11:59pm
As with previous assignments, you may work in groups of up to 3.
Overview
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.
Your job
...should you choose to accept it (and we highly recommend that you do), is 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:
- Come up with a carefully crafted URL to exploit the cross-site scripting vulnerability,
- Extract our login cookie,
- Deliver it back to a location you control, and finally,
- Use this cookie to log in to Yoshoo! DB and change your grade.
To accomplish such feats, you will need to craft javascript that:
- Evades the filter for the version of the search engine you're attacking,
- Reads the cookie on the victim's browser, and
- Sends the contents of the cookie back to a script you control.
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.
The Specifics
Our search engine lives at:
http://yoshoo.degdeg.com/xss-search.php
It can be accessed through a simple interface we've set up at:
http://yoshoo.degdeg.com/
It is implemented as a PHP script that takes GET requests, and it takes two parameters:
version
(int): the version of the search engine to implement
query
(string): the query string
By way of summary, the versions of the search engine behave as follows:
- Version 1: No filtering
- Version 2: No filtering if
<SCRIPT>
tag included
- Version 3: All instances of the word "script" filtered
- Version 4: All but
<META>
tags correctly filtered
- Version 5: This one is for extra credit.
The login cookie is stored under the name "authtoken" in the domain "yoshoo.degdeg.com".
What you need to do
- 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!)
- Construct your CGI (or PHP) script to receive the cookie information sent by your scripts
- Set up your script from (2) to run on abstract.cs.washington.edu
- Upload your exploit URLs to Yoshoo!'s y.um.my service. Being idiots, we will visit all of your exploit links.
- Put the cookies' contents you have retrieved in a file named "authtokens.txt"
- Put your exploit URLs in a file named "exploits.txt"
- Use the authentication cookie to change your grade on the project part from 0 to 10.
- 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://catalysttools.washington.edu/collectit/assignment/kohno/1225/5467.
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 2.0.
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.
- Your script must run on abstract.cs.washington.edu!