School of Computer Science and Communication

Department of Theoretical Computer Science

Lab 3Web attacks: XSS, XSRF, SQL injection

Computer Security

DD2395 / HT2012

CONTENTS

Contents

1 Introduction 11.1 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 XSS and XSRF(CSRF) 32.1 Cookie Theft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Cross-Site Request Forgery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Protection against XSS and XSRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 SQL injection 73.1 WraithMail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Cloaknet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 Protection against SQL injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 History 11

I

1 Introduction

The goal of this lab is for you to get familiar with web security. The lab covers four common web applica-tion vulnerabilities: SQL injection, Insecure Direct Object References, Cross-Site Scripting (XSS), and Cross-SiteRequest Forgery (XSRF/CSRF). According to the Open Web Application Security Project (OWASP), these vul-nerabilities are among the top ten critical web application security flaws. This lab will help you find and exploitvulnerabilities in several web applications that run on a test-bed web server.

If you need help, you are welcome to come to the scheduled lab sessions, but since these might be crowded,make sure to book a seat by signing up in advance. However, you can also work remotely, but you will still have toshow your answers and solutions to a lab assistant once you are finished. In order to accomplish this requirementyou will have to sign up for a regular lab session. This lab should be solved in pairs (if you do not have a partnernor find one, let us know as soon as possible).

DeadlineThe deadline for the lab can be found on the course website:http://www.csc.kth.se/utbildning/kth/kurser/DD2395/dasak12/

1.1 Preparation

The lab exercises require a certain level of expertise; therefore, you are strongly advised to go through therelevant sections of the OWASP Webgoat or Google Gruyere projects.You can download some virtual machines from the OWASP Broken Web Applications Project. In the case ofGruyere, you can visit its website without downloading anything.

The first part of the lab covers Cross-Site Scripting (XSS) and Cross-Site Request Forgery (XSRF/CSRF).If you need help with JavaScript, you can find a tutorial here:http://www.w3schools.com/js/default.asp, and a cheat sheet here: http://ha.ckers.org/xss.html.Firefox’s JavaScript Error Console and DOM Inspect are both accessible from the ‘Tools/Web Developer’ menu.The Error Console lets you see which exceptions are being thrown and why they are happening. The Inspect toollets you peek at the structure of the page and the properties and methods of the corresponding DOM tree nodes.Youcan also use the Web Console from the same menu to analyze request headers, including the content of cookiessent along with the requests (clicking on a GET request line opens a popup with detailed information). You mayneed to use Cascading Style Sheets (CSS) to make your attacks invisible to the user. You should know whichbasic syntax you may need (http://www.w3schools.com/css/css syntax.asp) you may need (and its meaning), forinstance, <style>.warning{display:none}</style>If you need to encode certain special characters, such as newlines, take a look at this tutorial:http://scriptasylum.com/tutorials/encode-decode.html

The second part of the lab covers SQL injection. The following SQL tutorial might be useful for refreshingSQL commands and syntax: http://www.w3schools.com/sql/. We also advise you to have a look at the SQLInjection Cheat Sheet http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/. For this part of the lab you willneed an intercepting proxy that will allow you not only to capture the HTTP packets but also modify them beforesending them further. One such tool is the free version of the Burp Proxy.

1.1 PREPARATION

Burp proxy setup:• Download the free version from http://portswigger.net/burp/proxy.html

• 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 configuration:”

2. Set

– HTTP proxy: 127.0.0.1– Port: 8080

3. Tick “Use this proxy for all protocols”

4. Delete the “No Proxy for” line

In the Burb proxy software, go to the tab named proxy, and when the button named intercept is on isenabled (which is in that state by default) all requests to websites you visit in the browser will be interceptedby the proxy software.Once a request has been intercepted, you always have the possibility to change it before actually sendingthem out (by pressing the button forward).

The rest of these instructions comprises some more specific instructions for each specific exercise and a list ofquestions to think about at the end of some subsections. These questions should help you understand what is goingon in more depth.

