Assignment IV: Threat Assessment

BY: JUSIL T. GAITE

Name: Jusil T. Gaite Date Began: 09-28-13

Block No: 1A Date Finished: 09-29-13

Contact No: 09263893693 Grade:

I. Web application security risks This assignment will introduce several common threats against web applications. Poor authentication, injection flaws and cross-site scripting top the list of the top ten web application security risks (The OWASP top 10 web application security risks, available at http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project). 1.1. Poor Authentication and Session Management Flawed authentication can lead to significant risks for web applications. Authentication of web servers are done through TLS/SSL but authentication of web users are done by a variety of methods, such as password login, cookies, challenge question, etc. The evidence that users need to provide for authentication can be something that they know, such as passwords or answers to challenge questions, something that they have, such as cookies or security tokens, and something whom you are, such as biometrics. Poor implementations of user authentication methods often create vulnerabilities in web applications. For example, a security challenge question that asks users about their favorite color could be a weak authentication method by itself since attackers can easily break in the authentication by guessing a list of common colors. Authentication using cookies without TLS/SSL is subject to session manipulation. When client site cookies are used to maintain web sessions without any encryption, attackers might be able to eavesdrop cookies and substitute their contents with unexpected contents. By doing this, attackers will be able to manipulate session information and therefore again unauthorized access to a web site. 1.2. Injection Flaws Injection flaws occur when an attacker sends specific crafted data, usually malicious codes, to a trusted web application and results in unintended actions returned by the trusted web application. The impact of injection flaws could vary depending on the malicious codes. If the malicious codes were past to an operating system as system calls or shell scripts, they can result in executing unauthorized commands. If the malicious codes were past to a database as SQL commands, they can result in the access of information that is not intended to be shown. For example, on a customer directory search page, an attacker can input specific data in the html form that asks for customer name and trick a web server to reveal the entire content of the customer database. SQL injection is an attack that exploits the vulnerability of the invalidated user input and reveals the content of the data that are not supposed to be seen by an attacker. For example, in

order to search for the information of a customer Smith , the SQL command past from the web application to the database is below: SELECT * FROM user_data WHERE name=Smith In this example, the table name in the database is user_data and the attribute name for searching is name. A user Smith can type in his name and search for his account information. However, an attacker may type in Smith OR 1=1, which will result in the following SQL past to the database: SELECT * FROM user_data WHERE name = Smith OR 1=1 Since the logical statement, 1=1, is always true, the database will return will all user data in the table user_data. The ramification for this attack is to examine user inputs for invalid inputs, such as the one in the example. User input validation can be done at either the web application layer or the database layer. At the web application layer, input validation is done by comparing user inputs with either an acceptable list of inputs (whitelisting) or a list of potential malicious values (blacklisting). Whitelisting is more restricted on user inputs but blacklisting can create loopholes. At the database layer, stored procedures can be used to validate inputs. Stored procedures are subroutines that are called upon by the database once associated data attributes are accessed. To validate user inputs, application developers have to write stored procedures for the data attributes that are related to the inputs and set up constraints for accessing these data attributes. 1.3. Cross Site Scripting Cross Site Scripting (XSS) is a type of injection flaw that an attacker injects malicious codes through either the URL or the user inputs of a web page, resulting in the redirection of other naive users web pages to a malicious web site, usually without the awareness of the naive users. There are many forms of XSS. Figure 4 illustrates an example. An attacker injects malicious contents into a trusted web site as user inputs and the malicious contents are stored in the trusted web sites database. Once a naive user accessed the malicious contents posted on the trusted web site, such as by clicking a link posted on the trusted web site or by reading the user messages posted on a guest book, the trusted web site would either redirect the user to the attackers web site or to run a malicious script program on the naive users computer. In additional to injecting malicious contents into a trusted web site, an attacker can also send a naive user mails with an URL pointing to a trusted web site but embedded with malicious scripts. The goal of XSS attacks is usually compromising users privacy or information confidentiality. XS is often used as a technique for phishing or cookie stealing. Once naive users

