6.893 Fall 2009 Lab 3: Browser security

Handed out:	Monday, October 19, 2009
Part 1 due:	Friday, October 30, 2009 (11:59pm)
All parts due:	Friday, November 6, 2009 (11:59pm)

Introduction

This lab will introduce you to browser-based attacks, as well as to how one might go about preventing them. For this lab, you will be using the Zoobar web application that you were working on in the previous lab. Be sure that you have a functional Zoobar web site running in your VM, as per the previous lab assignment, before you start working on this lab.

When working on the exercises, you may find the following hints and tools useful:

Before you begin working on these exercises, please edit the GNUmakefile from your current lab 2 code, so that you will be able to submit the changes you make as part of this lab as lab3-handin.tar.gz, and verify that make handin generates lab3-handin.tar.gz, as follows:

Part 1: Attacks

You will craft a series of attacks against the Zoobar web site you worked on in lab 2 that exploit vulnerabilities in the website's design. Each attack presents a distinct scenario with unique goals and constraints, although in some cases you may be able to re-use parts of your code.

We will run your attacks after wiping clean the database of registered users (except the user named "attacker"), so do not assume the presence of any other users in your submitted attacks.

Your attacks will run in a restricted network environment that can only connect to the VM running the zoobar code from lab 2, and to pdos.csail.mit.edu. We will run your attacks after wiping clean the database of registered users (except the user named "attacker").

Important: be sure that all of the attacks you develop for this lab work on the unmodified Zoobar web site (i.e. the one without any of the privilege separation that you implemented in the previous lab). While we expect that privilege separation would not impact the exploitability of most of the browser-based vulnerabilities that are explored in this lab, we want to be sure that we can grade your submissions consistently.

We will grade your attacks with default settings using the latest official release of the Mozilla Firefox browser at the time the project is due. We chose this browser for grading because it is widely available and can run on a variety of operating systems. There are subtle quirks in the way HTML and JavaScript are handled by different browsers, and some attacks that work in Internet Explorer (for example) may not work in Firefox. In particular, you should use the Mozilla way of adding listeners to events. We recommend that you test your code on Firefox before you submit, to ensure that you will receive credit for your work.

For exercises 1 and 3, you will need a server-side script to automatically email information captured by your client-side JavaScript code to the TAs for grading. We have provided this script for you. Please review the instructions at http://pdos.csail.mit.edu/6.893/2009/labs/lab3/sendmail.php and use that URL in your attack scripts to send emails. You may send as many emails as you like while working on the project, but please do not attack or abuse the email script.

