BrixBits Java Web Application Security Webinar Series Testing VM Setup guide

BrixBits Java Web Application Security Webinar Series Testing VM Setup Guide

BrixBits Java Web Application Security Webinar Series

Copyright 2016 BrixBits, Inc. Page 2 of 40

THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF A LICENSE AGREEMENT. EXCEPT AS EXPRESSLY SET FORTH IN SUCH LICENSE AGREEMENT, BRIXBITS, INC., PROVIDES THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SOME STATES DO NOT ALLOW DISCLAIMERS OF EXPRESS OR IMPLIED WARRANTIES IN CERTAIN TRANSACTIONS; THEREFORE, THIS STATEMENT MAY NOT APPLY TO YOU. YOU ARE ENCOURAGED TO READ THE LICENSE AGREEMENT BEFORE INSTALLING OR USING THIS DOCUMENTATION OR SOFTWARE.

Some companies, names, and data in this document are used for illustration purposes and may not represent real companies, individuals, or data.

This document could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein. These changes may be incorporated in new editions of this document. BrixBits, Inc., may make improvements in or changes to the software described in this document at any time.

© 2013-2016 BrixBits, Inc., all rights reserved.

U.S. Government Restricted Rights: The software and the documentation are commercial computer software and documentation developed at private expense. Use, duplication, or disclosure by the Government is subject to the terms of the BrixBits, Inc., standard commercial license for the software, and where applicable, the restrictions set forth in the Rights in Technical Data and Computer Software clauses and any successor rules or regulations.



Oracle, Sun, Sun Microsystems, Solaris, Java and JavaServer Pages are trademarks or registered trademarks of Oracle Corporation and/or its affiliates.

“Apache Tomcat” and “Tomcat” are trademarks of the Apache Software Foundation.

Azul Systems, the Azul Systems logo, and Zulu are registered trademarks of Azul Systems Inc.

Burp Suite Free Edition and Burp Suite Professional are developed and licensed by PortSwigger Ltd.

All contents of the EC-Council Web Site are: Copyright 2016 by EC-Council and/or its suppliers.

KALI LINUX is a trademark of Offensive Security.

Linux is a registered trademark of Linus Torvalds.

OWASP Projects used in this guide include Zed Attack Proxy (ZAP), bodgeit, and WebGoat.

“Red Hat”, Red Hat Linux, the Red Hat “Shadowman” logo, Red Hat Enterprise Linux operating system, CentOS, and CentOS Marks are trademarks or registered trademarks of Red Hat, Inc. in the US and other countries.

VMware is a registered trademark or trademark of VMware, Inc. in the United States and other jurisdictions.

All other product names mentioned herein and throughout the entire web site are trademarks of their respective owners.

OWASP Statement of Non-Endorsement

OWASP does not endorse any product, services or tools. The following disclaimer/About OWASP text can be used in projects or press releases that reference external products, services or tools:

About the OWASP Foundation: The Open Web Application Security Project (OWASP) is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of software. Our mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license. You'll find everything about OWASP linked from our wiki and current information on our OWASP Blog. OWASP does not endorse or recommend commercial products or services, allowing our community to remain vendor neutral with the collective wisdom of the best minds in software security worldwide. We ask that the community look out for inappropriate uses of the OWASP brand including use of our name, logos, project names and other trademark issues.



Contents 1 Intended Audience .................................................................................................................. 6

2 Support Contact Information .................................................................................................. 7

3 Overview of the testing process ............................................................................................. 8

3.1 Test case methodology .................................................................................................... 8

3.2 High level Installation steps ............................................................................................. 9

4 OS setup ................................................................................................................................ 10

4.1 Limit access to the VMs to protect outside hacks. ........................................................ 10

4.2 Create VMs. .................................................................................................................... 10

4.2.1 Use standard installation processes for Red Hat Enterprise Linux or CentOS. ...... 10

4.2.2 Kali Linux ................................................................................................................. 10

5 Web Application Server Installation ..................................................................................... 11

5.1 Install desired JDK .......................................................................................................... 11

5.1.1 Choose JDK .............................................................................................................. 11

5.1.2 OpenJDK .................................................................................................................. 11

5.1.3 Oracle Java .............................................................................................................. 11