tricked to access the attackers site or to run a malicious script, they are usually asked to reveal their confidential information, such as user name, password, or credit card information. Since the naive users may think that they are communicating with the trusted web site, they would inevitably give their information to the malicious site. Countermeasures to XSS can be categorized as server-side solutions and client-side solutions. Server-side solutions are implemented on the web applications to detect malicious codes injected by attackers and client-side solutions are used to prevent naive users from running malicious URL or scripts on the user site. II. Objectives

In this assignment , you will learn to examine the following web application vulnerabilities: Poor authentication, SQL Injections, and Cross Site Scripting. III. WebGoat Login Steps: 1. The web server has already been pre-installed in your Lab and all you need to do is run the program. 2. From the menu bar on the top of the VM, select Applications > Accessories > Terminal. This will open up a Linux shell command terminal. 3. Run the following commands to start the web server. cd ~/tools/tomcat/bin sh startup.sh & 4. Use the Firefox browser to connect to the Apache Tomcat server which hosts WebGoat. Before connecting, make sure the browser is using the system proxy settings. a. On the menu bar of the browser. Select Edit > Preferences > Advanced > Network Tab > Settings. b. Make sure the Use system proxy settings radio button is selected. Click OK and Close. 5. Go to the Apache server homepage on your VM by entering http://localhost:8080/ into the Firefox address bar. Tip: When running a program on port 80, you do not have to specify the port number as it is the default HTTP port used by most web applications and servers.

6. Paste a screenshot of the Apache Tomcat welcome page from the browser.

3.1 Setup the Proxy Server We will investigate the web traffic between your browser and the Web server using a web proxy called Paros. All web communication between the browser and the Web server will be sent to Paros (the proxy server) first before it reaches the appropriate destination. 1. To start Paros, you need another Linux terminal window. Select Applications > Accessories > Terminal. Run these commands in the terminal window: cd ~/tools/paros sh startserver.sh

The Java-based Paros will execute and you will be greeted with its interface.

2. Now, you will need to change the proxy server settings in Firefox to redirect the web traffic to the proxy server. a. The proxy server is run under 127.0.0.1 and port 8080. On Paros menu, go to Tools > Options > Local Proxy, do the following settings Address 127.0.0.1 Port: 8008 (you may need to change it from 8080 to 8088)

b. Go back to your browser. Select Edit > Preferences > Advanced > Network Tab > Settings. c. Select the Manual Proxy Configuration radio button. d. Enter these values into the fields: HTTP: 127.0.0.1 Port: 8088 (the proxy settings need to match the setting on Paros) e. If there are any values in the No Proxy For: text field, delete them. This is important to make the proxy work successfully.

3. You have just enabled all HTTP traffic generated by Firefox to be sent to the running Paros proxy server which can analyze HTTP traffic before it is sent off to its final destination. If you reload http://localhost:8080/ on the browser, you will see Paros capture the web content sent between the server and the browser.

3.2 Web Goat Login 1. Go back to the browser in Ubuntu. Browse to http://localhost:8080/WebGoat/attack. 2. When prompted for login information, the user name is guest and the password is guest. On the WebGoat home page, click Start WebGoat. Note: when using latest version of WebGoat, username may not be guest. Check your username at /home/user/tools/WebGoat5.2/tomcat/conf/tomcat-users.xml

3. Go back to Paros. You should see Paros logs of the connection between the browser and WebGoat. What is the HTTP command used in the first transaction between the browser and WebGoat? GET What is the HTTP version? HTTP/1.1 4. On the left side of the screen is a list of WebGoat exercises you can try. We will try the first lesson, click on General and underneath it choose HTTP Basics.

5. This WebGoat exercise will accept a value in the text box that you enter and reverse it. In the Enter your name textbox, type your name and click on Go.

6. You can see the parameters sent between your browser and WebGoat with Paros. a. In Paros, look under Sites > http://localhost:8080 > WebGoat > POST:Attack(Screen,menu)(SUBMIT,Person). b. Change the view from Raw View to Tabular View. *You can see the session ID by looking under the Request tab in Paros next to the Cookie: reference.

