Hacking

Vulnerable Applications

Introduction

How often have we found ourselves in need of a vulnerable application, which we could use for various purposes? We could use such applications to test the web application scanners to assess the effectiveness of each scanner. We could also use vulnerable applications to test our knowledge of specific vulnerability detection and exploitation.

Earn two pentesting certifications at once!

Enroll in one boot camp to earn both your Certified Ethical Hacker (CEH) and CompTIA PenTest+ certifications — backed with an Exam Pass Guarantee.

View Pricing

Earn two pentesting certifications at once!

Enroll in one boot camp to earn both your Certified Ethical Hacker (CEH) and CompTIA PenTest+ certifications — backed with an Exam Pass Guarantee.

View Pricing

In this article we'll introduce two applications: the Damn Vulnerable Web Application (DVWA) and WebGoat. These two applications exist for one purpose only: to contain web vulnerabilities which we can exploit. Those two applications can be categorized as shown in the picture below. They are web applications, which require a webserver to run.

• Damn Vulnerable Web Applications (DVWA): PHP/MySQL web applications that contain various vulnerabilities.
• WebGoat: J2EE web application maintained by OWASP, designed to teach web application security lessons.

Damn Vulnerable Web Applications

First we need to download the Damn Vulnerable Web Application, extract it, and move it into the Apache document root folder:

# unzip DVWA-1.0.7.zip

# mv dvwa/ /var/www/

DVWA needs Apache web server and MySQL database server to function correctly, which is why we need to start them. To start both of them we need to issue the commands below:

# /etc/init.d/apache start

# /etc/init.d/mysql start

Afterwards we also need to edit DVWA configuration file /var/www/dvwa/config/config.inc.php, so the DVWA will be able to connect to the MySQL database. We have to change the following settings: db_server specifies the server host, which is localhost. The db_database specifies the name of the database to use; the database will be created once we've successfully set-up the DVWA web application. The last two configuration variables, db_user and db_password specify the username and password for MySQL database. On Backtrack Linux distribution the default username and password for MySQL are root:toor.

The relevant part of the configuration file is presented below:

$_DVWA = array();

$_DVWA[ 'db_server' ] = 'localhost';

$_DVWA[ 'db_database' ] = 'dvwa';

$_DVWA[ 'db_user' ] = 'root';

$_DVWA[ 'db_password' ] = 'toor';

When we first connect to the URI http://localhost/dvwa/ we'll have to set up the database. To do that we need to press on the "Create/Reset Database" button as presented in the picture below:

We can see that the database dvwa has been successfully created. Two tables were also created and popularized in that database. Those two tables are users table and guestbook table.

Afterwards, we can successfully login with the default username admin and password password that were automatically created by the DVWA web application. The next picture shows the DVWA login web page.

When we've successfully authenticated into the application, the web application will look like the picture below:

On the left side of the application there's a menu which we can use to navigate through the application. The DVWA web application contains the following vulnerability types:

• Brute Force Login
• Command Execution
• CSRF
• File Inclusion
• SQL Injection
• Upload Vulnerability
• XSS

We can start solving those challenges immediately or we can input the appropriate URIs to the web vulnerability scanner.

WebGoat

The WebGoat standard installation file already contains the Tomcat web server and Java JRE, which is why we don't need to install those separately. But let's just present what we would have to do if those were not present; this is included just to better introduce the default standalone Webgoat package. First we would need to install the Tomcat web server which will be used to host the WebGoat application. We can install the Tomcat web server with the command below:

# apt-get install tomcat6 tomcat6-admin tomcat6-examples tomcat6-docs

The package tomcat6 is the actuall Tomcat web server, whereas tomcat6-admin is used to administer the Tomcat web server. The tomcat6-examples provides useful Tomcat examples, whereas the tomcat6-docs installs the Tomcat documentation.

When we want to get server status and restart web applications, we need to access the URI http://yourserver:8080/manager/html, which is password protected. We need to create a user with a role manager in /etc/tomcat6/tomcat-users.xml.