5.1.4 Azul Zulu .................................................................................................................. 12

5.2 Tomcat ............................................................................................................................ 13

5.2.1 Tomcat Installation ................................................................................................. 13

5.2.2 Install the web applications .................................................................................... 16

6 Download web application penetration testing tools .......................................................... 17

6.1 Burp Suite Free ............................................................................................................... 17

6.2 ZAP .................................................................................................................................. 17

6.3 Add Firefox Extensions ................................................................................................... 18

7 Prepare Proxy ........................................................................................................................ 19

7.1 Configure pentest tools .................................................................................................. 19

7.2 Proxy ports ..................................................................................................................... 20

7.2.1 ZAP Proxy setup ...................................................................................................... 20

7.2.2 Burp Suite Proxy setup ............................................................................................ 21

7.3 Configure the web browser to use the proxy listed for Burp Suite. .............................. 22

7.3.1 Firefox ..................................................................................................................... 22

7.3.2 Ice Weasel on Kali ................................................................................................... 23

8 Automated Testing for Security Issues ................................................................................. 24



8.1 Explore the web site using ZAP ...................................................................................... 24

9 Manually run through some bodgeit use cases .................................................................... 27

9.1 Start Burp Suite proxy .................................................................................................... 27

9.2 Navigate the application ................................................................................................ 27

9.3 Find Hidden content as a non-admin user ..................................................................... 28

9.4 Display XSS popups......................................................................................................... 29

9.4.1 Level 1 ..................................................................................................................... 29

9.4.2 Level 2 ..................................................................................................................... 30

9.5 Change a password using GET ........................................................................................ 33

9.6 Logon as other users ...................................................................................................... 34

10 Manually run through some WebGoat use cases ................................................................. 35

10.1 Navigate the application ............................................................................................. 35

10.2 Injection Flaws ............................................................................................................ 35

10.2.1 Command Injection ................................................................................................. 35

10.2.2 Privileged account ................................................................................................... 40



1 Intended Audience

This document is designed to streamline the process of learning the basics of Java web application security. These instructions have been tested on the following operating systems: Red Hat® Enterprise Linux® and CentOS. Other Linux variations may require minor adjustments. Apache Tomcat, Burp Suite Free, OWASP ZAP, and OWASP vulnerable web applications are used in this guide. Since vulnerable web applications and penetration testing tools are used, this testing should be conducted in an isolated environment and ethical hacking techniques should be used.

NOTE: Improper use of penetration testing tools may result in employment dismissal, legal procedures, and other undesired outcomes. Please adhere to guidelines from internationally recognized professional organizations such as the EC-Council. http://www.eccouncil.org/Support/code-of-ethics

http://www.eccouncil.org/Support/code-of-ethics



2 Support Contact Information

To request a demo of Security Analyzer, please use the following link http://brixbits.com/request-a-demo/ If you encounter any issues or have any questions about BrixBits, Security Analyzer, this guide, related materials, or the testing process please reach out to Joseph Konieczka, BrixBits Sales Engineer. Email: [email protected] Cell: 832-319-0998 Skype: [email protected]

http://brixbits.com/request-a-demo/

mailto:[email protected]

mailto:[email protected]



3 Overview of the testing process

3.1 Test case methodology

These test cases were conducted on both Red Hat Enterprise Linux and CentOS using the following configuration. The screenshots and videos were recorded using CentOS.

1. OS: Red Hat Enterprise Linux 7 and CentOS 7 2. JDK: OpenJDK Runtime Environment (build 1.8.0_71-b15) 3. Web Application Server: Tomcat 8.0.28 4. Vulnerable applications: WebGoat 6, bodgeit, and the BrixBits demo application 5. Pentest tools: Burp Suite Free 1.6.30 and ZAP 2.4.2 6. RAM: 4 GB (minimal amount for a small POC) 7. Disk space: 10 GB (minimal amount for a small POC) 8. Processor: dual single core virtual CPUs 9. Hypervisor: VMware Workstation 12 Pro



3.2 High level Installation steps

1. OS installation 2. Updated to latest OpenJDK via yum 3. Installed Tomcat 8.0.28 4. Installed WebGoat 6 and bodgeit under the webapps directory 5. Installed Burp Suite Free 1.6.30 and ZAP 2.4.2 6. Downloaded and configured Firefox Extensions 7. Changed networking to Host Only mode 8. Used ZAP Attack to spider and then attack the default Tomcat site running on 8080,