While you are allowed (and encouraged) to use the resources that you find suitable to help you understand thedifferent kinds of web attacks and web programming specifics, you are also advised to take into account the CSCcode of honor; and you are reminded that by developing your own solution not only you will be able to learn, butalso enjoy the most.

Do not forget that you will have to show your answers to the questions when you present and explain yoursolution to the lab assistants.

2

2 XSS and XSRF

This section will help you understand what cross-site scripting (XSS) and cross-site request forgery (XSRF/C-SRF) are. You will craft a series of attacks against the Zoobar web site that will exploit varying vulnerabilities inthe website’s design. Each attack presents a distinct scenario with unique goals and constraints, although in somecases you may be able to re-use parts of your solution code.

The URL for the Zoobar web site is: http://dasak.csc.kth.se/zoobar/. You can take a look at the Zoobar PHPsource files: http://www.csc.kth.se/utbildning/kth/kurser/DD2395/dasak12/Labs/WebAttacks/zoobarPhpFiles.tar

EvaluationWe will grade your attacks with default settings using the latest official release of the Mozilla Firefoxbrowser 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 ofoperating systems, but there are subtle quirks in the way HTML and JavaScript are handled by differentbrowsers, e. g., some attacks that work in Internet Explorer may not work in Mozilla 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 receivethe corresponding credit for your work.

2.1 Cookie Theft

You will construct an attack that will steal a victim’s cookie for the zoobar site when the victim’s browseropens an URL of your choice. This type of attack is called Reflected Cross-site Scripting attack.You do not need to do anything with the victim’s cookie after stealing it for the purposes of this exercise, althoughin practice an attacker could use the cookie to impersonate the victim and issue requests as if they came from thevictim.

Your goal is to steal the document cookie and email it to yourself using this script:http://www.csc.kth.se/utbildning/kth/kurser/DD2395/dasak12/Labs/WebAttacks/sendmail.php

The grader will already be logged in to the Zoobar site before loading your URL. Except for the browseraddress bar (which can be different), the grader should see a page that looks exactly as it normally does when thegrader 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 (but it is all right if the page looks weird brieflybefore correcting itself).

Guidance with questions:

• What is the meaning of same origin policy? How does the reflected XSS attack bypass this policy?

• A web application vulnerable to reflected XSS will send the received unvalidated input back to the user (e.g., in a search result). How can you test for the reflected XSS based on this behavior? (Hint: sending thestring <script>alert("XSS works");</script> via an input field might not suffice. Look at the source

2.2 CROSS-SITE REQUEST FORGERY

code of the returned page and check how your input script is reflected).

• Which is the vulnerable element of the website?

• How do you use the email script to send data to your email? Provide an example in JavaScript language.

• 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 using a location object. How do you use it to hide the error messages?

Milestone:Report your progress to a lab assistant

2.2 Cross-Site Request Forgery

Now, in this new scenario, you will transfer ten zoobars from the victim’s account to your account. The victim,who is very naive, will load any HTML document (e. g., an HTML e-mail) that you send (social engineering isout of scope of this lab).

You need to create a short HTML document that the victim will open using its web browser. You can assumethat the victim is logged in (authenticated with the zoobar application) before loading your document but it shouldnot notice that a transfer of credits has occurred. Therefore, you should either redirect the victim to the courseweb page http://www.csc.kth.se/utbildning/kth/kurser/DD2395/dasak12/ after the transfer has been completed (fastenough so that the victim might not notice the transfer) or show something else to the victim, so that the victimdoes not become suspicious. In particular the location bar of the browser must not contain “zoobar site” at anypoint of time.

Guidance with questions:

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

4

2.3 PROTECTION AGAINST XSS AND XSRF

• Look at the source code and the HTTP headers during the transfer of zoobars. Your crafted request shouldlook exactly like the original. What information (input) 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 button’s click method(document.getElementById(’mybutton’).click();). Describe some other alternative manner to sub-mit the form with an example.

