School of Computer Science and Communication Department of Theoretical Computer Science

Lab 3 Web attacks: XSS, XSRF, SQL injection

Computer Security DD2395 / HT2011

Introduction

The goal of this lab is for you to get familiar with web security. The lab covers four common web application vulnerabilities: SQL injection, Insecure Direct Object References, Cross-Site Scripting (XSS), and Cross-Site Request Forgery (XSRF/CSRF). According to the Open Web Application Security Project (OWASP) these vulnerabilities are in the top ten. You are supposed to nd and exploit vulnerabilities in several web applications that run on the laboratory web server. You can access the server remotely. If you need help, you can come to the scheduled lab sessions, but since these might be crowded, make sure to get a seat by signing up in advance for the particular lab session you would like to join. Although if you prefer, you can also work remotely but you will still have to show your answers and solutions to a lab assistant when you are nished. For this, you will need to sign up for a regular lab session or a dedicated time slot for showing your work. This lab should be solved in pairs.

Deadline
The deadline for the lab can be found on the course website. Do not wait till the very last minute to do the lab! And... good luck!

1.1

Preparation

The lab exercises require a certain level of expertise, therefore we strongly advise you to go through the relevant sections of the OWASP Webgoat or Google Gruyere projects. You can get both of them by downloading the virtual machine from the the OWASP Broken Web Applications Project. For Gruyere, you can also just go to the Gruyere website without downloading anything. The rst part of the lab covers XSS and XSRF. You can nd a Javascript tutorial here: http://www.w3schools.com/js/default.asp, and a cheat sheet here: http://ha.ckers.org/xss.html. Firefoxs JavaScript console and DOM inspector are both accessible 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 isnt installed, make sure its selected when you install Mozilla Firefox.). You can use the LiveHTTPHeaders browser extension to analyze the content of the cookies and exchanged form data that a browser sends and receives. You may need to use Cascading Style Sheets (CSS) to make your attacks invisible to the user. You should know what basic syntax such as <style>.warningdisplay:none</style> means. If you need to encode certain special characters, such as newlines, take a look at this tutorial. The second part of the lab covers SQL injection. The following SQL tutorial might be quite useful for refreshing SQL commands and syntax: http://www.w3schools.com/sql/. We also advise you to look through this SQL Injection Cheat Sheet. For this part of the lab you will also need an intercepting proxy that will allow you to intercept HTTP packets, modify them, and send further. One example of such tools is the free version of the Burp Proxy used to prepare these instructions and tested on the Ubuntu machines available at the lab rooms (but also tested on the latest available version of Ubuntu).

II

1.1

P REPARATION

Burp proxy setup:

Download the free version, unpack, cd to the folder with burp Run the proxy with: java -jar burp... In Firefox Preferences, go to Advanced Network Settings: 1. tick Manual proxy conguration: 2. HTTP proxy: 127.0.0.1 Port:8080 3. tick Use this proxy for all protocols 4. delete No Proxy for line In the Burb Proxy program, go to the tab named proxy. When the button named intercept is on is activated (which it is by default) all requests to websites you visit in the browser will be intercepted. You then have the possibility to change these requests before actually sending them out (by pressing the button forward). You will nd a list of questions to think about at the end of some subsections. These should help you to understand what is going on in more depth. You will have to show your answers to the lab assistants to pass the lab. You will also show and explain your code to the lab assistants at an agreed upon time. On the course website, you can sign up for time slots to show your work. While you can use resources online to help you understand different kinds of web attacks and web programming particulars, remember the CSC code of honor and that you will learn the most by developing your own solutions.

III

XSS and XSRF

This section will help you understand what cross-site scripting (XSS) and cross-site request forgery (XSRF/CSRF) are. You will craft a series of attacks against the Zoobar web site that will exploit varying vulnerabilities in the websites 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. The URL to the Zoobar web site: http://dasakh11.csc.kth.se/zoobar/. Take a look at the Zoobar PHP source les.

Evaluation
We will grade your attacks with default settings using the latest ofcial 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 it can be run on a great 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. You are advised to test your code on Mozilla Firefox before you show it to ensure that you will receive the corresponding credit for your work.

2.1

Cookie Theft

Construct an attack that will steal a victims cookie for the zoobar site when the victims browser opens an URL of your choosing. This type of attack is called a Reected Cross-site Scripting attack. You do not need to do anything with the victims 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. 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 the site. No changes to the site appearance or extraneous text should be visible. Avoiding the red warning text is an important part of this attack. (Its ok if the page looks weird briey before correcting itself.)

Guidance with questions:

What is a same origin policy? How does the reected xss bypass this policy?

A web application vulnerable to reected XSS will reect (send back) received unvalidated input back to the user (e.g. in search result). How can you test for reected XSS based on this behavior? (Hint: just using <script>alert("XSS works");</script> might not sufce. Look at the source code of the returned

2.2

C ROSS -S ITE R EQUEST F ORGERY

page and check how your script is reected)

Where is the vulnerability?

How do you use the email script to send data to your email? Provide a JavaScript example.

Which HTML DOM Object has a cookie property?