/bodgeit, and /WebGoat 9. Manually ran through some of the bodgeit and WebGoat lessons



4 OS setup

4.1 Limit access to the VMs to protect outside hacks.

Localhost only networking should be used if installing known vulnerable applications such as WebGoat or bodgeit. Opening to an isolated network should only be done if traffic can be restricted.

4.2 Create VMs.

4.2.1 Use standard installation processes for Red Hat Enterprise Linux or

CentOS.

This document was created by using a VM tested on VMware Workstation Pro VMware Workstation Pro 12.1.0 build-3272444 and VMware Player 12.1.0 build-3272444 using Red Hat Enterprise Linux 7.0 and CentOS 7.0 build 1511 with the Server with GUI software selection installation option. The VM settings were 4 GB Memory, 2 Processors, localhost only network adapter, and 20 GB Hard Disk. Depending on your testing environment and choice of web application server, you may need to adjust these settings.

4.2.2 Kali Linux

https://www.kali.org/ Kali Linux is not required to complete these tests, but it does make more advanced penetration testing easier. All the bodgeit and WebGoat lessons outlined in this document can be exercised by using ZAP, Burp Suite Free, and the specified Firefox extensions. Observe all of the license restrictions, guidance, and compliance rules for Kali. Do not hack anything unless you are authorized by all of the owners of the data, including but not limited to the application hosting provider, the ISP, the application owner, your information security team, your company’s legal department, your manager, and anyone else in your organization designated in the change control approval process. If conducting an actual penetration test, submit a change control to the change advisory board, notify all interested parties, and update the NOC when starting and completing the test. Follow the instructions for installing and configuring Kali. Setup networking to connect to the localhost only network where the vulnerable web application is installed. Again, never use the vulnerable web applications or penetration testing tools in anything other than this isolated network, unless specifically authorized to do so.

https://www.kali.org/



5 Web Application Server Installation

5.1 Install desired JDK

5.1.1 Choose JDK

Regardless of the desired version of the JDK you choose, you will need to export the necessary environment variables: JAVA_HOME and JAVA_EXE.

5.1.2 OpenJDK

By default, OpenJDK is installed, so you only need to update the package via yum and then add these lines to a new file called /etc/profile.d/java_env.sh. If the JAVA environment variables are not defined, then OpenJDK jre will be used as Tomcat automatically looks for a java binary in the directory returned by which java. export JAVA_HOME=/usr/lib/jvm/<SPECIFIC VERSION>/jre export JAVA_EXE=$JAVA_HOME/bin/java

5.1.3 Oracle Java

Java 1.8.065 was the latest as of this document creation date. Replace with the correct version. Just replace the values with the desired values in steps 1-6 below. Since 7 and beyond leverage global environment variables, they can be used as is.

1. Create directory for java as needed. In this example /oracle_jre was used for the top

level directory

2. Download Java

3. tar –xzvf <SPECIFIC VERSION>/.tar.gz –C /oracle_jre

4. Change the default java location from openjdk to the latest version

a. su to root or sudo if configured

b. List current configuration:

c. /usr/sbin/alternatives --config java

d. Install new version as the next option:

/usr/sbin/alternatives --install /usr/bin/java java $JAVA_EXE 2

e. Select the new version:

/usr/sbin/alternatives --config java

f. Validate new configuration:

which java

ls -la /usr/bin/java

ls -la /etc/alternatives/java

java -version



5.1.4 Azul Zulu

https://www.azul.com/products/zulu/

No web applications installed, so you can temporarily switch to a NAT adapter and use the Azul

repository per its installation guide. Switch back to localhost once Zulu is installed.

1. su to root or sudo if configured

2. cd /etc/yum.repos.d/

3. Archive the standard repository definition files

a. mkdir /opt/default_repos

b. mv Cent*.repo /opt/default_repos

4. Create the custom repository definition

a. vim my.repo

b. Add the following lines

[myrepo]

name=myrepo

baseurl=file:///opt/installs/repository

5. Copy the Azul Zulu RPM package to /opt/installs/repository