• You can use also iframes to hide your attack and submit the form in the hidden iframe instead of thecurrent page. Describe at least two methods on 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 flaws in a web application.

5

2.3 PROTECTION 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

6

3 SQL injection

The following exercise will help you understand the SQL injection techniques and systematic vulnerabilitytesting. While the main focus is on the SQL injection, there is also one Insecure Direct Object References vulner-ability that you are supposed to exploit.You will likely need an intercepting proxy for these assignments, read section Preparation for further details.

For this part of the lab exercise, a Hackxor webapp hacking game is being used. The game consist of a set ofsites that you should hack. The first two steps of this hacking game, which include wraithmail (an e-mail service)and cloaknet (an anonymizing proxy service), are used for this exercise.For those of you who might want to try their skills directly, we encourage you to try solving the first two steps(wraithmail and cloaknet) of the game without reading the lab instructions in the following section. However, youwill still have to answer the questions anyways at the discretion of the lab assistant that examines your work.

The game scenario is as follows: you are a hacker who got the task to track down a person who performed anattack on one of the wraithmail accounts; for that, you should login into wraithmail.csc.kth.se:8080 and read theletter with the “trace job” description.Your login credentials are:

User algo

Password smurf

3.1 WraithMail

This section contains the Insecure Direct Object References vulnerability. You are more than encouraged totry any other attack to check whether the site is vulnerable to any of them or not.

Important hints:• Pay attention to the Referer line in the “trace job” letter

• Explore the site, look for a vulnerable add-onNote: 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

Answer the following questions:

• Briefly describe the attempt attack of the hacker that you are tracking (no details required, just the roughidea).

• What username was used for the attack?

• What was the logged IP address?

Milestone:Report your progress to a lab assistant

3.2 CLOAKNET

3.2 Cloaknet

By now, you have got evidence that the attacker used a cloaknet proxy to hide its IP. Now, your task is toperform an SQL injection attack to retrieve the account credentials (login, password, id,...) of all registered usersat cloaknet.You should also be able to confirm that the source of the attack was from GGHB, that the target was wraith-mail:8080/send.jsp, and that the date matches the one you could see in the wraithmail logs.

In order for you to find out who the attacker is, you should start with 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 this task.

Guidance with questions:

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

• A database has many different data types, but all of them can still be classified into a few groups based onhow they are represented in the SQL statements. Name these groups.

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

• How do you think the cloaknet’s SQL queries might look like?

• Check whether the cloaknet web application’s inputs are vulnerable to SQL injection or not. How do you dothat? Give two examples.

• Were you able to cause an SQL error or an HTTP error (500) to be displayed on the webpage? How did youdo 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 filtered (the filter is the same for all)! The filter escapes some characters and removes somewords (e. g., SELECT). Moreover, one of the inputs in cloaknet is treated with many characters as delimiters(even spaces). Why? Name at least four techniques to bypass filters in general (with examples) (Hint: checkthe cheat-sheet and try using predictable names for the attributes of each entity, that is the column names for

8

3.3 PROTECTION AGAINST SQL INJECTION

each table you want to use).

• The UNION operator is used to combine output from several SELECT statements. What requirements shouldthese statements meet in order to be “unioned”? What if the table you want to union does not have as manycolumns as the first? 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 onthe page. Sometimes, though, not everything is shown, and then it is important to find out the number ofcolumns. 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 inthe UNION without explicitly naming them?

• What are the username and the 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.

Questions:

• Describe how parametrized queries help protect against SQL injection. What other protection techniquescan be used on the application’s code level?

9

3.3 PROTECTION AGAINST SQL INJECTION

• What is a stored procedure? Describe how it protects against SQL injection. What other protection tech-niques can be used at the database level?

• What combination of protection techniques would you choose, to mitigate the SQL injection threat?

Milestone:Report your progress to a lab assistant

10

4 History

Version Contribution Author (Affiliation) Contact1.0 First development Oleksandr Bodriagov (CSC/KTH) obo@kth.se

11