We can also create virtual hosts if we connect to the URI http://yourserver:8080/host-manager/html, which is also password protected. To access it, we must create a user with a role admin in /etc/tomcat6/tomcat-users.xml.

When administering the Tomcat web server, some features need write access to the /etc/tomcat6/ directory, which isn't granted to the Tomcat user by default. This is why we need to grant the tomcat6 user permissions to that directory. We can do that with the commands below:

# chown tomcat6:tomcat6 /etc/tomcat6 -R

# chmod ug+w /etc/tomcat6 -R

Add the Tomcat admin users by editing the /etc/tomcat6/tomcat-users.xml configuration file. The configuration file should contain the following:

    <?xml version='1.0' encoding='utf-8'?>

    <tomcat-users>

        <role rolename="admin"/>

        <role rolename="manager"/>

        <user username="tomcatadmin" password="admin" roles="admin,manager"/>

        <role rolename="webgoat_basic"/>

        <role rolename="webgoat_user"/>

        <role rolename="webgoat_admin"/>

        <user username="basic" password="basic" roles="webgoat_basic,webgoat_user"/>

        <user username="guest" password="guest" roles="webgoat_user"/>

        <user username="webgoat" password="webgoat" roles="webgoat_admin"/>

        <user username="admin" password="admin" roles="webgoat_admin"/>

    </tomcat-users>

We added a new administrator user with username tomcatadmin and password admin. We also added WebGoat usernames basic, guest and webgoat with appropriate passwords. This is needed for being able to login to the WebGoat web application.

After that we can start Tomcat web server normally with the command:

# /etc/init.d/tomcat6 start

The port 8080 should be opened and in LISTENing state:

# netstat -lntup

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

tcp6 0 0 :::8080 :::* LISTEN 6864/java

When connecting to the Tomcat web server on the URI address http://localhost:8080 we can see the following default Tomcat webpage:

It really isn't much, but the links introduced on the webpage can display the documentation, samples and administrative interface.

We must download the WebGoat application WAR file:

# wget http://webgoat.googlecode.com/files/WebGoat-5.4.war

To install the WAR file, we must connect to the URI http://127.0.0.1:8080/manager/html and click on the "WAR file to deploy", which is presented in the picture below:

When we click on the Deploy button, the WebGoat-5.4.war file will be uploaded to the Tomcat web server and installed.

But we can avoid all of this if we use the default standalone Tomcat package. First we need to download and extract it:

# unzip WebGoat-5.4-OWASP_Standard_Win32.zip

# cd WebGoat-5.4/

# ./webgoat.sh start8080

This will start the Tomcat web server on port 8080 and the WebGoat application should be accessible on the http://localhost:8080/WebGoat/attack URI. This can be seen in the picture below:

Ok, we can see the WebGoat entry website. To actually start WebGoat, we need to press on the "Start WebGoat" button. The WebGoat is immediately started and we're redirected to the Web site presented below:

Now we have a working WebGoat vulnerable application and we can start testing various attacks on it. The following categories are available:

• Introduction
• General
• Access Control Flaws
• AJAX Security
• Authentication Flaws
• Buffer Overflows
• Code Quality
• Concurrency
• Cross-Site Scripting (XSS)
• Improper Error Handling
• Injection Flaws
• Denial of Service
• Insecure Communication
• Insecure Configuration
• Insecure Storage
• Malicious Execution
• Parameter Tampering
• Session Management Flaws
• Web Services
• Admin Functions

We've seen that it really pays off to use the standalone WebGoat package, since we don't need to bother with installation and configuration of Tomcat web server, and we also don't have to deploy the WebGoat war file.

Conclusion

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

We can see that WebGoat and DVWA contain mostly different vulnerabilities. That is why when trying to test a specific web application scanner, it's best to compare the results of chosen scanners against both web vulnerable applications. If we have an option, it would also be great to test all the scanners against real websites; just to be sure that one scanner is indeed better than the other. Of course the targeted website should contain at least one vulnerability so the web scanners can actually find something, otherwise it's not possible for them to detect something that isn't there.