6. Install the package

a. createrepo /opt/installs/repository/

b. yum repolist

c. yum search zulu

d. yum info zulu-8.x86_64

e. yum install zulu-8.x86_64 –nogpgcheck

7. Configure Zulu as the default JDK

8. Add these lines to a new file called /etc/profile.d/java_env.sh

a. export JAVA_HOME=/usr/lib/jvm/zulu-8

b. export JAVA_EXE=$JAVA_HOME/bin/java

9. Change the default java location from openjdk

g. su to root or sudo if configured

h. List current configuration:

i. /usr/sbin/alternatives --config java

j. Install new version as the next option:

/usr/sbin/alternatives --install /usr/bin/java java $JAVA_EXE 2

k. Select the new version:

/usr/sbin/alternatives --config java

l. Validate new configuration:

which java

ls -la /usr/bin/java

ls -la /etc/alternatives/java

java -version

https://www.azul.com/products/zulu/



5.2 Tomcat

5.2.1 Tomcat Installation

5.2.1.1 Create the user

useradd -s /sbin/nologin -d /home/tomcat

5.2.1.2 Create the directory structure

mkdir –p /opt/tomcat

5.2.1.3 Install Tomcat

Download Tomcat from http://tomcat.apache.org/download-80.cgi tar -xzvf apache-tomcat-8.0.28.tar.gz -C /opt/tomcat

http://tomcat.apache.org/download-80.cgi



5.2.1.4 Configure users for WebGoat and tomcat manager-gui roles in

/opt/tomcat/apache-tomcat-8.0.28/conf/tomcat-users.xml

1. Create guest and webgoat

2. Add manager-gui

<tomcat-users xmlns="http://tomcat.apache.org/xml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd" version="1.0"> <role rolename="webgoat_basic"/> <role rolename="webgoat_admin"/> <role rolename="webgoat_user"/> <role rolename="tomcat"/> <user password="webgoat" roles="webgoat_admin" username="webgoat"/> <user password="basic" roles="webgoat_user,webgoat_basic" username="basic"/> <user password="tomcat" roles="admin,tomcat,manager-gui,manager-script,manager-jmx,manager-status,admin-gui,admin-script" username="tomcat"/> <user password="guest" roles="webgoat_user" username="guest"/> <user roles="admin,tomcat,manager-gui,manager-script,manager-jmx,manager-status,admin-gui,admin-script" password="Admin$44" username="admin"/> </tomcat-users>

5.2.1.5 Run Tomcat manually

cd /opt/tomcat/apache-tomcat-8.0.28/bin ./startup.sh ./shutdown.sh

5.2.1.6 Setup Tomcat to run as a service

chown -R tomcat:tomcat /opt/tomcat Create a custom startup script named tomcat_start_stop_status.sh. (See the next page for the script) cp tomcat_start_stop_status.sh /etc/init.d/tomcat cd /etc/init.d chown root:root tomcat chmod 755 tomcat chkconfig --add tomcat chkconfig --level 345 tomcat on Another way is to use jsvc to run the service http://tomcat.apache.org/tomcat-8.0-doc/setup.html

http://tomcat.apache.org/tomcat-8.0-doc/setup.html



tomcat_start_stop_status.sh #!/bin/bash # chkconfig: 345 80 20 # description: Start up the Tomcat servlet engine. # processname: tomcat # Source function library. . /etc/init.d/functions RETVAL=$? CATALINA_HOME="/opt/tomcat/apache-tomcat-8.0.28/" case "$1" in start) if [ -f $CATALINA_HOME/bin/startup.sh ]; then echo $"Starting Tomcat" /bin/su -s /bin/bash tomcat $CATALINA_HOME/bin/startup.sh fi ;; stop) if [ -f $CATALINA_HOME/bin/shutdown.sh ]; then echo $"Stopping Tomcat" /bin/su -s /bin/bash tomcat $CATALINA_HOME/bin/shutdown.sh fi ;; status) pid=`ps -fe | grep $CATALINA_HOME | grep -v grep | tr -s " "|cut -d" " -f2` if [ -n "$pid" ]; then echo -e "\e[00;32mTomcat is running with pid: $pid\e[00m" else echo -e "\e[00;31mTomcat is not running\e[00m" fi ;; *) echo $"Usage: $0 {start|stop|status}" exit 1 ;; esac exit $RETVAL