Exercise 1: Cookie Theft. Construct an attack that will steal a victim's cookie for the Zoobar site when the victim's browser opens a URL of your choosing. (You do not need to do anything with the victim's cookie after stealing it, for the purposes of this exercise, although in practice an attacker could use the cookie to impersonate the victim, and issue requests as if they came from the victim.)

Your solution is a URL starting with http://zoobar-server-ip/zoobar/users.php?
The grader will already be logged in to the zoobar site before loading your URL.
Your goal is to steal the document cookie and email it to yourself using the email script.
Except for the browser address bar (which can be different), the grader should see a page that looks exactly as it normally does when the grader visits users.php. No changes to the site appearance or extraneous text should be visible. Avoiding the red warning text is an important part of this attack. (It's ok if the page looks weird briefly before correcting itself.)
Hint: Try this example attack as a starting point, while logged into your zoobar site: http://zoobar-server-ip/zoobar/users.php?user="><script>alert(document.cookie);</script>

For exercise 1, you will want the server to reflect back certain character strings to the victim's browser. However, the HTTP server performs URL decoding on your request before passing it on to the Zoobar PHP code. Thus, you'll need to make sure that your attack code is URL encoded. For example, use + instead of space and %2b instead of +. Here is a URL encoding reference and a handy conversion tool.

Exercise 2: Cross-Site Request Forgery. Construct an attack that transfers credits from a victim to the attacker, when the victim's browser opens an HTML document of your choosing. Do not exploit cross-site scripting vulnerabilities (where the server reflects back attack code), such as the one involved in exercise 1 above, or logic bugs in transfer.php that you fixed in lab 2.

Your solution is a short HTML document that the grader will open using the web browser.
The grader (victim) will already be logged in to the Zoobar site before loading your page.
Transfer 10 zoobars from the grader's account to the "attacker" account. The browser should be redirected to http://pdos.csail.mit.edu/6.893/2009/ as soon as the transfer is complete (so fast the user might not notice).
The location bar of the browser should not contain the zoobar server's name or address at any point.
Hint: Look at the sendmail script for ideas on how to issue HTTP GET requests from your HTML document.

For exercise 2, you will need to synthesize an HTTP POST request from your HTML page. To do so, consider creating an HTML form whose action attribute points to .../transfer.php, and which contains <input> fields with the necessary names and values. Look at the source of the HTML that's generated by transfer.php to get an idea of what this form should look like. You can submit a form by using JavaScript to invoke the click method on the submit button, or the submit method on the form itself.

Exercise 3: Side Channels and Phishing. Construct an attack that will steal a victim's credits, if the user is already logged in (using the attack from exercise 2), or ask the victim for their username and password, if they are not logged in.

Your solution is an HTML document that the grader will open using the web browser.
The grader will run the code once while logged in to the zoobar site before loading your page.
The grader will run the code a second time while not logged in to the zoobar site before loading your page.
When the browser loads your document, the document should sniff out whether the user is logged into the zoobar site:
- If the user is not logged in, present an HTML document visibly identical to the zoobar login page, by copying the HTML from the real zoobar login page (this should be self contained in the HTML file you turn in):
  - When the "Log in" button is pressed, send the username and password (separated by a comma) using the email script.
  - Once the email is sent, log the user into the real zoobar website (the URL should change to something at your VM's IP address).
  - The behavior for the Register button is left unspecified.
- If the user is logged in then forward to the attack from exercise 2.
Hint: The same origin policy does not allow you to access the documents of another domain loaded into an iframe. What types of files can be directly accessed by another domain?

Exercise 4: Profile Worm. Create a worm that will transfer 1 zoobar from the victim to the attacker, and spread to the victim's zoobar site profile, when the victim views the profile of another infected user.

Your solution is a profile that, when viewed, transfers 1 zoobar from the current user to a user called "attacker" (that's an actual username) and replaces the profile of the current user with itself.
Your malicious profile may include a witty message to the grader (optional, but it helps us see that it replicated).
To grade your attack, we will cut and paste the submitted profile file into the profile of the "attacker" user and view that profile using the grader's account. We will then view the copied profile with more accounts, checking for the transfer and replication.
The transfer and replication should be reasonably fast (under 15 seconds). During that time, the grader will not click anywhere.
During the transfer and replication process, the browser's location bar should remain at http://zoobar-server-ip/zoobar/users.php?user=username, where username is the user whose profile is being viewed. The visitor should not see any extra graphical user interface elements (e.g. frames), and the user whose profile is being viewed should appear to have 10 zoobars.
You will not be graded on the corner case where the user viewing the profile has no zoobars to send.
Hint: The site allows a sanitized subset of HTML in profiles, but you can get around it, either by finding strings that the sanitization forgets to block, or by finding a way to sneak a prohibited strings past it in a different form. This MySpace vulnerability may provide some inspiration.

For exercise 4, you may need to create an iframe and access data inside of it. You can use the DOM methods document.createElement and document.body.appendChild to do so. Getting access to form fields in an iframe differs by browser, and only works for frames from the domain (the Same Origin Policy). In Firefox, you can do iframe.contentDocument.forms[0].zoobars.value = 1;. Another approach may be to use XMLHttpRequest instead of an iframe.

Challenge: Password Theft. Create an attack that will steal the victim's username and password, even if the victim is diligent about only entering their password when the URL address bar shows the zoobar server's IP address.

Your solution is a short HTML document that the grader will open using the web browser.
The grader will not be logged in to the zoobar web site before loading your page.
Upon loading your document, the browser should immediately be redirected to http://zoobar-server-ip/zoobar/index.php. The grader will enter a username and password and press the "Log in" button.
When the "Log in" button is pressed, send the username and password (separated by a comma) using the email script.
The login form should appear perfectly normal to the user. No extraneous text (e.g. warnings) should be visible, and assuming the username and password are correct the login should proceed the same way it always does.
Hint: The site uses htmlspecialchars() to sanitize the reflected username, but something is not quite right.

For this final attack, you may find that using alert() to test for script injection does not work; Firefox blocks it when it's causing an infinite loop of dialog boxes. Try other ways to probe whether your code is running, such as document.loginform.login_username.value=42.

Deliverables

Create files named answer-1.txt, answer-2.html, answer-3.html, answer-4.txt, and if you are doing the challenge, answer-chal.html, containing each of your attacks. Include your zoobar VM's IP address in answers.txt so that we can reproduce your attacks. Feel free to include any comments about your solutions in the answers.txt file (we would appreciate any feedback you may have on this assignment).

Submit your project by running make handin and uploading the resulting lab3-handin.tar.gz file.

Beware of Race Conditions: Depending on how you write your code, all four of these attacks attacks could potentially have race conditions that affect the success of your attacks. Attacks that fail on the grader's browser during grading will receive less than full credit. To ensure that you receive full credit, you should wait after making an outbound network request rather than assuming that the request will be sent immediately.

Part 2: Defenses

Now that you've figured out how to hack the site, it's time to don your white hat and fix the vulnerabilities.

Exercise 5. Fix all of the bugs you exploited in the previous exercises, in either the unmodified zoobar code from your lab 2, or from the privilege-separated zoobar code from your lab 2. Describe the vulnerabilities that you fixed in the answers.txt file, and the kinds of inputs that you now prevent (just one sentence each is fine).

Prevent the attacks from Exercises 1, 2, 3, and 4, and the challenge. (You must prevent the challenge attack even if you didn't exploit it yourself).
Secure the site against any other cross-site scripting vulnerabilities you find.
Secure the site against any other cross-site request forgery vulnerabilities you find. (Exception: You don't need to prevent attacks that merely force users to log out without their permission.)
For defending against the attack from exercise 3:
- Somehow figure out how to stop leaking the information that tells if the user is logged in.
- Do some browser history sniffing yourself to determine if the user has visited http://pdos.csail.mit.edu/6.893/2009/labs/lab3/bad.html. If so then display a warning on the login page telling the user that their data may have been phished.
Do not change the site's appearance or behavior on normal inputs, except for the sniffing defense for the attack from exercise 3.

In preventing cross-site scripting vulnerabilities, consider all of the possible ways that an attacker can trick your Zoobar site into reflecting the attacker's HTML code to a victim. Remember that the victim can be given any possible URL to visit on the Zoobar site, and that URL need not involve any PHP code. It may be helpful to look at your ZooKWS configuration to understand how the server will handle different URLs that the attacker might construct.

You do not need to fix any of the following issues: SQL injection vulnerabilities, database race conditions, buffer overflows, attacks that only work when register_globals is on, or lack of HTTPS. (You will not receive any additional credit for fixing them.)

There are no specific requirements for error messages on bad input. You can sanitize the input or simply die(), as long as you note your decision in the answers.txt file. Sanitizing is probably the more user-friendly option.

Run make handin to generate the lab3-handin.tar.gz file and submit it as per instructions. You're done!

6.893 Fall 2009 Lab 3: Browser security

Introduction

Part 1: Attacks

Deliverables

Part 2: Defenses

Acknowledgments