Project 2 FAQ

Main project page

General

What is the late policy for programming projects?

Every student in the class is given a total of 72 late hours that can be applied to the projects and homeworks. These late hours must be taken in chunks of 24 hours (essentially 3 late days) for example, submitting a homework 3 hours later than it's due counts as 24 late hours used. After all your late hours are used up, the assignment score gets halved with every 24 hours the assignment is late — for example, someone submitting a project 47 hours late after having used all her late days will get (1/2)^2 = 1/4 of the grade. If a project has more than one part, each part is considered a separate assignment for late days — for example, if you submit part 1 72 hours late and part 2 24 hours late, then part 1 gets full credit and part 2 gets half credit. Note that no late hours can be used on the last part of the last programming project.

Is magic_quotes_gpc enabled on the web server?

Yes, it's enabled on both zoobar.org and cgi.stanford.edu. The optional magic_quotes_gpc PHP feature escapes single quotes, double quotes, and backslashes in GET and POST data by prepending a backslash. This feature makes it slightly harder to write websites that are vulnerable to cross-site scripting and SQL injection attacks. However, as you will see in this assignment, there are still lots of holes to fix. There are many ways that sites can turn off magic_quotes_gpc, such as .htaccess files, php.ini files, and by calling stripslashes on the escaped data. Note that magic_quotes_gpc doesn't do anything to angle brackets (<>). For that, you want htmlspecialchars.

Is register_globals enabled on the web server?

No, we've turned it off on zoobar.org and it's off by default on cgi.stanford.edu. The login page is vulnerable to an attack if register_globals is on, which you are welcome to fix if you want in Part 2. (This isn't part of the grading for the assignment, however.)

Why do I get an error when I try to visit login.php with my web browser?

Actually, login.php isn't intended to be viewed directly. It's just a library of functions that get called if the user tries to view one of the other pages and isn't logged in yet.

Is http://zoobar.org/ different from http://www.zoobar.org/?

They contain the same website, but will be treated as separate domains by the browser for purposes of the same origin policy. Each domain has its own cookies and they can't talk to each other using frames. You should use zoobar.org in your project.

Resources

Where can I find more information about JavaScript?

You can find a lot of references on Google. There's a decent one at W3Schools. Pay particular attention the DOM examples.

My JavaScript isn't working, and I don't know why. What can I do?

Two extremely useful tools for debugging in Mozilla Firefox are the JavaScript console and the DOM Inspector. Both can be accessed from the Tools menu. The JavaScript console lets you see which exceptions are being thrown and why. The DOM Inspector lets you peek at the structure of the page and the properties and methods of each node it contains. (If the DOM Inspector isn't installed, make sure it's selected when you install Mozilla Firefox.)

What do I need to know about CSS?

You only need to know enough to make your attacks disappear. You should know what basic syntax like <style>.warning{display:none}</style> means, and you should feel free to use stealthy attributes like style="display: none; visibility: hidden; height: 0; width: 0; position: absolute" in the HTML of your attacks. Beware that frames and images may behave strangely with display: none, so you might want to use visibility: hidden instead.

How can I see cookies and form data that the browser sends?

Try the LiveHTTPHeaders browser extension.

Where can I find more information about PHP?

The definitive resource on PHP is php.net. You can find some introductory tutorials there.

Part 1 Hints

Am I allowed to load scripts or images from other domains?

No, your attacks should not load data from domains other than crypto.stanford.edu and zoobar.org. For example, this file is ok, but this one is not. We are enforcing this policy so that the submission deadline is a hard one.

Are we allowed to include additional files?

Please limit yourself to the files requested. One file per attack, the README file, and the ID file.

Should we submit a tar file?

No, that's not necessary.

Attack A.

How are the graders going to test our URL?

We will put it into the browser's address bar and click the "Go" button.

The example attack doesn't seem to do anything. What's wrong?

You need to be logged in to zoobar.org before the attack will work. When you click the link, you should get a browser alert with the contents of document.cookie.

Why would someone want to steal document.cookie?

The cookie is the user's authentication credential. If you steal someone else's cookie, it is easy to hijack that user's session (although we won't ask you to do so in this project).

How am I supposed to email document.cookie? I didn't know browsers could send email.

You have to convince the browser to send a GET request to the CS155 email script, which will cause an email to be sent by the crypto.stanford.edu server to you and the grader. The grader gets the email automatically, so just put a group member's email address (or a comma-delimited list of addresses) in the "to" field.

