Download SQL Injection: Learning and Protection and more Assignments Electrical and Electronics Engineering in PDF only on Docsity!
ECE4112 Internetwork Security
Web Security
Group Number: ____________ Member Names: _______________________ _______________________ Date Assigned: March 14, 2006 Due Date: March 28, 2006 Last Edited on: April 2, 2006 Please read the entire lab and any extra materials carefully before starting. Be sure to start early enough so that you will have time to complete the lab. Answer ALL questions on the Answer Sheet and be sure you turn in ALL materials listed in the Turn-in Checklist on or before the date due.
Goal: This lab will introduce you to several security issues involving web server
software and web applications.
Summary: In this lab you will be learning about several techniques to attack web
applications as well as how to defend against them. First you will learn about “Cross Site Scripting” and use your knowledge to experiment with a cross site scripting exploit. Then, you will learn about SQL injection and use your knowledge to break into a database driven website and then explain how to protect against such attacks. Then we will tie them all together into a practical exercise.
Requirements:
Red Hat WS 4
SPI Dynamics VMware machine
Section 0: Setup
I. Setting up Apache
Apache should already be installed on your Red Hat WS 4.0 Machine. If it is not, please follow the directions given in Lab 2. Make sure you have a directory called apache somewhere on your machine. Possible locations for this folder are /home/apache2, /usr/local/apache2 or /var/local/apache2. In order to use php, we must modify our server’s configuration file. This file called httpd.conf is located under the apache2 directory (/conf/httpd.conf). The following lines must be added. The best way to add these lines is to search for them in the config file and place them below the commented examples. LoadModule php4_module modules/libphp4.so
DirectoryIndex index.html index.html.var index.php (this replaces existing line) AddType application /x-httpd-php .php For reference, an httpd.conf file is placed on nas4112/Lab9/Examples
II. Setting up PHP
Now that we have our apache server configured, we need to make sure we can interpret a php file located in .../apache2/htdocs. More than likely, PHP and MySQL were not installed during the initial installation of Red Hat WS4. Therefore, you will need to obtain the Red Hat installation cds from a TA. To install, go to: Applications -> System Setting -> Add/Remove Applications Under “Servers” find MySQL Database Open “details” Select: o PHP-MySQL o MYSQL Server o MYODBC o MYSQLDevel First, locate php.ini (use the locate command; you may have to updatedb before you can). More than likely php.ini is located in /etc/. Open php.ini and set the document root to the path of your htdocs directory. For example, if apache2 is located in /usr/local, then find the line in php.ini starting with doc_root and type the following: php-mysql php-odbc doc_root = “/usr/local/apache2/htdocs/” Remember, depending on the location of the apache2 directory, the above line may be different. Once you have completed this task, test out php by creating a sample file in apache2/htdocs called test.php ;
Now, restart apache by typing #/apache2/bin/apachectl restart. If you receive an error about libphp4.so module not found, locate the libphp4.so file and copy to /apache2/modules (probably located in /usr/lib/httpd/modules/) Open up a web browser, and type http://localhost/test.php. If you see a page with a lot of information formatted in a nice table, you have succeeded.
mysql> INSERT INTO messages VALUES (4, '42', 'Meaning of life the universe and everything.'); mysql> INSERT INTO messages VALUES (5, 'Hello', 'Hey everyone!'); mysql> INSERT INTO messages VALUES (6, 'We need more messages', 'Here is yet another message!'); mysql> INSERT INTO messages VALUES (7, 'Yo dude', 'Jeff should type more of these.'); mysql> INSERT INTO messages VALUES (8, 'Lalala', 'Typing messages for people.'); mysql> INSERT INTO messages VALUES (9, 'Yet another message', 'Here is a hint. Post a message.'); To create the users table: mysql> CREATE TABLE users ( user_id int(11) NOT NULL auto_increment, first_name varchar(50) NOT NULL default '', last_name varchar(50) NOT NULL default '', address varchar(50) NOT NULL default '', city varchar(50) NOT NULL default '', state char(2) NOT NULL default '', zip varchar(5) NOT NULL default '', phone varchar(10) NOT NULL default '', email varchar(50) NOT NULL default '', password varchar(8) NOT NULL default 'password', PRIMARY KEY (user_id) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=5 ; mysql> INSERT INTO users VALUES (1, 'Jeff', 'Jo', '1008 State Street', 'Atlanta', 'GA', '30318', '4041234567', '[email protected]', 'password'); INSERT INTO users VALUES (2, 'Tim', 'Jackson', '342 Hempill Avenue', 'Atlanta', 'GA', '30318', '7704325543', '[email protected]', 'password'); INSERT INTO users VALUES (3, 'Unsuspecting', 'User', '10 Hackme Place', 'San Diego', 'CA', '45443', '3153332222', '[email protected]', 'password'); INSERT INTO users VALUES (4, 'Henry', 'Owen', '10 Professors Place', 'New York', 'NY', '07321', '2124432345', '[email protected]', 'goodbye'); To create the login database. mysql> create database my_database; mysql> use my_database; mysql> CREATE TABLE users ( id int(10) NOT NULL auto_increment, username varchar(40), password varchar(50), regdate varchar(20), email varchar(100), website varchar(150), location varchar(150),
show_email int(2) DEFAULT '0', last_login varchar(20), PRIMARY KEY(id)); After executing these commands, you should have two databases: ece4112 and my_database. ece4112 has three tables: cookies, messages, and users. my_database has one table: users. Refer to Appendix C for more information about mysql statements. Hopefully, everything has gone smoothly. Installing these three components are often quite tricky. We have just done the basic configurations; however, all three can be customized for various uses.
Section 1: Cross-Site Scripting
Before you begin, let’s grab the source code for all the PHP files you will be looking at for this lab. Copy the file \57.35.6.10\secure_class\Lab 9 \ece4112-source.tar.gz to a location on your local machine. Unzip the files using “tar – xvzf” to extract them to /apache2/htdocs. You will refer to these files later – they are also available in Appendix D. Also, make sure your cookies are deleted before beginning this lab. On your WS4 machine, open up the Firefox web browser. Go to Edit -> Preferences -> Privacy And click the “Clear” button next to “Cookies” Background Cross Site Scripting (CSS or XSS) refers to a vulnerability in web applications where an attacker can “inject” code (usually Javascript) into a page in a manner such that the web page subsequently executes the code. Since its discovery, the acronym for Cross Site Scripting, CSS, has been replaced with XSS because of the obvious confusion with Cascading Style Sheets. XSS vulnerabilities appear in dynamic web applications that do not properly validate and escape user input. The classic example is a search engine application that prints back the original query to the user when listing the query’s results.
Type in a query in the text input box and click the “Google Search” button. You’ll be taken to a page that lists mock results, but notice near the top of the page that the query you entered on the previous page is shown again on the page. Press back and type the following query into the search box:
Click the “Google Search” button. Notice that the search results now has a text box with the default text set to “I Love ECE4112”. Now that we know we can type in any HTML into the search box and have it executed by the search results page, let’s see what we can do with Javascript. Hit the back button and type in the following query:
Click the “Google Search” button. Q1.1.1 What happened when you are taken to the search results page? Screenshot 1: Take a screen shot of the search results page showing the effects of the injected script that you typed into the query box Although this example is not very malicious or useful to an attacker, it’s a prime example of how XSS vulnerabilities arise in web applications. Click OK on the dialog box if you have not already done so. URL variables are a way to pass data between subsequent page requests. This data is passed via the URL line and takes the format: http://?=&=… To summarize, the URL variables appear after the web page’s address followed by a “?”. Then the variable name and variable value pairs are separated by a “&”. Q1.1.2 Looking at the URL line at the top of the browser, what is value of the URL variable “searchQuery”? Right click in the browser window and select “View Page Source”. A copy of the source has been included in Appendix D. Lines 9 and 10 are what interest us: 9: Your Search Query Was: 10: For those who are not familiar with the PHP scripting language, all PHP code must be enclosed within tags. The “print” command simply writes its argument to the
output stream. The $_GET[] array is an array of URL variables that were passed in the URL. A partial PHP reference has been included at the end of this lab. Q1.1. 3 What are these two lines of code doing in the context of the application? One way to ensure that these web pages are not vulnerable to this type of attack, web developers should ensure that any user input that is redisplayed in the browser is properly formatted or quoted to display the actually value of the user input as opposed to executing any code that may be present. Further discussion about how to combat XSS vulnerabilities is included at the end of this section. Q1.1.4 Take a look at Appendix B. Which PHP function may be useful for properly handling user input? Q1.1.5 Rewrite line 10 of the code above to reflect this change. Now that you have seen a simple example of a reflected XSS attack, let’s move on to something a bit more malicious. Section 1.2 – Cookie Stealing and XSS The HTTP protocol was designed to be a “stateless” protocol meaning subsequent requests that are sent to a web server know nothing about each other. As web applications became more complex a need to maintain certain state information across client requests became necessary. One solution to this has been the adoption of web browser cookies. Cookies are small text files (less than 4KB in size) that web applications create on a client machine to maintain state. The format of a cookie is outlined in RFC2965. (http://www.ietf.org/rfc/rfc2965.txt) The attributes that we are interested in for the purposes of this lab are: NAME Specifies the name of the cookie and the VALUE Specifies the data value associated with this cookie MAX-AGE Specifies when the cookie should expire. An expired cookie should be deleted DOMAIN Specifies the domain for which this cookie is valid. PATH Specifies the path on the web server where this cookie applies.
Take a look at the code after the else statement. Q1.2.3 What are the two lines that start with “document.cookie = “ doing? List the following attributes of the two cookies, NAME, MAX-AGE, PATH. Refer to the Javascript reference located in Appendix A. Enter your group number (eg. Group 36) for the name field Make up a super secret password that you think would never be guessed by anyone in a million years. Click the “Login” button. This will bring you to a welcome screen that greets you with a welcome message that contains the name you entered on the previous page. Q1.2.4 Look at the source of this page (/ece4112/cookie/welcome.php) in Appendix D and describe a potential XSS vulnerability that exists on this page. (Hint: It’s near the welcome message) Now to ensure that the cookie has been saved properly let’s run some tests. Test 1: Make sure that going to the site does not require you to log in again. Navigate to http:///ece4112/cookie/welcome.php. Q1.2.5 What happens this time when you go directly to the page? Test 2: Let’s ensure that the PATH attribute of the cookie was set properly. As you answered in a previous question, the PATH attribute of the cookie has been set to the path that the web page is located in. That means another page that is located in a different path on the web server cannot access the contents of the cookie. We demonstrate this with a simple web page that prints out the value of the cookie. Use your web browser to navigate to http:///ece4112/cookie/testcookie.php. Take note of the path that this page is located in. Q1.2.6 What do you see when you navigate to this page? Now, user your web browser to navigate to http:///ece4112/badcookie/testcookie.php. Notice that the path of this page is different. Q1.2.7 What is different when you navigate to this page? Why is this so?
Now that we have demonstrated that the cookie has been written and the path attribute set correctly, let’s demonstrate the attack. The scenario for this attack is an attacker knows that you have a user name and password to this site and wishes to exploit the fact there exists an XSS vulnerability on the site. He sends you a malicious e-mail which will carry out his attack. We simulate this email in the form of a web page. Since most email clients today support HTML code in the body of email messages, this is a plausible scenario. Use your browser to navigate to http:///ece4112/badcookie/bademail.php. You will see that this email simply tells you to log into the site to update your financial information. Set aside your best moral judgment for the time being and click the “Login to Website” link. Q1.2.8 What happens when you click the link? Does it seem as though anything malicious has occurred? Let’s take a look at what’s going on behind the scenes. Navigate back to http:///ece4112/badcookie/bademail.php. Right click in the browser window and select “View Page Source”. A copy of the source code is also available in Appendix D. The important lines that should be noted are the lines that contain the tag that links to the website. Q1.2.9 What do you think the tag in the malicious tag is doing. Use your browser to navigate to http:///ece4112/badcookie/mycookies.php. This page simply prints out all cookies that have been collected by the malicious attacker. Q1.2.10 Do you see your group name and super secret password? Q1.2.11 Review the source code for harvestcookies.php in Appendix D. What is this program doing? Q1.2.12 When the link in the email was clicked, why did it seem as though no malicious activity took place? An attacker could have disguised their mischief even further by escaping the malicious tag with its hexadecimal equivalent. For example: “ Q1.3.4 Post a message that, when clicked, will pop up an alert window with a message. What is the text you entered in the message body field to achieve this? Screenshot 2: Click on the message that you have just created and take a screenshot of the exploit in action (the browser window with the alert window). How to combat XSS There are several ways to combat the XSS vulnerabilities presented in this lab. One definitive way to combat Javascript attacks is for users to disable Javascript on their web browsers. This, however, is not a feasible solution as many websites today require that Javascript be enabled. Because of the inherent vulnerabilities present in Javascript, many web application developers today are moving towards writing code that does not require the use of Javascript. The other, more viable alternative is for web developers to be informed of these types of attacks and write code that is not vulnerable. Developers should validate all user input. For example, if an input field should not contain a class of special characters (such as an email address, the input should be rejected by the application. Almost all of the reputable programming languages that are available to web developers include special functions that “sanitize” any dynamic text that is displayed to users. What this does is escape any special characters into their HTML equivalents, so that they cannot be injected into the page. This method, however, is limiting to web applications that allow users to post HTML formatted messages. A more difficult alternative is for developers to write code that allows user-supplied HTML in the output of the web page, but checks the data and prevents any blacklisted code from being displayed.
Section 2: SQL Injection on Linux Apache Web Server
Background SQL injection is an attack vector against sites which utilize SQL databases to store and retrieve data. The goal is to modify variables being sent by the webpage to the database and so cause the return value to be something other than what the page creater intended. The primary vector of SQL injection is to take advantage of the fact that SQL statements can be chained together using the ; and ' characters. It is therefore possible to modify the SQL statement SELECT * FROM atable WHERE column=1 to SELECT * FROM atable WHERE column='(SELECT COUNT(*) FROM atable)' and that will cause the statement to return the last row. This is useful as it will indicate how many rows there are in the table. Other subqueries may yield equally useful information. The best defense against SQL injection is input validation. All input from the client should be validated to ensure its proper type. If a number is expected, strings should not
be accepted. Strings should not be allowed to contain ''','@', or ';' characters. These special characters can be escaped and restored upon retrieval. Section 2.1 – Introductory Exercises There are several ways to launch a SQL Injection attack. The simplest is by modifying arguments in the URL; for instance, changing the http://www.hackme.com/index.php? msg_id=23 to msg_id=24. This is a trivial change, but it is useful to see what happens. Use a web browser to go to http:///ece4112/messageboard/messages. You will need to create a login before you are allowed to view messages. (See earlier part of lab for how to do this.) View the messages and click on a single message. You will note the value of the msg_id in the URL. Modify it and watch what happens. If you select a message that exists, you will get that message, if not you will get an error message. On many systems, particularly those powered by Microsoft's ASP pages, the error messages that come back can be very useful. This is a useful thing to note. Set the msg_id to 1ee and load the page. Q2.1.1 What message do you get back when you set the msg_id value to 1ee7? Looking at view_messages.php in appendix D, you will see that the site uses a query: SELECT * FROM messages WHERE msg_id= That number comes from the msg_id= field in the URL. By changing it, we are able to insert whatever we want, including other queries. This is the most common vulnerability. One way this can be useful is to get information about a database. In this case, we want to know how many users are in the database. Change the URL to be http:/// ece4112/messageboard/view_messages.php?msg_id=(SELECT COUNT() FROM users) This will cause msg_id to be the return of the subquery (SELECT COUNT() FROM users). COUNT() returns the number of items in a list and * is a wild character meaning all. So, we are going to count the number of rows in the users table. The SELECT is necessary to make a proper query and return the output of COUNT(). So, if there were 100 users in the database, we should get back message 100. Note the "Message ID:" entry on the page. This will tell you which message was actually returned by the query, since the msg_id variable will still look like your subquery. Q2.1.2 Which message do you get back when running http:///ece4112/ messageboard/view_messages.php?msg_id=(SELECT COUNT() FROM users)? Section 2.2 – Blind SQL Injection*
We know that the Message ID field will tell us whether the output from our subquery was a 1 or a 0. Using this, you can do a search by changing the 'n' to whatever string you want to guess. Once you have found the first character, change the argument to LEFT(password,2) and start using two character strings, say 'no' if n was the first character. Remember to change only the last character. Q2.2.5. What is the user_id/password combination you stole? Q2.2.6. How might a web developer prevent this type of data theft? Section 2. 3 – Faulty Login Page Now that we have seen sql injection directly into the url, it is time to see how a faulty login can provide us the same results. In this exercise, we will be looking at two login pages: one that is not secure and one that has been hardened. You will be comparing the difference between the two in the next section. But for now, we will just see how a fault login can be extremely dangerous. From NAS, get the file php_login.tar.gz. Place the un-tarred folder in /apache2/htdocs. In a web browser, go to http:///php_login/login_corrupt.php. Try a random username and password and observe what happens. A statement like the one below should be displayed: SELECT username FROM users WHERE username = ‘group1’ and password = ‘group1’ This print out is not usually part of the error message; rather it was printed so you could see the kind of sql statement generated to check the username and password. Go back to the login page and now type in the username field: ’ – and junk for your password. Q2.3.1 What happened? Explain why this sql injection worked. (Hint: what is -- in a sql statement?) Q2.3.2 List at least three other similar sql injection code snippets that could be used to exploit this login? Screenshot 3 : Take a screen shot of a successful login. Section 2. 4 – Securing the Login Page
Now that we have seen what a corrupt login looks like, we can investigate how to secure the login page. In a web browser, go to http:///php_login/login.php. Play around with the login page. To register a username, go to http:///php_login/register.php Try sql injection statements in login.php. What happens? Now open up login.php. Q2.4.1 How are the passwords stored in the database? For verification, go to the database in mysql and view the contents of table users by typing select * from users. Q2.4.2 How is the username and password verification different in login.php versus login_corrupt.php? Q2.4.3 What does the get_magic_quotes_gpc() function do? Q2.4.4 Explain the general strategy in preventing sql injection statements.
Section 3: Practical Web Exercise on Windows Server
Copy the image called Exploit-IBuySPI-VMWare.zip from the NAS server to your root directory. Unzip the file using the unzip command. Follow normal procedures to create the virtual machine. When creating the virtual machine, you may be prompted about upgrading. If so, click on the upgrade button.
Starting the Image
The username is “administrator” and the password is “pass.” This machine will run IIS, iPlanet, MSDE (sql server), and DNS. Although a Windows update icon displays the message “Click here to update,” do not run Windows update or portions of this website may stop working. To access the website, enter http://172.16.10.17/ into the browser’s address bar. You will be forwarded to the portal located at http://172.16.10.17/StoreCSVS/. The first time you access this portal (after booting up your computer) will be very slow. This is normal and can’t be avoided. Subsequent accesses will occur at normal speed.
Sometimes when you browse a web site, you see a list of files instead of a rendered HTML page. This occurs when the website developer neglects to include an index page in the current directory, potentially exposing important files. Go to the main page by clicking this icon in the left column. Notice the SPIDynamics logo at the very top of the main page (Default.aspx). If you hover your mouse over the logo, you will see that it links to “/admin/show.asp.” If you delete the “show.asp” portion, you will get a directory listing. If you click on database.mdb or WS_FTP.LOG, you will get all kinds of useful information that the site owner probably doesn’t want you to have. An easy fix to prevent directory listings is to put in a default.asp, index.shtml, or index.html file (others may exist, depending on server’s configuration). Section 3 .3 – Predictable File Location As the title implies, these are files that we think are probably going to exist. One of the most common files a website or piece of software will have is readme.txt. Paste the following URL into your browser’s address box and click Go : http://172.16.10.17/readme.txt You will notice that this file not only exists, but also contains a note by the administrator. We will talk about the content of this note a little more below. Section 3.4 – OS Commanding In our “Predictable File Location” vulnerability, we referenced a file named readme.txt by guessing it. It contains a note from the system administrator that appears to be directed to other website developers. It looks like the Default.aspx application has a hidden administrative function called AdminMode that allows you to execute commands remotely. If you try one of the examples in this note, you will find you can execute Windows commands! Section 3.5 – Filename Manipulation Filename Manipulation involves modifying the filename in an attempt to find backup copies of a particular file. For example, a file named index.shtml may have a backup copy named index.shtml.old or index.shtml.bak in the same directory. Let’s start by guessing a few filenames. We know the file http://172.16.10.17/StoreCSVS/web.config contains important information about the portal, and may contain login information for the database. By default, ASP.NET denies access to this file for security reasons (which is a good thing). What if someone created a backup copy? Let’s start by entering in common backup filenames. If you search for web.config.txt or web.config.old, you get nothing. If you enter web.config.bak, you will get a copy of the web.config file. This copy is more then likely just a backup, and may not always contain the same information. Either way, this information can be extremely valuable to an attacker.
Section 3.6 – SQL Injection On the lower left corner of the website’s home page, click Recover your account password. You will see the Full Name and Email fields. If you type a single quote (apostrophe) in the Full Name field and enter a random e-mail address, and then click Submit , the program will return “Unclosed quotation mark before the character string ‘‘‘.” This by itself will not give you any data. If you would like to extract information from the database, type the following in the Full Name field and then click Submit. ' UNION SELECT name FROM sysobjects WHERE name != ' d This command asks the SQL server for a list of table names that store data. Now you should see the word “Categories” appear on your screen. This is the name of a table in our database. Next, try sending: ' UNION SELECT name FROM sysobjects WHERE name > 'Categories You will now see the word “CustomerAdd” returned. At this point, you are enumerating through the database. Next, send: ' UNION SELECT name FROM sysobjects WHERE name > 'CustomerAdd and you will go to the next entry. Section 3.7 – Information Leakage Information leakage is when an attacker can obtain “leaked information.” This can include everything from a machine name to a directory path. Click Munitions in the left column to access the Munitions page, then click Multi-Purpose Rubber Band. The URL displayed in the address bar is: http://172.16.10.17/storecsvs/()/ProductDetails.aspx? productID=363. If you append a nonnumeric character after “363” and click Go , the webserver will return an error message revealing the server path, a nonpublic filename (\172.16.10.17\ibuy StoreCSVS\ProductDetails.aspx.cs), and a few developer comments. This information gives the attacker an idea of the .NET libraries you are using, which can help aid additional attacks. Note: The following sections may give you some problems. If you have too much trouble running the rest of section 3., skip to Section 4. Section 3.8 – Insufficient Process Validation and Authorization* Return to the main page and click on the Manage Banners link. If you click on this link, it will warn you that you need to be an administrative user to perform this function. This application checks to see who you are logged in as. If your login name matches an entry in the administrative list, the program forwards you to the admin.aspx page. The problem here is that if you enter “admin.aspx” directly, then you will be able to access