5.2.2 Install the web applications

Copy the web applications war files to /opt/tomcat/apache-tomcat-8.0.28/webapps WebGoat and bodgeit are vulnerable web applications created by OWASP. https://www.owasp.org/index.php/OWASP_Vulnerable_Web_Applications_Directory_Project/Pages/Offline

5.2.2.1 WebGoat

https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project Download the war file and not the –exec.jar version which has an embedded Tomcat server https://github.com/WebGoat/WebGoat-Legacy/releases/tag/v6.0.1 The downloaded jar has the version number appended. Rename it to WebGoat.war in the webapps directory. Add users for WebGoat if prior

5.2.2.2 Bodgeit Store

Download https://github.com/psiinon/bodgeit

5.2.2.3 Validate that the applications startup correctly

Check that all the web application instances run correctly http://localhost:8080 http://localhost:8080/bodgeit http://localhost:8080/WebGoat

https://www.owasp.org/index.php/OWASP_Vulnerable_Web_Applications_Directory_Project/Pages/Offline

https://www.owasp.org/index.php/OWASP_Vulnerable_Web_Applications_Directory_Project/Pages/Offline

https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

https://github.com/WebGoat/WebGoat-Legacy/releases/tag/v6.0.1

https://github.com/psiinon/bodgeit

http://localhost:8080/

http://localhost:8080/bodgeit

http://localhost:8080/WebGoat



6 Download web application penetration testing tools

The easiest way to test is by using Kali Linux since all the tools are already pre-installed. Otherwise, you can download Burp Suite and ZAP individually to conduct the tests. Create /opt/pentest to store the files. If using the single pre-configured VM or the extracted tarball, then ZAP and Burp Suite are already in /opt/pentest

6.1 Burp Suite Free

https://portswigger.net/burp/download.html Copy the jar file to /opt/pentest. Since Burp Suite is just a jar file, you can run it directly with java -jar burpsuite_free_v1.6.30.jar

6.2 ZAP

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project ZAP is a zipped tar file, so you will need to extract it. tar -xzvf ZAP_2.4.2_Linux.tar.gz -C /opt/pentest

https://portswigger.net/burp/download.html

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project



6.3 Add Firefox Extensions

Including several extensions will decrease the learning curve of penetration testing using bodgeit and WebGoat since there are many tutorials that use a number of different extensions. https://addons.mozilla.org/en-us/firefox/collections/adammuntner/webappsec/ If you are not using Kali Linux, you will want to install these extensions. You can also install them on Kali Linux, if desired, as Ice Weasel conforms to the Firefox extension standards.

1. Firebug

2. Tamper Data

3. Live HTTP Headers

4. Cookies Manager+

https://addons.mozilla.org/en-us/firefox/collections/adammuntner/webappsec/



7 Prepare Proxy

7.1 Configure pentest tools

1. Start the proxy in either Burp Suite or ZAP. Burp Suite’s proxy will be used for the

majority of these tests, but both ZAP and Burp Suite will be used.

2. If using the single pre-configured VM or the extracted tarball, then ZAP and Burp Suite

are in /opt/pentest

3. Open separate two terminals

4. Burp Suite

a. cd /opt/pentest

b. java -jar burpsuite_free_v1.6.30.jar

5. Zap

a. cd /opt/pentest/ZAP_2.4.2

b. ./zap.sh

6. On Kali, they can be found under Applications – 03- Web Application Analysis



7.2 Proxy ports

Change the proxy ports for ZAP and Burp Suite as they default to 8080 which is the same port as the default Tomcat port.

7.2.1 ZAP Proxy setup

1. Tools menu

2. Options

3. Local Proxy

4. Edit Port to be 8002



7.2.2 Burp Suite Proxy setup

1. Proxy tab

2. Temporarily turn off the Intercept option.

3. Intercept tab

4. Click Intercept is on to turn it off.

5. Options tab

6. Select the current listener

7. Edit the listener to use a different port for all interfaces

8. Change from Loopback only to All interfaces

9. Change port 8080 to 8001

10. Confirm Warning about all interfaces



7.3 Configure the web browser to use the proxy listed for Burp Suite.