How do I convince the browser to send a GET request to an URL of my choosing?

The email script provides some example code. You allocate a JavaScript Image object, and set its src attribute to be the URL you want the browser to retrieve. The browser immediately tries to fetch the content of this image, even though the URL isn't actually pointing at an image and the image hasn't been inserted into the page anywhere. Pretty sneaky.

Should I include the javascript:void part in my code?

If you do, your attack might still work, but it's not necessary if you're already within a <script> tag. Just copy the part starting with (new Image()).src=...

There are two people in our group. What should we put in the netid parameter?

Put in the Leland username of a group member. You can put in both if you want, but it's not necessary. As long as it's clear to the grader that the attack is from your group, you'll be fine.

What's up with this random query parameter?

If you try your attack more than once, the browser might think that it already has the image in its cache, and so it wouldn't send a second GET request. Adding a random number to the end of the URL ensures that the browser will think the new URL is different, and won't use the cache. The email script ignores this parameter, so it's only useful for bypassing the cache.

Why are the characters reflected back different from the ones in the URL?

Your query parameter is URL decoded by the server before being reflected back at the user. You'll need to made 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.

Are there any restrictions on the length of my solution URL?

No. Internet Explorer has a limit of 2083 characters or so for URLs, but the limit is much longer in Firefox, which is what we are using for grading. The grader's solution was 297 characters, and shorter solutions are possible.

Since a sending an email is a side effect of the request, wouldn't it make more sense for the browser's request to be a POST instead of a GET?

Yes, but that would prevent the Image trick from working. Real-world attackers are rarely bothered by such semantic distinctions.

What should the email look like if the attack worked?

The parts that might be different are in red.

From: Apache <apache@theory.stanford.edu>
To: grader@zoobar.org, youremail@stanford.edu
Subject: Message from group 'yourlelandusername'

Payload:

ZoobarLogin=YToyOntpOjA7czo4OiJhbnRpZ3JhdiI7aToxO3M6MzI6
ImZlOGIzMTM3YjgyNTFlMDQ2YTIzMzRkNTgxOWM2YWZiIjt9=

I'm afraid of spamming the grader's email account. Should I be careful not to test the attack until I'm ready?

Don't worry, we will be ignoring emails sent to grader@zoobar.org until we start actually grading the first part of the assignment.

My attack is working. What should I do to make it invisible to the user?

The text box should its usual size and in the normal place. No warning text or characters that are normally part of the page should be visible. From the point of view of the visitor, it should appear as if they just went to users.php and didn't put in a username yet (with the possible exception of the address bar, which can be whatever you want). It's ok if the page briefly looks weird before correcting itself. Don't worry about the fact that the header at the top of the page changes with each page view — that's normal site behavior.

That sounds hard.

There are actually several quick and easy ways to do it, so try to think outside the box on this one. If you can't figure it out, try moving on to the other attacks and come back to this one when you're done.

Attack B.

Is this a cross site scripting attack?

No, this is a "cross site request forgery" attack. You are exploiting the fact that zoobar.org uses only a cookie to authenticate requests, even ones with side effects.

Can I use the vulnerability in user.php from Attack A?

Since this not a cross site scripting attack, you do not need to use the vulnerability in user.php. All you have to do convince the user's browser to post malicious form data to transfer.php.

How do I convince the browser to send a malicious POST request to transfer.php?

Put together a form in your HTML document, with http://zoobar.org/transfer.php as the action attribute.

How can I get the form to be submitted with no user interaction?

You can call the "Send" button's click method. Or, you can use JavaScript to call the form's submit method. Keep in mind that the site is looking for a parameter named "submission" in the form data, so if it's not there, the transfer won't happen.

What <input> fields should the form contain?

Use the browser's view source function on transfer.php and you'll get a pretty good idea.

How can I submit a form to zoobar.org without causing the browser's address bar to change to zoobar.org?

Create a hidden <iframe> and make sure the form's target attribute matches the frame's name attribute.

Uh oh, iframes. Will the grader have third-party cookie blocking enabled?

No, third party cookie blocking will not be enabled. It's probably off by default on your browser, but if your attack isn't working because the login cookie isn't sent, you might want to check to make sure. Tools > Options > Privacy > Cookies > Uncheck "for the originating site only"

How do I make the iframe hidden?

There are lots of ways to do it, but the easiest is probably <iframe style="visibility: hidden" ...>.

How do I redirect the browser to the CS155 home page?