7. There are two parameters in the transactions using POST: person and SUBMIT. The value for person is JUSIL and the value for submit is Go!. Explain the functions of the POST command with the two parameters. The function of the POST command is to post the parameters it got from the input (Textbox and Button) in the server and then it generates the inverse of the name entered to display it back again to the client. 7. You can also see the solution for the exercise by clicking on Show Solution in WebGoat. For all the exercises below, you can either read instructions from this manual or read the instructions from Show Solution (We use Paros instead of WebScarab in our lab). IV. Authentication Flaws in Login

With this assignment , you are going to exploit a common weakness in password retrieval systems. Web applications such as Web e-mail and Web forums provide their users the ability to retrieve a forgotten password with security questions. The problem is that there is no criterion to the strength of the security answers and some questions are overly easy to guess. 1. Click on Authentication Flaws and underneath select Forgot Password in the left pane of WebGoat. This assignment will show how vulnerable a bad authentication scheme is. 2. The goal here is to retrieve the password of another user. You are going to retrieve a password from a regular user with the username webgoat. a. Type in the user name into the User Name textbox and hit Submit.

b. You are presented with an over simplistic security question of What is your favorite color? c. Try different colors and see what happens when you enter a wrong color as the security answer. d. Enter red and you should be able to retrieve the password for the webgoat user.

In the next step you will try to retrieve the password for the WebGoat administrator account. Try to complete it without any hints or help. * If you have trouble breaking into the system, see Show Solution in the WebGoat menu.

What is the administrators user name and what is the password? 2275$starBo0rn3

Describe one method to improve the login security here. Use an authentication scheme wherein the security question/s to be used are those with a vast number of possible answers, and with that hacker would have hard time in cracking/hacking your account. Explain what you have learned from this exercise. A weak authentication scheme may cause ones account to be compromised. And one should be warned for websites that has same questions/authentications for your accounts are at risk. V. Injection Flaws String SQL Injection

SQL injection is used to gain access, extract data or compromise secured databases. The methods behind an attack are simple and the damage dealt can range from inconvenience to system compromise. 1. Click on Injection Flaws and underneath select String SQL Injection in the left pane in WebGoat. 2. The exercise first prompts you to enter the last name Smith (SQL is case sensitive). A simple SQL query to a database would looks like this SELECT * FROM user_data WHERE last_name = Smith

In this case, Smith is the value you enter in the Enter your name textbox. The SQL will select all information about the user Smith from the database.

How many entries have you obtained? Two Are they all information regarding the user Smith? Yes 3. Let us look at the following SQL command SELECT * FROM user_data WHERE name = Smith OR 1=1 This SQL command will ask the database to show all user information since 1=1 is always true. String SQL injection exploit the vulnerability that a database that does not conduct checks on constraints so that attackers can inject SQL commands through the regular user interface. 4. Now, enter Smith OR 1=1 in the Enter your last name textbox. 5. Paste a screen shot of your results.

6. What is the security implication of your results? It implies that the system has a very weak security that it allows someone to enter a String SQL injection attack in showing all the registered accounts by creating a condition on the query that will always result to a TRUE value. 7. Describe a method to fix the vulnerability in this exercise. The systems security should feature a validation that it it only allows one to enter only a name (alphabetic characters) and should accept numbers and special characters and other character. It should only accept characters/String in the alphabet. VI. Cross Site Scripting (XSS) Stored XSS attack

Stored XSS attacks allow users to create message content that could cause another user to load an undesirable page or undesirable content when the message is viewed or accessed. In this assignment you will create such a message. 1. Click on Cross-Site Scripting (XSS) and underneath select Stored XSS Attacks in the left pane in WebGoat. 2. In the title text box, type XSS example 3. In the message text box, copy and paste the following HTML content. <script language="javascript" type="text/javascript">alert("Ha! Ha! You are hacked! ");</script>

4. Click on Submit. You will click on the message you have just posted under message list. 5. What will happen if someone clicks on the message you have just posted? When someone clicks the link that Ive posted, it will open an alert showing that he/she has been hacked.

6. Paste a screenshot of the results below.

7. What is the security implication of your results? It implies that one can insert scripts, especially JavaScript in textboxes and when the victim clicks it he or she will be directed to a malicious website in gaining access to the victims sensitive data. It can result to a hacked account, identity theft and unauthorized use of your accounts. VII. Authentication Flaws in Session Management