The victim is not supposed to see any error messages. What does the following script do? document.getElementByID(x").style.display = ...; You can also try to use a location object. How can you use it to hide error messages?

Milestone:
Report your progress to a lab assistant

2.2

Cross-Site Request Forgery

The scenario is the following. You should transfer 10 zoobars from the victims account to your account. The victim, who is very naive, will most probably load any HTML document (e.g. HTML e-mail) that you send (social engineering is out of scope of this lab). You need to create a short HTML document that the victim will open using its web browser. The victim also has to be logged in (authenticated with the zoobar application) before loading your document for the attack to succeed, but it should not notice that a transfer of credits has occurred; therefore, you should either redirect the victim to the course web page http://www.csc.kth.se/utbildning/kth/kurser/DD2395/dasakh11/ after the transfer is complete (should be done fast enough so that the victim might not notice the transfer) or show something else to the victim, so that the victim does not become suspicious. The location bar of the browser should not contain zoobar site at any point of time.

Guidance with questions:

Describe the browser behavior and problems with session management that make XSRF possible.

2.3

P ROTECTION AGAINST XSS AND XSRF

Look at the source code and the HTTP headers during the transfer of zoobars. Your crafted request should look exactly like original. What information (inputs) is being sent? What type of request should you craft: GET or POST?

One way to submit the form using javascript is to call the buttons click method (document.getElementById(mybutton).click();). Describe some other way to submit the form (with example).

You can use iframes to hide your attack and submit the form in the hidden iframes instead of the current page. Describe at least two methods how you can hide iframes.

Describe some other technique, besides hidden iframes, to make your attack invisible to the victim.

Milestone:
Report your progress to a lab assistant

2.3

Protection against XSS and XSRF Questions:

Describe how to prevent XSS aws in a web application.

VI

2.3

P ROTECTION AGAINST XSS AND XSRF

What can be done by a user (at the browser level) to protect against XSRF? Name at least two alternatives.

How to prevent XSRF vulnerabilities on the web application level?

Milestone:
Report your progress to a lab assistant

VII

SQL injection

The following section will help you understand SQL injection techniques and systematic vulnerability testing. The main focus is on the SQL injection, though there is also one Insecure Direct Object References vulnerability that you are supposed to exploit. You will need an intercepting proxy for these assignments, read section Preparation for more details. For this part of the lab a Hackxor webapp hacking game is used. The game consist of a set of sites that you should hack. The rst two steps of the game that include wraithmail (an e-mail service) and cloaknet (an anonymizing proxy service) are used in this lab. The following description will provide you with quite elaborate hints on how to solve the game. For those of you who might want to try their skills directly, we encourage you to try solving the rst two steps (wraithmail and cloaknet) of the game without reading the lab instructions in the following section. However, you will have to answer mandatory question with guidance afterwards anyway. The game scenario is the following: You are a hacker that received the task to track down a person who performed an attack on one of the wraithmail accounts. You should login into wraithmail.csc.kth.se:8080 and read the letter with the trace job description. Your login: algo, password: smurf. You should complete the following two tasks and answer the questions that follow.

3.1

WraithMail

This section contains the Insecure Direct Object References vulnerability. You are encouraged to try other attacks and check if the site is vulnerable to any of them.

Important hints:
Pay attention to the Referer line in the trace job letter Explore the site, look for a vulnerable add-on Note: You will need an intercepting proxy to exploit the vulnerability. If your attack succeeds, you will be able to see that the abuse contact is from the cloaknet

Questions:
Describe the attack that the hacker whom you are tracking attempted

What username was used for the attack?

What IP address was logged?

Milestone:
Report your progress to a lab assistant

3.2

C LOAKNET

3.2

Cloaknet

By this time you were supposed to get evidence that the attacker used a cloaknet proxy to hide the IP. Your task is to perform an SQL injection attack and retrieve account information (login, pwd, id) of all registered cloaknets users. You should also conrm that the source of the attack was GGHB, the target wraithmail:8080/send.jsp, and the date matches the one you could see in wraithmail logs. Find out who the attacker is. The Cloaknet website: cloaknet.csc.kth.se:8080 You might need to look at the SQL Injection Cheat Sheet mentioned in section Preparation to complete the task.

Guidance with questions:

Name at least 3 ways (in terms of the HTTP protocol!) that are used by web applications to get input data and that might be susceptible to injection.

Databases have many different data types, but they all can be divided in just a few groups based on how they are represented in SQL statements. Name these groups.

One of the values that goes as input to the SQL query in Cloaknet is Username. Name two other values that might be used as input in SQL queries. (Hint: these 3 values cover all groups from the previous question)

How do you think the cloaknets SQL queries might look like?

Check whether the cloaknet web applications inputs are vulnerable to SQL injection. How do you do that? Give 2 examples.

Were you able to cause an SQL error or an HTTP Status 500 to be displayed on the page? How did you do it? What information did you learn? What kind of database and web server are being used?

Why is it useful to know which database is used?

All inputs are ltered (the lter is the same for all)! The lter escapes some characters and removes some words (ex. SELECT ). Besides, one of the inputs in cloaknet treats many characters as delimiters (even spaces). Why? Name at least 4 techniques of bypassing lters in general(with examples). (Hint: check the cheat-sheet)

IX

3.3

P ROTECTION AGAINST SQL INJECTION

Important hint: in this game all column and table names are very predictable! The UNION operator is used to combine output from several SELECT statements. What requirements should these statements meet in order to be unioned? What if the table you want to union does not have as many columns as the rst? How do you solve this?

You should be able to infer the number of columns used in the query statement from the output you see on the page. Sometimes, though, not everything is shown, and then it is important to nd out the number of columns. How is it done? Provide an example.

You can UNION tables even without listings column names. How can you include all columns of a table in the UNION without explicitly naming them?

What are the username and password of the attacker ?

Milestone:
Report your progress to a lab assistant

3.3

Protection against SQL injection

There are many mitigation techniques for SQL injection. Below is a list of questions about some of them.

Questions:
Describe how parametrized queries help protect against SQL injection. What other protection techniques can be used on the applications code level?

3.3

P ROTECTION AGAINST SQL INJECTION

What is a stored procedure? Describe how it protects against SQL injection. What other protection techniques can be used on the database level?

Do you know any other defenses against SQL injection? What combination of protection techniques, in your opinion, should mitigate the SQL injection threat?

Milestone:
Report your progress to a lab assistant

XI