Lab #2 - Web Security
Due: 22 November 2013, 5pm
We 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.
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 folks 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. To provide added value, the
bookmark manager visits each URL you store in it. These services are all
token. We believe this is safe due to the same-origin policy.
In researching Yoshoo!, you also heard from a disgruntled ex-TA that the beta
version of y.um.my (which you can opt-in to with a helpful checkbox) 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 bagel (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 | |
...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, 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.
to mount an SQL injection attack to add yourself to Yoshi's Good List
You may work in groups of up to three people on this lab.
To get a y.um.my account, email Adam with the UW Net IDs of all
group members and the desired group name and password. Don't forget to include the password,
or you may be assigned one that you don't like.
Our search engine 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 "yoshoo.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
- Upload your exploit URLs to Yoshoo!'s y.um.my service. Comforted by our naive overconfidence, 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/kohno/28907
In the README, also give a short explanation of how each exploit works.
- Use an SQL inject to add yourself to Yoshi's Good List.
- Add the inject 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 cookie-receiving scripts should run on
- You cannot directly log into
- The webserver will look for a
public_html directory in
your home folder. All your web documents must go there. If you don't
public_html folder, then make one:
- log into a department server (e.g.
chmod 711 public_html
echo "test" > public_html/index.html
chmod 644 public_html/index.html
- Now try to go to
- The database backend uses your UW Net IDs not your CSE Net IDs.
- Q: Is the clicking script working?
A: Yes, if your links are getting crossed off, it's working. If they're never crossed off, then they're not getting clicked and it's a problem on our end.
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 hosted on
- 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: 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 . For example, we've used this