7.3.1 Firefox

1. Options

2. Advanced

3. Network

4. Connection

5. Settings

6. Select Manual proxy configuration

7. HTTP Proxy

8. localhost

9. Port 8001

10. Check Use this proxy server for all protocols

11. Delete all entries under No Proxy for



7.3.2 Ice Weasel on Kali

1. Preferences

2. Advanced

3. Network

4. Connection

5. Settings

6. Select Manual proxy configuration

7. HTTP Proxy

8. localhost

9. Port 8001

10. Check Use this proxy server for all protocols

11. Delete all entries under No Proxy for



8 Automated Testing for Security Issues

8.1 Explore the web site using ZAP

1. cd /opt/pentest/ZAP_2.4.2 2. ./zap.sh 3. ZAP displays the Sites and Quick Start tabs by default

4. Sites will list all of the discovered web sites and URLs

5. Attack the basic tomcat website http://localhost:8080 or http://<HOSTNAME>:8080

6. Once sites have been discovered, then you can use the Select button to choose any of

the URLs found.

http://localhost:8080/



7. ZAP will first walk the site in the Spider tab.

8. Once the site has been traversed, an Active Scan will begin.

9. Once the scan has finished, you will see that there are no current scans and the pause

and stop buttons are greyed out.



10. Now the sites list is populated with the discovered hierarchy. This represents the default

tomcat starting and administration pages.

11. Attack the other applications that are installed on the server

a. http://rhel03:8080/bodgeit

b. http://rhel03:8080/WebGoat

12. Sites has been expanded to include bodgeit and WebGoat.

13. The Alerts tab shows the high level vulnerabilities that have been found. The left pane

shows the results and the right pane provides an explanation of the vulnerability type.

http://rhel03:8080/bodgeit

http://rhel03:8080/WebGoat



9 Manually run through some bodgeit use cases

Tutorial for additional information for completing the lessons. http://resources.infosecinstitute.com/the-bodgeit-store-part-1-2/ http://resources.infosecinstitute.com/the-bodgeit-store-part-2/

9.1 Start Burp Suite proxy

1. cd /opt/pentest

2. java -jar burpsuite_free_v1.6.30.jar

9.2 Navigate the application

Browse each of the Web pages and review the displayed HTML. Each of the pages is standalone, except for the About Us page which links to the Scoring page which lists the exploits that can be graded. The tasks do not need to be completed in order.

Challenge Done?

Login as [email protected] Not completed

Login as [email protected] Not completed

Login as [email protected] Not completed Find hidden content as a non admin user Not completed

Find diagnostic data Not completed

Level 1: Display a popup using: <script>alert("XSS")</script>.

Not completed

Level 2: Display a popup using: <script>alert("XSS")</script>

Not completed