Change the document.location property. Note that it is okay (and required, in fact) for the browser's address bar to change to http://crypto.stanford.edu/cs155/ once your attack is complete.

How do ensure that the redirect doesn't happen until after the form data has been posted?

You can trigger the redirect from the frame's onload handler. Depending on how your code is written, this onload handler may get called twice — once when the page initially loads and once when the form is submitted. If this is the case, you'll have to make sure that you change document.location on the second time only.

Attack C.

What can we assume the grader will do when logging in?

The grader will type a username, then click the password field, type a password, then move the mouse over the login button and click it. The grader will then wait for the login to complete.

Why is the site using JavaScript to focus the username field?

It's a convenience for the visitor, so they don't have to select the username field manually when they first come to the page. You may it useful as well.

How do I get the browser to call my injected code?

Because your code is sanitized with htmlspecialchars, you won't be able to inject a simple <script> tag like you did in Attack A. Trick the browser into running your code another way.

I think I figured it out, but when I call alert to test my attack, nothing happens.

It turns out that calling alert would lead to an infinite loop of dialog boxes, so Firefox is trying to be helpful by preventing it. Try using something like document.loginform.login_username.value=42 to test whether your attack is working.

How am I supposed to invoke the email script from my script without any single or double quotes?

Try using String.fromCharCode(), which doesn't require any quotation marks to use. You may also find eval to be useful.

I have to write my entire attack in Unicode values? How annoying.

It's easier if you write it as a string in your attack page and then use String.charCodeAt() to pull out the Unicode values.

What do I need to do to make my attack invisible to the user?

You'll have to get a handle on the relevant DOM nodes and make the extraneous text disappear, either by deleting the text or setting the style.display property to "none".

How can I get a handle on the warning message? It doesn't have an id attribute.

It does have other distinguishing characteristics. You may find getElementsByTagName useful. Depending on how your attack works, you may not see a warning message anyway.

I'm sending the email when the form is submitted, but it isn't working. What's wrong?

There's a race condition here where the form may be getting submitted before the email image is downloaded. Once the form submit starts, the thread that's downloading the image is killed. So, to ensure that your attack always works, you should delay the form submission a little bit. You can use addEventListener with an event handler such as function(evt) { evt.preventDefault(); ... }. In this way, you can prevent the form submission until you're ready to trigger it yourself.

Ok, I prevented the submission. How long should I wait?

If you're lazy, you can use setTimeout with a reasonable number of milliseconds. But the precise way of doing it is to create an iframe element using document.createElement, set its source to the email script, use addEventListener to handle its "load" event, and add it to the current page's body.

What should I do after the email is sent?

You can trigger the submission manually using the login button's click() method. Use removeEventListener() to avoid infinite loops.

Is it okay if the attack doesn't work when the HTML file is clicked on the desktop, but it does work when the URL of the HTML file is put into the browser address bar directly?

That is fine. We will test your attack by putting in the URL of your HTML file in the browser's address bar.

What should the email look like if the attack worked?

The parts that might be different are in red.

From: Apache <apache@theory.stanford.edu>
To: grader@zoobar.org, youremail@stanford.edu
Subject: Message from group 'yourlelandusername'

Payload:

grader,topsecret

Attack D.

How does the site sanitize profiles?

It uses strip_tags() to restrict the tags that can be used, and it uses a regular expression to replace certain dangerous words like "onmouseover" with the word "disallowed." Note that strip_tags() will remove all tags that are more than 1024 characters. If your solution occurs inside a tag, you will have to make sure it fits inside this limit, or it won't render to the user.

What tags does zoobar.org allow in profiles?

<a> <br> <b> <h1> <h2> <h3> <h4> <i> <img> <li> <ol> <p> <strong> <table> <tr> <td> <th> <u> <ul> <em> <span>

What strings does zoobar.org not allow in profiles?

javascript: eval onclick ondblclick onmousedown onmouseup onmouseover onmousemove onmouseout onkeypress onkeydown onkeyup

How am I supposed to get script to run when my profile is viewed?

One approach is to get the site to eval your attack, instead of the data it thinks is trusted.

How do I transfer the zoobar?

Create an <iframe> pointing to transfer.php, set the appropriate form fields inside it, and post the form. Alternatively, you can create a form on the current page with transfer.php as its target, and then post it with the target pointing at an <iframe>. Either way, you'll probably want to use an <iframe>.

How do I create an <iframe>?

