Download SQL Injection: Understanding and Prevention and more Study Guides, Projects, Research Electrical and Electronics Engineering in PDF only on Docsity!
ECE 4112: Internetwork Security
Web Security, v2.
Group Number: _______________ Member Names: _________________________ _________________________ Date Assigned: Date Due: Last Edited: Edited by: Brett Poche’ & Chris Hood (Group 18) 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 and be sure you turn in ALL materials listed in the Turn-in Checklist ON or BEFORE the Date Due.
Goal: The goal of this lab is to introduce you to the varying security issues related to
hosting a web server and web applications, and then to suggest ways in which to protect yourself, your users, and your data.
Summary: In this lab, we will take a look at varying security issues that relate to
web security, both on the server and the client side. There are five sections and each section starts with some background information, presents the issues, then will conclude with helpful pointers to prevent that section’s information disclosure. The first section deals with the basics for creating, assigning, and accessing cookies in PHP and the potential security risks involved. The next section will take a look at Cross- Site Scripting, the different types that are available, what information they can expose, and how an administrator can help prevent them. Section Three contains examples of SQL Injections and demonstrates their potential. The next section will combine the previous ones into a small, practical example (created by SPI Dynamics) that you may use to see how sites that appear to be secure really are not. Finally, the lab will end with a section depicting how easily information can be obtained from documents that were “censored” and placed online, especially if the censoring is not done well.
Background and Theory: To begin, not all websites are insecure.
There are many out there that are supported by a staff that works around the clock to ensure that their site is as secure as possible. However, there are also many other sites where the administrators are too short-handed or are completely oblivious to their security holes or even think that the attackers will not take the time necessary to hunt down their security holes. This, obviously, is a huge problem.
It is easy to take the security of the software you built and your commercial software for granted. However, one needs to have a good understanding of what is going on in both of these cases in order to secure everything. Lightly glancing over software documentation or programming APIs might make one feel like they are using the software correctly, however they may not be. This is especially important for large scale commercial products that have user manuals posted online. An administrator may not want to take the time to read the entire document to learn how everything works, but if an attacker really wants to get in, then they will take the time to read the documentation themselves and use that information to exploit any default settings they can find. This lab is a general test on assumptions. One may assume that their software is secure, or that the user will only enter valid data, or even that the server has the proper security settings, but items as important as this need to be understood and verified in order to obtain the maximum level of security.
Requirements: You will need the following machines. No special
configuration is required. Red Hat WS 4 SPI Dynamics VMWare machine (Windows 2000) Windows XP VMWare machine
Prelab Questions: None.
Section 0: Setup
Section 0.1 – Setting up Apache
Apache should already be installed on your Red Hat WS 4.0 Machine. If it is not, please follow the instructions provided in Lab 2 to install it. Once it is installed, you should have a directory called apache2 located in either /home/apache2, /usr/local/apache2, or /var/local/apache2. Remember this location because the rest of the lab will refer to it as: [path to apache2]. Next, we need to modify the server’s configuration file to use PHP. The file is called httpd.conf and is located under the apache2 directory ([path to apache2]/conf/httpd.conf). Once you have found it, add the following lines. (Search for them in the config file and place them under the commented examples.) LoadModule php4_module modules/libphp4.so DirectoryIndex index.html index.html.var index.php AddType application /x-httpd-php .php
Section 0.2 – Setting up PHP
The first line starts the MySQL daemon, which you will need to run anytime you start your machine so that you can use the database. The second line adds a user named root, with the password “password” and will only need to be run once. This lab uses three databases, which are setup and described below. One will be used to store captured cookie information, one will be used for a message board, and the third one will be used to store login information. To create each of these databases, we will need to execute the following commands. First get a myslq> prompt by typing #mysql –u root –p Type your password when you are prompted. Now enter the following commands, which you can copy from the commands.sql file provided in the lab folder: mysql > create database ece4112; mysql > use ece4112; To create the cookies table: mysql > CREATE TABLE cookies ( id int(11) NOT NULL auto_increment, username varchar(100) NOT NULL default '', password varchar(100) NOT NULL default '', PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=7 ; mysql > INSERT INTO cookies VALUES (6, 'testertest', 'hilohilo'); To create the message board table: mysql > CREATE TABLE messages ( msg_id int(11) NOT NULL auto_increment, title varchar(50) NOT NULL default '', body text NOT NULL, PRIMARY KEY (msg_id) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=19 ; mysql > INSERT INTO messages VALUES (1, 'Test Message 1', 'This is a test.'); mysql > INSERT INTO messages VALUES (2, 'Test Message 2', 'This is another test.'); mysql > INSERT INTO messages VALUES (3, 'We love 4112', 'What a great message.'); 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'); mysql >INSERT INTO users VALUES (2, 'Tim', 'Jackson', '342 Hempill Avenue', 'Atlanta', 'GA', '30318', '7704325543', '[email protected]', 'password'); mysql >INSERT INTO users VALUES (3, 'Unsuspecting', 'User', ' Hackme Place', 'San Diego', 'CA', '45443', '3153332222', '[email protected]', 'password'); mysql >INSERT INTO users VALUES (4, 'Henry', 'Owen', ' 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,
to know that you can also do it in PHP. Appendix A contains information about how to set and access cookies via JavaScript. In a nutshell, you should have read that there are a couple of options which you may use when setting a cookie and that PHP has a built-in, global variable which will allow you easy access to your cookies. The most important part to notice here is that the secure option, on the PHP website, is described as follows: “Indicates that the cookie should only be transmitted over a secure HTTPS connection. When set to TRUE , the cookie will only be set if a secure connection exists. The default is FALSE ” [13]. Remember this as you go through this section.
Section 1.2 – How secure is it?
Now we will test the “secure” parameter of the setcookie() method to see how well it works. Go view the source code of setcookie.php located in [path to apache2]/htdocs/ece4112/test/ in a text editor (not through the browser). Do NOT go to the page yet. If you did, clear your cookies and close your browser. This is just a demonstration of how the code would create the cookie based off of the user supplied information. Change the $myIP variable to the IP address of your WS machine. For simplicity’s sake, we skipped the step where you would enter your user name and password and jumped right to the cookie setting part. We just want to quickly demonstrate how the cookie is passed along. Q1.2.1 From the source code, what are all the parameters used to set the cookie? Now, open Ethereal on your WS 4 machine and start capturing packets. Open your browser on the Windows XP virtual machine and navigate to: http://[IP WS4]/ece4112/test/setcookie.php Once it has successfully loaded you should see some output on the screen confirming that a cookie was set.. Go stop Ethereal and look for the packets sent over the connection. Right-click on one of the packets and select “Follow TCP-Stream.” Q1.2.2 Can you read the contents of the cookie? Screenshot 1: Take a screenshot or print the TCP-Stream that you captured. Q1.2.3 Did the security option work like we thought it would? How to Protect your Cookies The best method for protecting the information within your cookies, if you are unsure of your server’s security setup, is to encrypt the data within the cookies by sending its hash value (for instance, by using the md5() function). In our examples, the server was not setup to accept secure connections, in which case, according to the documentation, it should not have set the cookie.
One good tool to use to evaluate your webpage is WebSleuth, which may be found at: http://www.geocities.com/dzzie/sleuth/. (Do not be dissuaded by the geocities domain, this is a good program and has been referenced by many security sites.) It provides a graphical interface that allows you to surf your website and see all of the information present in the source code. It does this by separating the source into tabs, dividing the sections into: comments, header, cookies, and more. The cookie’s tab would be most useful for the above exercise since it will display exactly what the cookies contain, so it would be easy to verify if sensitive information is in plain text. It also comes with plugins, including an HTTP/Cookie session ID brute forcer, SQL injection tester, and HTTP brute forcer [14]. It is also important to be aware that programs like this make it easy for attackers to create their own data for form entries and supply that to the webpage. For instance, some applications send an HTTP request (GET or POST) when handling logins, searches, etc. When data is sent via POST, it is not visible in the URL string, so some may assume that it is hidden. However, programs like WebSleuth and Achilles (http://www.mavensecurity.com/achilles) make it very easy for an attacker to see which fields are present in the background and to modify their values before sending it to the server, where it will probably be used without validation. Although this lab does not specifically address GET and POST methods, it is still a risk that an administrator should be aware of.
Section 2: Cross-Site Scripting
Before beginning this section, delete all of the cookies from the browsers you are using on all systems. Do so like the beginning of Section 1. 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. XSS has been categorized into three types: Type 0: DOM-based or local Type 1: Non-persistent or reflected Type 2: Persistent or stored
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 “&”. Q2.1.2 Looking at the URL line at the top of the browser, what is value of the URL variable “searchQuery”? Look at the code for this page by navigating to it on your machine (not through the browser). 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 (in this case, the HTML document). 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. Q2.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 is for web developers to check that any user input that is redisplayed in the browser is properly formatted or quoted to display the actual 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. Q2.1.4 Take a look at Appendix B. Which PHP function may be useful for properly handling user input? Q2.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 2.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 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. The DOMAIN and PATH attributes listed above are of particular importance. They prevent a web server whose domain and path values do not match what is contained in the cookie from accessing the contents of the cookie. For example, if www.google.com writes a cookie on your machine, then www.hotmail.com cannot read this cookie since Hotmail’s domain does not match Google’s. Similarly, if a page in the path www.google.com/search/ writes a cookie and specifies the PATH attribute to be “www.google.com/search”, then another page with a different path (ex. www.google.com/differentpath/) cannot access the cookie. We will revisit this a bit later. Some common examples where cookies may be used are: In an online shopping application to keep track of what products a user has looked at in order to deliver recommendations based on past activity To keep track of what is in a user’s online “shopping cart” To store a session id which tells the web server if the current user is logged in and as a means for authentication To send annoying pop-ups based on a user’s past browsing habits. Another very common use of a cookie can be seen in web applications that “remember” a user’s username and password so that they don’t have to type it in every time they visit the site. Hotmail (www.hotmail.com) is one site that uses cookies for this exact purpose. Q2.2.1 Why are the DOMAIN and PATH attributes important in term of security? (Hint: What kind of data may the cookie potentially contain?)
Test 1: Make sure that going to the site does not require you to log in again. To do this, on your WS4 machine navigate to http://localhost/ece4112/cookie/welcome.php. Q2.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. Again, use your web browser to navigate to http://localhost/ece4112/cookie/testcookie.php. Take note of the path that this page is located in. Q2.2.6 What do you see when you navigate to this page? Now, user your web browser to navigate to http://localhost/ece4112/badcookie/testcookie.php. **Notice that the path of this page is different. ** Q2.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://localhost/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. Q2.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. On your WS4 machine, navigate to [path to apache2]/htdocs/ece4112/badcookie/ and open bademail.php (not in a browser). The important lines that should be noted are the lines that contain the tag that links to the website.
Q2.2.9 What do you think the tag in the malicious tag is doing. Use your browser to navigate to http://localhost/ece4112/badcookie/mycookies.php. This page simply prints out all cookies that have been collected by the malicious attacker. Q2.2.10 Do you see your group name and super secret password? Q2.2.11 Review the source code for this file within the file system (not through the browser). What is this program doing? Q2.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: NOTE: “ 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 3: SQL Injection on Linux Apache
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. Before proceeding, if you do not have a good understanding of databases (MySQL in particular), be sure to read Appendix C in its entirety. Pay close attention to the sections on using quotes, comments, and semicolons. Also, if you feel you need some more information, please reference Appendix E, which describes SQL injections in more detail, in a FAQ style.
Section 3.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 your web browser to go to http://localhost/ece4112/messageboard/messages/php. 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 1ee7 and load the page. Q3.1.1 What message do you get back when you set the msg_id value to 1ee7? Looking at view_messages.php within your filestructure (ie: not in your browser), 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. Q3.1.2 Which message do you get back when running http:///ece4112/ messageboard/view_messages.php?msg_id=(SELECT COUNT() FROM users)?*
Section 3.2 – Blind SQL Injection
One way of combating SQL injections is to block any error output from being displayed to the user. For most web servers, this is just a simple variable change within the server’s configuration file. The admin can identify a specific page that will be displayed if there is a database error (say, one that simply states there was an error, without displaying any details which the attacker could use). The actual error output could then be collected in a document somewhere that only the authorized administrators can view so that debugging can still take place. However, this does not necessarily mean that an attacker cannot use SQL injection anymore. Let’s see why. Back in your browser, change the URL so that the msg_id value is 0.
Now, look at view_message.php within your filesystem. Q3.2.4. What is the $SQL variable going to be when it is submitted to the database? 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. Q3.2.5. What is the user_id/password combination you stole? Q3.2.6. How might a web developer prevent this type of data theft?
Section 3.3 – Faulty Login Page
Now that we have seen how to use SQL injection directly with 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 [path to apache2]/htdocs. In a web browser, go to http://localhost/php_login/login_corrupt.php. Try a random username and password and observe what happens. A statement similar to 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.
Q3.3.1 What happened? Explain why this sql injection worked. (Hint: what is -- in a sql statement? Look at the appendices.) Q3.3.2 List at least three other similar sql injection code snippets that could be used to exploit this login? Screenshot 4: Take a screen shot of a successful login.
Section 3.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://localhost/php_login/login.php. Play around with the login page to see if there are any obvious outputs. To register a username, go to http://localhost/php_login/register.php Try SQL injection statements in login.php. What happens? Now open up login.php. Q3.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. Q3.4.2 How is the username and password verification different in login.php versus login_corrupt.php? Q3.4.3 What does the get_magic_quotes_gpc() function do? Q3.4.4 What are magic quotes? Q3.4.5 Explain the general strategy in preventing SQL injection statements.
Section 4: 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.
