Exercise 1- Exploit Web Application Vulnerabilities
In many scenarios, organizations use off-the-shelf applications. In other scenarios, the
organizations use a mix of off-the-shelf and custom applications. The patches and updates for the
off-the-shelf applications are created and released by the vendor that created the application. It is
now the organization's responsibility to update their existing off-the-shelf applications to patch
these applications. In the case of custom applications, this is not the scenario. The custom
applications are developed to meet a specific business need. An organization may have an inhouse development team to create the application, or it might be outsourced to another vendor.
Releasing updates is a common issue with custom applications. The vendors do not provide
updates in most cases. Therefore, these inherent vulnerabilities will continue to be present until the
time application is used.
There are several known Web application vulnerabilities. Open Web Application Security Project,
more commonly known as OWASP, releases the top 10 Web application vulnerabilities, which are
released after every few years. This data is collected from various organizations through extensive
research, and then top 10 Web applications are selected. Remember - there are hundreds of Web
application vulnerabilities, and therefore, when doing a penetration test, you can focus on the key
ones but do not ignore to test for the other vulnerabilities. The top 10 Web application
vulnerabilities of 2017 released by OWASP are:
•
•
•
•
•
•
•
•
•
•
A1:2017-Injection
A2:2017-Broken Authentication
A3:2017-Sensitive Data Exposure
A4:2017-XML External Entities (XXE)
A5:2017-Broken Access Control
A6:2017-Security Misconfiguration
A7:2017-Cross-Site Scripting (XSS)
A8:2017-Insecure Deserialization
A9:2017-Using Components with Known Vulnerabilities
A10:2017-InsufficientLogging&Monitoring
This module will cover a few of these vulnerabilities that you can exploit.
Note: In this module, you will use a Web application named bWAPP, which is designed with
more than 200 vulnerabilities. It is not legal to exploit a live Web application on the Internet, and
therefore, you will use this Web application to learn the art of exploiting a Web application. It will
not be possible to cover all types of vulnerabilities due to the short time in the lab environment.
In this exercise, you will learn about exploiting Web application Vulnerabilities.
Alert
The tools and techniques displayed in these exercises are to be used for improving network
security. Usage of all tools for attacking targets without prior mutual consent is illegal. Practice
Labs assumes no liability for any misuse or damage caused if these tools and techniques are
used for malicious activities.
Learning Outcomes
After completing this exercise, you will be able to:
•
•
•
•
•
•
•
•
Launch a SQL Injection Attack
Perform Broken Authentication Attacks
View Session ID in URL
Conduct OS Command Injection Attack
Perform Server-side Includes Injection Attack (SSI)
Perform Cross-site Scripting Attack
Performing Directory Traversal Attack
Perform Web Application Brute Forcing Using DirBuster
Your Devices
You will be using the following devices in this lab. Please power on these devices.
•
•
•
•
PLABDC01 - (Windows Server 2019 - Domain Server)
PLABKALI01 - (Kali 2019.2 - Linux Kali)
PLABWIN10 - (Windows 10 - Domain Member)
PLABWIN810 - (Windows 8.1 - Domain Member)
Task 1 - Launch a SQL Injection Attack
SQL Injection or SQLi is an injection attack that allows the attack to execute malicious SQL
statements in a text box. Web applications are built with authentication and authorization.
However, if not programmed properly, the attacker can use the SQL statements to bypass
application security controls and measures. The SQL injection attack can allow the attacker to add,
remove, modify, or manipulate the data in the database in whichever he or she likes. If the SQL
injection attack is successful, the content of the entire database is at the mercy of the attacker.
In this task, you will learn to launch a SQL injection attack. To do this, perform the following steps:
Step 1
Ensure you have powered on all the devices listed in the introduction and connect to PLABWIN810.
Figure 1.1 Screenshot of PLABWIN810: Showing the desktop of PLABWIN810.
Step 2
From the Windows taskbar, click the Internet Explorer icon.
Figure 1.2 Screenshot of PLABWIN810: Clicking the Internet Explorer icon.
Step 3
The Internet Explorer window with the Intranet homepage is displayed. In the address bar, type the
following URL:
Note: bWAPP is case sensitive. Therefore, be cautious and enter exactly, as mentioned in the
URL below.
http://192.168.0.10/bWAPP
Press Enter.
Figure 1.3 Screenshot of PLABWIN810: Entering the bWAPP URL in the address bar.
Step 4
On the Login Webpage, use the following credentials:
Login:
bee
Password:
bug
Click Login.
Figure 1.4 Screenshot of PLABWIN810: Entering the user credentials and then clicking the Login
button.
Note: If you find the security level will not set then restart the nested PLABBWAPP device on
PLABWIN10. This can be done by doing the following steps: Connect to PLABWIN10, click Start
> Hyper-V Manager > Right click PLABBWAPP > Turn Off… > Right click PLABBWAPP > Start.
PLABBWAPP will take approximately 5 minutes to fully power on. Once done go back to
PLABWIN810 and refresh the web page, you should now be able to set the security level and
proceed.
Step 5
The Portal Webpage is displayed. In the notification bar, Click Not for this site.
Figure 1.5 Screenshot of PLABWIN810: Showing the notification bar in Internet Explorer.
Step 6
On the Portal Webpage, from the given list box, select SQL Injection (Get/Search) and click Hack.
Figure 1.6 Screenshot of PLABWIN810: Selecting SQL Injection (Get/Search) from the list of bugs.
Step 7
The SQL Injection (GET/Search) Webpage is displayed.
Without entering any data in the Search for a movie textbox, click Search.
Figure 1.7 Screenshot of PLABWIN810: Showing the SQL Injection (GET/Search) Webpage.
Step 8
The results are displayed. This means that there is a database in the backend that contains the
movie list.
Figure 1.8 Screenshot of PLABWIN810: Showing the search results.
Step 9
Let’s test if the application is prone to an SQL Injection attack. In the search box, type the following:
m’
Press Search.
Figure 1.9 Screenshot of PLABWIN810: Testing the application for SQL Injection attack.
Step 10
Notice the error that confirms that the SQL Injection attack is possible. A notification bar appears.
Click No.
Figure 1.10 Screenshot of PLABWIN810: Showing the error of SQL syntax and also showing the
notification.
Step 11
Next, you need to find the total number of columns that exist in the original SQL statement. Type
the following code in the textbox:
Note: The value of 1 is used to test if there is only one column in the database.
m’ order by 1-- -
Press Search.
Figure 1.11 Screenshot of PLABWIN810: Entering the statement to find the total number of columns
that exist in the original SQL.
Step 12
Notice the output. This means that there are more than one column in the database, and
column 1 does not have the movie list.
Figure 1.12 Screenshot of PLABWIN810: Showing the output of the statement that has been
executed.
Step 13
Next, try another random number. Type the following code in the text box:
m’ order by 8-- -
Press Search.
Figure 1.13 Screenshot of PLABWIN810: Entering the statement to find the total number of columns
that exist in the original SQL.
Step 14
Notice the following error:
Error: Unknown column ‘8’in ‘order clause’
Note: The value of 1 is used to test if there is only one column in the database.
This means that there are less than 8 columns.
Figure 1.14 Screenshot of PLABWIN810: Showing the error caused by the entered statement.
Step 15
Next, try another random number. Type the following code in the textbox:
Note: The value of 1 is used to test if there is only one column in the database.
m’ order by 7-- -
Press Search.
Figure 1.15 Screenshot of PLABWIN810: Entering the statement to find the total number of columns
that exist in the original SQL.
Step 16
There is no error in column 7, which confirms that there are a total of 7 columns in the original SQL
statement.
Figure 1.16 Screenshot of PLABWIN810: Showing the output of the entered statement.
Step 17
You will now need to select all columns at once using the union all select statement. To do this,
type the following statement:
m' union all select 1,2,3,4,5,6,7 -- -
Click Search.
Figure 1.17 Screenshot of PLABWIN810: Entering a statement to select all columns at once using
the union all select statement.
Step 18
Notice that there is no error. The output is now generated.
Figure 1.18 Screenshot of PLABWIN810: Showing the output of the union all select statement.
Step 19
You need to find the database name now. To do this, type the following statement:
m' union all select 1,database(),3,4,5,6,7 -- -
Click Search.
Figure 1.19 Screenshot of PLABWIN810: Entering a statement to find the database name.
Step 20
The name of the database appears in the Title column.
Figure 1.20 Screenshot of PLABWIN810: Showing the database name in the output.
Step 21
Next, you need to find the table names in the database, which is bWAPP. To do this, type the
following statement:
m' union all select 1,table_name,3,4,5,6,7 from
information_schema.tables where table_schema=database() -- -
Click Search.
Figure 1.21 Screenshot of PLABWIN810: Entering a statement to find the table names in the
database.
Step 22
Notice the output lists the table names. The statement that you executed has found five tables in
the bWAPP database.
Figure 1.22 Screenshot of PLABWIN810: Showing the table names in the output.
Step 23
Let’s explore the users table and find its columns. To to this, type the following statement:
m' union all select 1,column_name,3,4,5,6,7 from
information_schema.columns where table_name='users' and
table_schema=database() -- -
Click Search.
Figure 1.23 Screenshot of PLABWIN810: Entering a statement to explore the users table.
Step 24
Notice that the output reveals the names of the columns. There is a total of nine columns that were
found in the users table.
Figure 1.24 Screenshot of PLABWIN810: Showing the total number of columns in the table.
Step 25
Let’s now explore the values that are in the following columns:
•
•
•
login
Password
secret
Type the following statement:
m' union all select 1,login,password,secret,5,6,7 from users - -
Click Search.
Figure 1.25 Screenshot of PLABWIN810: Entering a statement to find the values of multiple
columns.
Step 26
Notice the output. Two records have been found in the users table.
Note: You have now got the hashed value as a password. You can use any password cracking
tool, such as John the Ripper, and retrieve the value. When you run value through John the
Ripper, the password is decrypted as a bug. Remember, this is the username you had used to
log in to this Web application.
Figure 1.26 Screenshot of PLABWIN810: Showing the user names in the users table.
Keep the Internet Explorer window open.
Task 2 - Perform Broken Authentication Attacks
Authentication is a process that confirms a user’s identity using a username and password. The
user’s identity is validated by the server or the Web application. In a Web application scenario, the
authentication process is as follows:
•
•
•
•
•
On a login form of a Web application, the user enters the login credentials in the form of a
username and password.
After the user submits the user credentials, they are then sent to the Web application, where
the user credentials are verified for the user, and then a session is created and stored in a
database.
A cookie is sent to the user’s system.
When a user makes a subsequent request, the session ID is verified with the one that is
stored in the database. The Web browser at the client end stores and sends the token as a
cookie to the server. If both the session ID values match, the user’s request is processed.
However, if the values do not match, then the request is not processed any further.
After performing certain tasks, when a user logs out from the Web application, from the
client and the server, the session is destroyed.
In this task, you will learn to perform broken authentication attacks. To do this, perform the
following steps:
Step 1
Ensure you have powered on all the devices listed in the introduction and connect to PLABWIN810.
The Internet Explorer window should be open.
Figure 1.27 Screenshot of PLABWIN810: Showing the SQL Inject (Get/Search) page.
Step 2
From the Choose your bug: drop-down, select Broken Authentication - Insecure Login Forms, and
click Hack.
Figure 1.28 Screenshot of PLABWIN810: Selecting Broken Authentication - Insecure Login Forms
and clicking Hack.
Step 3
The login page is displayed.
Figure 1.29 Screenshot of PLABWIN810: Showing the login page.
Step 4
Several times, the developers hard-code the login information in the login form. It is quite easy to
extract login information. To do this, right-click anywhere on the login form and select View source.
Figure 1.30 Screenshot of PLABWIN810: Right-clicking the Webpage and selecting View source.
Step 5
A Notepad window opens and displays the source code for the login page. Review the code from
line 59 to 63. Notice the username and password. It displays the login name as tonystark and
password as I am Iron Man.
Figure 1.31 Screenshot of PLABWIN810: Showing username and password in the source.
Step 6
Close the Notepad window.
Let’s try another type of Broken Authentication. From the Choose your bug: drop-down,
select Session Management - Administrative Portals, and click Hack.
Figure 1.32 Screenshot of PLABWIN810: Selecting Session Management - Administrative Portals
and clicking Hack.
Step 7
The Session Mgmt. - Administrative Portals Webpage is now loaded.
Figure 1.33 Screenshot of PLABWIN810: Showing the Session Mgmt. - Administrative Portals
Webpage.
Step 8
Click on the address bar and notice the last part of the URL. It is mentioning admin=0, which means
that a session ID is being passed in the query string.
Figure 1.34 Screenshot of PLABWIN810: Showing the admin=0 as the session ID in the URL
Step 9
Change the admin=0 to admin=1 and press Enter.
Figure 1.35 Screenshot of PLABWIN810: Changing the session ID in the URL.
Step 10
Notice the outcome of the change that you made in the URL. The Webpage now displays a
message that you have unlocked the page using URL manipulation.
Figure 1.36 Screenshot of PLABWIN810: Showing the output of changing the session ID.
Step 11
Logout management is one of the common vulnerabilities in Web applications. Even if the user logs
out, the user session is still alive. One of the common methods is to click the Back button on the
Web browser to get back to the same session after logging out.
Let’s perform a logout management attack on this Web application. From the Choose your
bug drop-down, select Broken Authentication - Logout Management and click Hack.
Figure 1.37 Screenshot of PLABWIN810: Selecting Broken Authentication - Logout Management
and clicking Hack.
Step 12
The Broken Auth - Logout Management Webpage is loaded. Right-click the here in the Click here to
logout statement and select Open in new tab.
Figure 1.38 Screenshot of PLABWIN810: Opening a new tab by right-clicking here in the logout
statement.
Step 13
The bWAPP - Login tab opens. Click the new tab. Notice that you are logged out successfully. Close
this tab.
Figure 1.39 Screenshot of PLABWIN810: Showing the Login page on the second tab.
Step 14
Notice that you are back on the first original tab. You are still logged in this tab.
Click Bugs.
Figure 1.40 Screenshot of PLABWIN810: Clicking Bugs in the menu bar on the first tab.
Step 15
The Portal Webpage is loaded successfully. This means that you were still able to work within the
Web application.
Figure 1.41 Screenshot of PLABWIN810: Showing the Portal Webpage.
Keep the Internet Explorer window open.
Task 3 - View Session ID in URL
One other major vulnerability with the Web application is using the session IDs in the URL. If a
session ID is sent in the URL, an attacker can grab the current session, specifically if the session ID
is sent in cleartext. The attacker can eavesdrop on the session and capture the current session to
impersonate the user. The session ID should be sent to the Web server in the body part of the
request. An encrypted connection must be used for sending the request so that it cannot be
intercepted by the attacker. In this task, you will learn to view the session ID in a URL. To perform
this task, perform the following steps:
Step 1
Ensure you have powered on all the devices listed in the introduction and connect to PLABWIN810.
The Internet Explorer window should be open with the bWAPP Web application loaded.
Note: If, for some reason you had closed the Internet Explorer window or logged out of the
current session, ensure that you log back into the bWAPP Web application.
From the Choose your bug drop-down, select Session Management - Session ID in URL and
click Hack.
Figure 1.42 Screenshot of PLABWIN810: Selecting Session Management - Session ID in URL and
clicking Hack.
Step 2
The Session Mgmt. - Session ID in URL Webpage is loaded. Pay attention to the last part of the URL
- there is a session ID, which is in cleartext. This could lead to an eavesdropping attack by the
attacker.
Figure 1.43 Screenshot of PLABWIN810: Showing the session ID in the URL.
Keep the Internet Explorer window open.
Task 4 - Conduct OS Command Injection Attack
Command injection is a type of attack in which the attacker executes arbitrary commands through
a vulnerable application to the host operating system. When an application allows the unsafe usersupplied data, such as forms, cookies, HTTP headers, to be passed to the host system, the attacker
can take advantage of this vulnerability to gain access to the underlying host system. Command
injection attacks take place because input fields accept arbitrary data without sufficient input
validation.
In this task, you will learn to conduct an OS command injection attack. To do this, perform the
following step:
Step 1
Ensure you have powered on all the devices listed in the introduction and connect to PLABWIN810.
The Internet Explorer window should be open.
From the Choose your bug drop-down, select OS Command Injection and click Hack.
Figure 1.44 Screenshot of PLABWIN810: Selecting OS Command Injection and clicking Hack.
Step 2
The OS Command Injection Webpage is displayed. Click Lookup.
Figure 1.45 Screenshot of PLABWIN810: Clicking Lookup on the OS Command Injection Webpage.
Step 3
Notice the output. The firewall blocks the DNS query to go out of the lab environment, and
therefore, you get a connection timed out error.
Figure 1.46 Screenshot of PLABWIN810: Showing the error as the output of Lookup.
Step 4
Replace the existing text in the DNS lookup text box and type the following:
|hostname
Click Lookup.
Figure 1.47 Screenshot of PLABWIN810: Entering |hostname and clicking Lookup.
Step 5
The output is now displayed.
Figure 1.48 Screenshot of PLABWIN810: Showing the output of the |hostname command.
Step 6
Replace the existing text in the DNS lookup text box and type the following:
|net user
Click Lookup.
Figure 1.49 Screenshot of PLABWIN810: Entering |net user and clicking Lookup.
Step 7
The output is now displayed. There are two users, nobody, and bee.
Figure 1.50 Screenshot of PLABWIN810: Showing the output of the |net user command.
Step 8
Switch to PLABKALI01. Invoke Firefox from the left pane and load the following Website:
http://192.168.0.10/bWAPP
On the Login Webpage, use the following credentials:
Login:
bee
Password:
bug
Click Login.
Figure 1.51 Screenshot of PLABKALI01: Entering the user credentials of the Login page.
Step 10
From the Choose your bug drop-down, select OS Command Injection and click Hack.
Figure 1.53 Screenshot of PLABKALI01: Selecting OS Command Injection and clicking Hack.
Step 11
The OS Command Injection Webpage is now loaded.
Replace the existing text in the DNS lookup text box and type the following:
|whoami
Click Lookup.
Figure 1.54 Screenshot of PLABKALI01: Entering |whoami and clicking Lookup.
Step 12
The output of the command is displayed.
Figure 1.55 Screenshot of PLABKALI01: Showing the output of |whoami.
Step 13
Replace the existing text in the DNS lookup text box and type the following:
|pwd
Click Lookup.
Figure 1.56 Screenshot of PLABKALI01: Entering |pwd and clicking Lookup.
Step 14
The output of the command is displayed. It displays the directory for the current Web application.
Figure 1.57 Screenshot of PLABKALI01: Showing the output of |pwd.
Step 15
You can also read the contents of a file using the command injection attack. Replace the existing
text in the DNS lookup text box and type the following:
|cat /etc/passwd
Click Lookup.
Figure 1.58 Screenshot of PLABKALI01: Entering |cat /etc/passwd and clicking Lookup.
Step 16
Notice the output is displayed. The contents of the /etc/passwd file are displayed.
Figure 1.59 Screenshot of PLABKALI01: Showing the output of the |cat /etc/passwd.
Keep the Internet Explorer window open.
Task 5 - Perform Server-side Includes Injection Attack (SSI)
SSI directives are used in web applications to provide dynamic content to the HTML pages. SSIs
execute a set of defined actions before the Webpage is loaded. Therefore, the Web server, which
hosts the Web application, analyses the SSI before the HTML page is loaded in the user’s Web
browser. The SSIs are mainly injected into the fields that accept inputs. When the field input is
submitted, the script, which was added to the input field, is executed. In an SSI attack, the attacker
injects malicious scripts into the HTML pages. By injecting the scripts, the attacker can gain
access to sensitive information or even execute shell commands. The SSI directives are injected in
input fields, and they are sent to the web server.
To perform an SSI attack, perform the following steps:
Step 1
Ensure you have powered on all the devices listed in the introduction and connect to PLABWIN810.
The Internet Explorer window should be open.
From the Choose your bug drop-down, select Server-side Includes (SSI) Injection and click Hack.
Figure 1.60 Screenshot of PLABWIN810: Selecting Server-side Includes (SSI) Injection and clicking
Hack.
Step 2
The Server-Side Includes (SSI) Injection Webpage is loaded. In the First name text box, type the
following:
plab
In the Last name text box, type the following:
user
Click Lookup.
Figure 1.61 Screenshot of PLABWIN810: Entering the user credentials on Server-Side Includes (SSI)
Injection page.
Step 3
Notice that the output is displayed with an IPv4 address. Click the Back arrow to navigate back to
the previous page.
Figure 1.62 Screenshot of PLABWIN810: Showing the output and clicking the Back button.
Step 4
Back on the Server-Side Includes (SSI) Injection Webpage, you need to insert the following into
the First name text box:
alert("Hacked")
In the Last name text box, type the following:
user
Click Lookup.
Figure 1.63 Screenshot of PLABWIN810: Entering a script in the First name field and user in the
Last name field.
Step 5
Notice the output. The script embedded in the First name text box has been executed successfully.
Click OK.
Figure 1.64 Screenshot of PLABWIN810: Showing the output of the entered script as prompt.
Step 6
Again, the text on the Webpage is changed to the IPv4 address. Click the Back button on the Web
browser.
Figure 1.65 Screenshot of PLABWIN810: Showing the output and clicking the Back button.
Step 7
Back on the Server-Side Includes (SSI) Injection Webpage, you can also fetch the cookie from the
Web server. you need to insert the following into the First name text box:
alert(document.cookie)
In the Last name text box, type the following:
user
Click Lookup.
Figure 1.66 Screenshot of PLABWIN810: Fetching the cookie from the Web server by using a script
in the First name text box.
Step 8
Notice the output. The script embedded in the First name text box has been executed successfully.
The cookie is being displayed in the dialog box. Click OK.
Figure 1.67 Screenshot of PLABWIN810: Showing the cookie in the dialog box.
Step 9
Again, the text on the Webpage is changed to the IPv4 address. Click the Back button on the Web
browser.
Figure 1.68 Screenshot of PLABWIN810: Showing the output and clicking the Back button.
Step 10
Back on the Server-Side Includes (SSI) Injection Webpage, you can show the current document
name. you need to insert the following into the First name text box:
In the Last name text box, type the following:
plab
Click Lookup.
Figure 1.69 Screenshot of PLABWIN810: Entering a script in the First name text box.
Step 11
Notice the output. It displays the current document name before the last name, which is plab. Click
the Back button on the Web browser window.
Figure 1.70 Screenshot of PLABWIN810: Showing the output and clicking the Back button.
Step 12
Back on the Server-Side Includes (SSI) Injection Webpage, you can show the virtual path and
filename. To do this, you need to insert the following into the First name text box:
In the Last name text box, type the following:
plab
Click Lookup.
Figure 1.71 Screenshot of PLABWIN810: Entering a script in the First name text box.
Step 13
Notice that the output shows the virtual path and the file name. Click the Back button on the Web
browser.
Alert: Try the following command: and note the output.
Figure 1.72 Screenshot of PLABWIN810: Showing the output and clicking the Back button.
Step 14
You should be back on the Server-Side Includes (SSI) Injection Webpage.
Figure 1.73 Screenshot of PLABWIN810: Clicking the Back button and then showing the ServerSide Includes (SSI) Injection page.
Keep the Internet Explorer window open.
Task 6 - Perform Cross-site Scripting Attack
Cross-site scripting (XSS) is a type of attack where the attacker injects malicious scripts into
vulnerable web applications, thereby causing serious damage to the applications. The malicious
script is executed in the victim’s web browser when the victim visits the infected page. JavaScript
is the most common scripting language used for developing malicious codes. There are two broad
categories of cross-site scripting attacks. These are as follows:
•
•
Reflected XSS
Stored XSS
A reflected XSS attack is also known as the non-persistent XSS attack. In this type of attack, the
attacker sends the malicious code as a link in an email or posts it on the website. The victim clicks
the link. The malicious script embedded within the link gets executed and is reflected back on the
victim’s web browser. The browser then sends the cookie information of the victim’s session to the
attacker. Thus, reflected XSS attack occurs only if the victim clicks the malicious links. Malicious
links are generally found in unknown emails and comments section of less secure websites.
A stored XSS attack is also known as the persistent XSS attack. In this type of attack, the attacker
injects the malicious script directly into a vulnerable web application. The malicious script steals
the cookie information of the victim’s sessions and sends it to the attacker. Therefore, in stored
XSS attack, the damage is more as the malicious script executes on every visit to the web
application.
In this task, you will perform cross-site scripting attacks on bWAPP application.
Step 1
Ensure you have powered on all the devices listed in the introduction and connect to PLABWIN810.
The Internet Explorer window should be open.
To begin reflected cross-site scripting attack, from the Choose your bug drop-down, click Crosssite Scripting - Reflected (GET) and click Hack.
Figure 1.74 Screenshot of PLABWIN810: Clicking Cross-site Scripting - Reflected (GET) and clicking
Hack.
Step 2
On the XSS - Reflected (GET) Webpage, In the First name text box, type the following name:
Plab
In the Last name text box, type the following name:
User
Click Go.
Figure 1.75 Screenshot of PLABWIN810: Entering user credentials on the XSS - Reflected (GET)
page.
Step 3
Observe the output displayed on the screen.
The input passed to the server is reflected in the application. This indicates a good entry point for
reflected XSS attacks as the response is getting reflected.
Figure 1.76 Screenshot of PLABWIN810: Showing the input passed to the server is reflected in the
application.
Step 4
On the XSS - Reflected (GET) Webpage, In the First name text box inject a JavaScript code, type the
following name:
alert(“Hacked”)
In the Last name text box, type the following name:
User
Click Go.
Note: The script contains the following tags: : This tag determines the start of
JavaScript.alert: This will display an alert box on script execution.Hacked: This is the text to be
displayed in the alert box.: This tag determines the end of JavaScript.
Figure 1.77 Screenshot of PLABWIN810: Entering the JavaScript code in the First name text box.
Step 5
The server processes the script and displays the alert message box.
Click OK.
Note: The script is executed and reflected back in the server response, which is a vulnerability.
Using this vulnerability in a real-time environment, an attacker can inject malicious scripts in
less secure applications to steal cookies, learn about the document location, and so on.
Figure 1.78 Screenshot of PLABWIN810: Showing the output of the injected script.
Step 6
You are back on the XSS - Reflected (GET) Webpage. From the Choose your bug drop-down,
select Cross-Site Scripting - Stored (Blog) and click Hack.
Figure 1.79 Screenshot of PLABWIN810: Selecting Cross-Site Scripting - Stored (Blog) and clicking
Hack.
Step 7
On the XSS - Stored (Blog) Webpage, type the following message in the text box:
Welcome to the PLAB blog!
Click Submit.
Figure 1.80 Screenshot of PLABWIN810: Entering statement in the text box on the XSS - Stored
(Blog) page.
Step 8
Observe the output displayed on the screen.
The entered values are stored in the application’s database and are displayed permanently in the
application’s XSS - Stored (Blog) page. This could be a potential entry point for stored XSS attacks.
Figure 1.81 Screenshot of PLABWIN810: Showing the stored statement that had been entered in the
text box.
Step 9
On the XSS - Stored (Blog) Webpage, type the following message in the text box:
alert(“Hacked”)
Click Submit.
Figure 1.82 Screenshot of PLABWIN810: Entering a script in the text box on the XSS - Stored (Blog)
page.
Step 10
The server processes the script and displays the alert message box.
Click OK.
Figure 1.83 Screenshot of PLABWIN810: Showing the prompt as the output of the entered script.
Step 11
You are back on the XSS - Stored (Blog) Webpage. Notice that there is a second entry on the list,
but it is empty. The entered JavaScript gets reflected in the stored XSS section of the web page.
Unlike reflected XSS, stored XSS is permanent since the entered values are stored in the
application’s database.
Therefore, attackers could use this vulnerability to deface any website by displaying an image using
stored XSS, steal cookies of users, and so on.
Figure 1.84 Screenshot of PLABWIN810: Showing the entries in the list box.
Step 12
Click Bugs in the menu bar. The Portal homepage is now displayed. Once again, select Cross-Site
Scripting - Stored (Blog) from the Choose your bug drop-down and click Hack.
Figure 1.85 Screenshot of PLABWIN810: Selecting Cross-Site Scripting - Stored (Blog) and clicking
Hack.
Step 13
The stored XSS script that you used on this page is displayed back again automatically.
Click OK in the alert message box.
This is because the injected JavaScript is stored in the database, and it gets executed every time
you navigate to the stored XSS section.
However, in reflected XSS, this does not happen since the values are not stored in the application’s
database.
Figure 1.86 Screenshot of PLABWIN810: Showing the Hacked prompt on XSS - Stored (Blog) page.
Step 14
The XSS - Stored (Blog) Webpage is now displayed.
Figure 1.87 Screenshot of PLABWIN810: Showing the list of entries on the XSS - Stored (Blog)
page.
Keep the Internet Explorer window open.
Task 7 - Performing Directory Traversal Attack
Directory traversal allows attackers to access restricted directories and file on a Web server. It is
most commonly known as the path traversal attack. Through the directory traversal attack, the
attacker can bypass security implemented on the Web server and access directories and files that
are stored on the Web server even though they are outside the root directory of the Web server.
In most common scenarios, a Web server administrator would restrict users to the Web server’s
root directory, which holds the files for the Web application. The user will be restricted to navigate
outside this directory. The Web server administrator usually applies Access Control Lists (ACLs),
which define the access rights and privileges for the users to view, modify, and execute files.
To perform a directory traversal attack, perform the following steps:
Step 1
Ensure you have powered on all the devices listed in the introduction and connect to PLABWIN810.
Keep the bWAPP window open.
Figure 1.88 Screenshot of PLABWIN810: Showing the list of entries on the XSS - Stored (Blog)
page.
Step 2
Connect to PLABKALI01. Open Firefox if already not opened.
In the new tab, type the following string in the address bar:
http://pentest-tools.com/home
Press Enter.
Figure 1.89 Screenshot of PLABKALI01: Entering a URL in the address bar.
Step 3
In the menu bar, click Tools and then select URL Fuzzer under the WEB APPLICATION
TESTING category.
Figure 1.90 Screenshot of PLABKALI01: Clicking on the URL Fuzzer link on the Webpage.
Step 4
The URL Fuzzer Webpage is now loaded. In the search textbox, type the following URL:
http://testphp.vulnweb.com
Select I am authorized to scan this target, and I agree with the Terms of Service click FREE SCAN.
Note: The Light Scan option is selected by default and is free. Full Scan is a paid service.
Figure 1.91 Screenshot of PLABKALI01: Entering the URL in the search bar and clicking FREE SCAN.
Step 5
The scanning starts.
Figure 1.92 Screenshot of PLABKALI01: Showing the URL Fuzzer process running.
Step 6
After the scanning is complete, you need to scroll down to view the list of directories. Click /admin/.
Figure 1.93 Screenshot of PLABKALI01: Showing the discovered directories.
Step 7
Notice that there is a create.sql file stored.
Figure 1.94 Screenshot of PLABKALI01: Showing the create.sql file in the /admin/ directory.
Close the Firefox window.
Task 8 - Perform Web Application Brute Forcing Using DirBuster
There are several tools or Websites that you can use to traverse through a Website’s directory
structure. When you configure a Web server with a Website, it is best to ensure that you have not
enabled directory listing. If enabled, an attacker can exploit the Web server and get the listing. In
this task, you will learn to perform directory traversal using a multi-threaded tool named DirBuster,
which can brute force the Web applications to find their directory structure.
To perform Web application brute force using DirBuster, perform the following steps:
Step 1
Ensure you have powered on all the devices listed in the introduction and connect to PLABKALI01.
Click the Leadpad icon.
Figure 1.95 Screenshot of PLABKALI01: Showing the desktop of PLABKALI01 and clicking the
Leafpad icon.
Step 2
The *(Untitled) window is opened. Type the following words:
XSS
Cross-script
Attack
Evil
SQL
Injection
Figure 1.96 Screenshot of PLABKALI01: Creating a file in Leadpad with some text.
Step 3
Click File and select Save
Figure 1.97 Screenshot of PLABKALI01: Saving the file with the File ( Save option.
Step 4
The Save As dialog box is displayed.
From the left pane, select Desktop. In the Name text box, type the following name:
test
Click Save.
Figure 1.98 Screenshot of PLABKALI01: Naming the file as a test and saving on the Desktop.
Step 5
Notice that the file name is now changed to test. Close the Leafpad window.
Figure 1.99 Screenshot of PLABKALI01: Showing the test file and closing it.
Step 6
Click the Terminal icon.
Figure 1.100 Screenshot of PLABKALI01: Clicking the Terminal icon from the left pane on the
desktop.
Step 7
The terminal window is displayed. Type the following command:
dirbuster
Press Enter.
Figure 1.101 Screenshot of PLABKALI01: Entering the Dirbuster command in the terminal window.
Step 8
The OWASP DirBuster window is displayed.
Figure 1.102 Screenshot of PLABKALI01: Showing the OWASP DisBuster window.
Step 9
In the Target URL text box, type the following URL:
http://192.168.0.10/bWAPP
In the File with the list of dirs/files, type the following path:
/root/Desktop/test
Click Start.
Figure 1.103 Screenshot of PLABKALI01: Entering the URL and the path for the test file and clicking
Start.
Step 10
The scanning process starts.
Figure 1.104 Screenshot of PLABKALI01: Showing the scanning process.
Step 11
After the scanning process is completed, click Report.
Figure 1.105 Screenshot of PLABKALI01: Clicking the Report button.
Step 12
Click Browse.
Figure 1.106 PLABKALI01: Clicking the Browse button.
Step 13
In the Please Select The Location To Save The Report To dialog box, select Desktop and click Select
Directory.
Figure 1.107 Screenshot of PLABKALI01: Setting the path to save the report.
Step 14
Click Generate Report.
Figure 1.108 Screenshot of PLABKALI01: Clicking the Generate Report button.
Step 15
The DirBuster 1.0-RC1 Report View dialog box is displayed. Notice the list of all files and directories
that have been discovered.
Figure 1.109 Screenshot of PLABKALI01 Showing the discovered files and directories.
Close all open windows.
Prev
3 of 5
NextTopDone
Week Two ITPro.TV Lab
Hide Assignment Information
Instructions
Launch ITPro.TV (using the ITPro.TV (click here to launch) section) and complete the following virtual labs:
Virtual Labs >> CompTIA >> Pentest+ >> Exercise 1 Exploit Web Application Vulnerabilities
Task 2 - Perform Broken Authentication Attacks
Task 3 - Task 3 - View Session ID in URL
Task 4 - Conduct OS Command Injection Attack
Task 5 - Perform Server-side Includes Injection Attack (SSI)
Task 6 - Perform Cross-site Scripting Attack
Task 7 - Performing Directory Traversal Attack
Task 8 - Perform Web Application Brute Forcing Using DirBuster
Notes
Submission Requirements:
•
•
•
Screenshots demonstrating completion of the lab (Screenshot of your last step).
A 2 - 3 paragraph write up on the value and quality of the lab.
Submit a Word document with the screenshot and write up. Name the document "lastnamew2_ITPRO_lab.docx"
For instructions on accessing and troubleshooting ITPro.TV:
•
•
Accessing ITPro.TV Labs
Troubleshooting Lab and Video Issues
Submit Assignment
Files to submit
Purchase answer to see full
attachment