Access someone else’s basket Not implemented/tested yet :(

Get the store to owe you money Not completed Change your password via a GET request Not completed

Conquer AES encryption, and display a popup using: <script>alert("H@cked A3S")</script>

Not completed

Conquer AES encryption and append a list of table names to the normal results.

Not completed

http://resources.infosecinstitute.com/the-bodgeit-store-part-1-2/

http://resources.infosecinstitute.com/the-bodgeit-store-part-2/



9.3 Find Hidden content as a non-admin user

Review the comments on the web pages to uncover a hidden admin.jsp link.  When you access that page, you will see the following table. Now we have a list of the current users that exist for the application. Gaining access to usernames is often a starting point for hackers.



9.4 Display XSS popups

9.4.1 Level 1

Search for a product and try to insert HTML tags. <u><sup>Testing Tags </sup></u> When you click the Search button, you will see underlined superscript text.

This indicates that input validation is not enabled for the search criteria, so try to inject a script that indicates a XSS attack. <script>alert("XSS")</script> The alert popup will display and the task will now be listed as completed on the scoring page.



9.4.2 Level 2

A second task also includes XSS, so navigate to the Contact Us page as many comment pages allow free form text in the fields. Again, this is a failure to validate user supplied input and is one of the most common XSS and SQLi attack vectors. When you use HTML tags, the displayed input includes the underlined superscript. <u><sup>Testing Comment Page for Injection </sup></u>

However, typing in <script>alert("XSS")</script> only displays alert(XSS) and not a popup. If you enable the Burp Suite Intercept Proxy, then you can examine both the HTTP Request and Response. For each request, you can examine it in Burp Suite and then forward the request to the application. For the request, review the comments field.



For the response, you can view the outputted row in several of the tabs. The easiest way is to go the the HTTP history tab, select the last POST, choose the Response tab, and finally the Raw tab. <tr><td>alert(XSS)</td></tr>



Many websites attempt to protect against attacks using basic blacklist entries, but hackers are always adapting to this technique and can easily generate many varieties of input strings. For this example, simply change the case of script and substitute single quotes for the double quotes. <SCRIPT>alert('XSS')</SCRIPT> This attempt works, but it does not satisfy the criteria for the Level 2 attack. Other potential form inputs should be explored to perform the XSS attack. Since some of the other tasks include logging in as other users, it makes sense to create a new user and determine how sessions are validated. It would also be a good test for a possible stored SQL injection as the username is stored persistently in the database. Select the Login page and then register. Attempt to use an invalid string like the alert text we’ve used before. A basic validation test is used as an error message is returned: Invalid username - please supply a valid email address. Try using [email protected]<script>alert("XSS")</script> and see what happens. The logon is accepted and the XSS popup message displays. Since the username is now saved in the database, any page that displays the username will automatically generate the alert. Logout to prevent the popup from repeatedly reoccurring. Level 2 XSS is now completed.

mailto:[email protected]%3cscript%3ealert(%22XSS%22)%3c/script



9.5 Change a password using GET

Another task is to change the password using GET and not POST. Many websites do not restrict the HTTP method used, so this is another common form of tampering. Create a new user and then select the username on the top right to access the Change Password form. Enable the Burp Suite proxy and step through the requests. We will change the method used and proceed with the transaction. Select the Headers tab and change from POST to GET. Also notice that the password field is actually being sent as a URL parameter, so sensitive information is being exposed in clear text.

/bodgeit/password.jsp?password1=test2&password2=test2 HTTP/1.1



9.6 Logon as other users

Use SQL Injection to bypass the password check for the user logins. If you want to generate some additional Java Exceptions, then simply mistype the exploit by leaving off one of the ‘ so that the command is incomplete - [email protected] 'or'1'=1 The correct string to compromise each of the usernames leverages 'OR'1'='1 to force the statement to always be true. [email protected]'OR'1'='1 [email protected]'OR'1'='1 [email protected]'OR'1'='1

mailto:[email protected]'OR'1'='1





10 Manually run through some WebGoat use cases

Tutorial for additional information for completing the lessons. The WebGoat lessons themselves provide hints and the solution for most of the exercises. There are also a large number of videos on YouTube. http://www.win.tue.nl/~jhartog/CourseSecurity/Materials.html

10.1 Navigate the application

WebGoat has a multitude of lessons that cover a wide range of exploits. The lessons are designed to provide an understanding of security vulnerabilities and protections against them.

10.2 Injection Flaws

10.2.1 Command Injection

Select the Injection Flaws section and then Command Injection. This task uses OS commands to display a text file. Providing direct access to OS commands is a very dangerous operation and must be used with extreme caution.

http://www.win.tue.nl/~jhartog/CourseSecurity/Materials.html



10.2.1.1 Edited command and results

When the request is intercepted in Burp Suite, it is very easy to manipulate it and substitute a command of your choosing. In this example, netstat and ifconfig are used. This information could be useful to establish outbound connections, determine which services are running on the server, and network settings to identify other network servers to attach. Change the value for HelpFile. You will need to enclose the additional command with quotes to escape it as the help file already has a quote appended to it. Burp Suite will automatically encode the updated request. CommandInjection.help" & netstat -an & ifconfig"



Submit the request and then view the response in the web page.



You can also view the operation in Burp Suite’s HTTP History tab.



Burp Suite automatically encodes the edited command.



10.2.2 Privileged account

The command will be limited to the security context of the web application user, so understanding the user credentials and privileges of the application user is essential. If an application is running as root and command injection is possible, then hackers can add users, open connections to external servers for saving extracted data, anything else that they desire.

Technology

BrixBits Java Web Application Security Webinar Series Testing VM Setup guide