This assignment illustrates the vulnerability of session management using Cookies. Using a proxy server, the attacker will be able to trap important information regarding transaction authorization information, such as authorization header and cookies. By manipulating these login information, the attacker can re-login as a different user. 1. To complete this assignment , you need to observe what HTTP requests are sent between the browser and the server. You can trap the web requests at the proxy server. To do this, on Paros, click on the Trap tab, check Trap request. This will trap the HTTP request at the proxy server, while the server waits for the HTTP request to arrive, letting the proxy server be the man-in-the-middle and giving the proxy server the ability to manipulate the HTTP request before letting the request continue to its destination.

2. Click on Authentication Flaws and underneath select Basic Authentication on the left pane in WebGoat.

3. Read the WebGoat description of the exercise and click on Submit. You will need to setup Paros before clicking Submit to trap the request as mentioned previously in order to continue. 4. Go to Paros and look under Sites > http://localhost:8080 > WebGoat > POST:Attack(Screen,menu)(SUBMIT,person). You will see your HTTP request intercepted at the proxy server and you can see the HTTP command you have just submitted. The HTTP header contains a basic authentication header called Authorization within the HTTP request. You should be able to see its value on the HTTP header window in Paros. The value should be some code following Authorization: Basic in the HTTP header request. 5. Write down the code here: Z3Vlc3Q6Z3Vlc3Q= 6. The code is encoded in BASE64 and we need to decode it to see the ASCII value. Use the decoder under Tools, Encoder/Hash. Decode it using BASE64 decode.

7. What is the plain text value of the authentication header that you have just decoded? guest:guest

8. Now, uncheck Trap request and click Continue to let the HTTP request go through. 9. Go back to WebGoat. Enter the name of the authentication header (Authorization) and the value of it (the code you have just decoded above) into the appropriate fields. Click on Submit. 10. Once you have successfully finished this exercise, paste a screen shot below.

11. WebGoat will ask you to further investigate authentication by logging in again using the username basic with password basic. Authentication header and Cookie (JSESSIONID) are the information that HTTP uses to manage a session. You are currently logging in as guest. The server can recognize you since the browser sends the server the same authentication header and JSESSIONID every time. If you want the server to ask you for a re-login, you need to corrupt your authentication header and JSESSIONID. 12. We can use Paros to alter the HTTP request and corrupt the authentication header and JSESSIONID. Go to Paros, check Trap request to intercept the HTTP command. 13. Go back to WebGoat, click on Basic authentication. Go back to Paros. You can see the intercepted HTTP command under the Trap tab. You can then delete the value after Authorization and Cookie. Click Continue to send the HTTP command to the server. 14. You will be prompted for re-login. You can now re-login as user basic using password basic.

15. Go to Paros. You will see the new authorization code for the user but the cookie (JSESSIONID) is the same because the browser sent the value that was cached. So, corrupt the Cookie by changing the JSESSIONID value to =novalidsession, uncheck Trap request and click Continue. 16. WebGoat losses all the information about the user guest and regards you as a new user basic. Now login as the user basic using the password basic and click on Start WebGoat to restart the exercise. Click on Basic Authentication to complete this exercise. 17. Paste a screen shot below that shows you have completed the Basic Authentication exercise.

18. Describe what you have learned from this Exercise. I have learned that one can use an application to intercept or trap a request and alter its parameters to compromise/exploit a vulnerability on a system. This method can be use to bypass some of the authentication of a system with a weak authentication mechanism. VIII. Turn off virtual machine 1. Change the settings in Paros back to port 8080 such as Tools > Options > Local proxy > Address 127.0.0.1 port: 8080 2. Click on File| Exit to close Paros. Note: After finishing this exercise, you should reset Firefox proxy setting so it stops using the proxy server. Otherwise you would not be able to visit web sites without running the proxy server. To do so, Launch your Firefox web browser, and follow its menu item path Edit|Preferences|Advanced|network Tab|Settings button to reach the Connection Settings window. Check the Use System Proxy Settings checkbox. 3. Run the following commands to stop the web server. cd ~/tools/tomcat/bin sh shutdown.sh 4. Close all the windows. Turn off the virtual machine by clicking the power button.