Project #3

Logistics

Out: May 24
Due: May 31

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 trick us into revealing personal information to you 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 filtered out every possible malicious search string, so long as it isn't a META tag. We are convinced we are now 100% secure. Our security auditors tell us that META tags can be co-opted to mount a cross-site scripting attack. We don't believe them. (You will be proving us wrong).

To improve the user experience, we save your last search term in a cookie in your browser. 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 three versions of the search engine. Specifically, for each version, you will need to:

Come up with a carefully crafted URL to exploit the cross-site scripting vulnerability,
Extract the search term saved in our cookie, and finally
Deliver it back to a location you control.

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.

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://128.208.3.85/~nmurphy/cse490k/xss-search.php

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

http://www.cs.washington.edu/education/courses/490k/07sp/projects/xss-search-form.html

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 three versions of the search engine behave as follows:

Version 1: No filtering
Version 2: SCRIPT tag filtered
Version 3: All but META tags correctly filtered

Our cookie is stored by the name "cse490k_search_cookie" in the domain "128.208.3.85".

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
Place your exploit URLs on a simple web page, and email a link to this page to yoshi at cs.washington.edu and nmurphy at cs.washington.edu. Being idiots, we will open your page and click on all of your exploit links.
Put the cookies' contents you have retrieved in a file named "search_terms.txt"
Put your three exploit URLs in a file named "exploits.txt"
Submit search_terms.txt, exploits.txt, and your CGI/PHP script via Catalyst at https://catalyst.washington.edu/webtools/secure/esubmit/turnin.cgi?owner=kohno&id=6021.

IMPORTANT: Our stupidity is limited. If you send us exploit URLs, we click on them, and they don't work, you may try to fix your URLs. However, we will only click on your links a maximum of 3 times! We also make no guarantees on how soon we will click on them. What does this mean? It means you should consider sending us your URLs tantamount to turning in your assignment, and it means you will want to test your URLs somehow. As it's currently implemented, the search engine will set the cookie on your browser to a fixed value ("combatwombat"). This is only for the sake of your testing. When the teaching staff tests your exploit, the cookie will have a different value.

Also note: we will be loading your exploit URLs in Firefox 2.0. In general, your exploits should be general enough to work in any browser with the exception of the META tag exploit which may not work in IE7.

Useful resources

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

Good luck!