Web Attack Lab
Due: May 20, 2015 at 5:00pm
Parts 1 and 1.5 are both required. Exploiting version 5 in Part 1 is extra credit.
Before you start
You may work individually or in groups of 2 or 3. You should have already filled out the survey with your group name, group members, and password.
I have some good news. For this assignment you get to take revenge on the
teaching staff for all those 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.
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
<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
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
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 Franzi's Good List (Franzi keeps a
list of people she REALLY likes in a database table). After you buy the TA a
coffee and a bagel (a great way to get information out of TAs), he also sends
you the schema of Franzi's Good List:
mysql> describe goodstudents;
| Field | Type | Null | Key | Default | Extra |
| username | text | YES | PRI | NULL | |
...should you choose to accept it (and we highly recommend that you do), is two fold:
to mount a cross-site scripting attack against all versions of the search
engine (part 5 is extra credit), 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.
- 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
it in a file.
Part 1.5 (correction: required, NOT extra credit!):
to mount an SQL injection attack to add yourself to Franzi's Good List
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:
version (int): the version of the search engine to implement
query (string): the query string
- Version 1: No filtering
- Version 2: No filtering if
<SCRIPT> tag included (really dumb mistake, but hey, it happens)
- Version 3: All instances of the word "script" filtered
- Version 4: All but
<IFRAME> tags correctly filtered
- Version 5: This one is for extra credit.
The login cookie is stored under the name "authtoken" in the domain "codered.cs.washington.edu".
The beta flag of y.um.my does "creative" SQL injection checking.
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 homes.cs.washington.edu (FAQ about homes)
- 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.
- 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://catalyst.uw.edu/collectit/dropbox/franzi/35015.
In the README, also give a short explanation of how each exploit works.
- Use a SQL injection to add yourself to Franzi's Good List.
- Add the injection you constructed to "exploits.txt" from Part 1.
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
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 homes.cs.washington.edu! For more details about how to build a website there, see CSE Support's FAQ.
- The database backend uses your UW Net IDs not your CSE Net IDs.
- Q: Is the clicking script working?
Q: Then why when I enter a link in my browser, I receive my cookie,
but when I add it as a bookmark, I never get the TA cookie?
A: There could be several reason for why it works when you click on it and not when the script clicks on it:
- You're using a browser that behaves significantly differently from Firefox 3.6.13
- Your code creates a popup / new window
- Your attack is not on homes.cs.washington.edu
- You have a space in the URL you paste (often the browser's
URL bar will catch this space and delete it for you, our clicking
script will not). Either delete the space or URL encode it (%20).
- Some part of your URL is not URL encoded (see reasoning for (4))
- Q: But I really want to test my exploits on Chrome!
A: Run Chrome from the command line with the XSS auditor turned off, using the flag --disable-xss-auditor
- Q: How do I add/view/modify cookies in my Firefox?
A: There are many ways, but the easiest is to use a Firefox
add-on. Several add-ons for cookie-related work can be found
here . I'm currently using this
- Q: How do I add my Bookmarks to y.um.my?
A: You need to log in using the account that Peter created for you based on your form submission.
- Q: What if I have more questions?
A: Please post non-personal questions to the discussion board so that other students who have solved the problem can give input. We will also answer any questions posted there.