You can use the DOM methods document.createElement and document.body.appendChild.

How do I get a handle on form fields inside the <iframe>?

It differs by browser, and only works when the frame's domain matches the parent page (that's the Same Origin Policy). Here's the Firefox way of doing it: iframe.contentDocument.forms[0].zoobars.value = 1;

How do I replace the profile?

Use the same technique you just used on transfer.php, but point at index.php instead.

Is there an easy way to get a copy of the current profile?

You can use document.getElementById('profile').innerHTML, but it may mangle quotes in your profile, so be sure to check that the replicated profile is still functional. Also, note that only display:inline tags can be nested inside a <p>.

My profile doesn't propagate if the user doesn't have any zoobars. Is that a problem?

No, that's a fringe case, you don't have to worry about it.

Part 2 Hints

How hard is this part?

It's pretty easy if you know PHP. The hardest part is just reading through the website source code to find the weak points. You'll probably spend as much time writing your README file as you will actually coding.

Can I use the nifty JavaScript techniques from the first part of the assignment?

You're trying to secure the site, not add functionality. The number of instances of eval should go down, not up.

Do I need to look at the files in the includes/ directory?

You should skim these files to get a sense for how the site works, but you're not allowed to change them, so don't spend too much time on it.

How can I get the value of the user's cookie in PHP?

Try $_COOKIE[$user->cookieName]. The global variable $user is initialized in common.php, and you can find out more about the User class in auth.php.

What should I do to users.php to stop Attack A?

Make sure the username is echoed back safely.

What should I do to stop cross-site request forgeries in transfer.php and index.php (preventing Attack B)?

This issue was covered in the lecture on secure web site design, and in section. You need to rely on the Same Origin policy to protect a piece of information that the attacker doesn't know. The exact choice of what information to use is up to you, but it should not be easy to guess for an attacker who does not have access to the user's account. Use that information to validate the posted form data. It should only take a couple lines of code in each file to fix.

Is checking the "HTTP Referer" a valid method of stopping cross-site request forgeries?

No. Users may have browsers configured not to send "Referer" information (in fact, "Referer" is never sent for links on SSL pages). Also many anonymizing proxies strip "Referer" information.

What should I do to login.php to stop Attack C?

It's a very minor change.

What should I do to users.php to stop Attack D?

You probably want to strengthen the profile sanitizing code and/or replace the (unnecessary) JavaScript code in users.php with something simple and straightforward. Whatever you decide on, make sure you convince yourself that it's secure!

What other threats should I be worried about?

You should be concerned with cross-site scripting attacks that can be used to modify a legitimate user's account in some way (changing the profile, transferring zoobars), or steal the user's authentication information, without that user's knowledge or consent.

How many more of these vulnerabilities are there for me to find?

More than zero.

What user behavior can I expect?

The attacker may entice the user to view a malicious page, either on zoobar.org or elsewhere, but the user will only provide their username and password if the address bar starts with http://zoobar.org/ and the login form looks convincing.

Is it a problem if an attacker's site I'm viewing is able to log me out of zoobar.org against my will?

That's an annoyance, but by itself it's not a security problem, so you don't have to defend against it.

Is it a problem if an attacker can log me in as another user the attacker knows the password for?

Not unless this can be used to impact the security of the user's own account.

How can I find input validation vulnerabilities and fix them?

Look for other places that database data or form data are reflected back at the user. Determine whether magic_quotes_gpc is providing enough protection or whether some other sanitization function like htmlspecialchars, strip_tags, or addslashes is required.

What user input can I disallow/sanitize?

You won't be penalized for over-sanitizing, as long as the site still works on alphanumeric inputs. Please use the README file to note any restrictions you are imposing on users.

Should we worry about users tampering with their own cookies?

No, that's not really a cross-site scripting attack. You can't change auth.php anyway.

Should we worry about malicious data that's already in the database?

Your database will be empty when we start the attacks. Anything that we put in it during the attacks (e.g. profiles) will be using your web interface. So either sanitize it on the way in, or on the way out.

Can I make additional assumptions that legitimate users will not do stupid things?

If you want to make additional assumptions, that most likely fine, but please check first with cs155ta@cs.stanford.edu and note your assumptions in the README file.

I think I've found an attack that isn't a cross-site scripting attack. Should I fix it?

Don't spend too much time hardening the site against other attacks, since they won't be part of the grading. However, if it's an interesting attack, you might want to let us know about it or mention it in your README file.