15.3 student guide web application tool time overviewtodays c

15.3 Student Guide: Web Application Tool Time
Overview
Today's class is the final part of our introduction to web
vulnerabilities. You will learn how to use tools to determine and
automate the discovery of vulnerabilities that exist within a web
application. The lesson will introduce web proxies and Burp
Suite. You will use Burp Suite to exploit broken authentication
vulnerabilities by conducting attacks such as session hijacking
and brute force attacks. Additionally, you will learn mitigation
methods used to protect against these exploits.
Class Objectives
· Identify ways in which web application security tools can
assist with testing security vulnerabilities.
· Configure Burp Suite and Foxy Proxy to capture and analyze
an HTTP request.
· Identify session management vulnerabilities using the Burp
Suite Repeater function.
· Conduct a brute force attack against a web application login
page with the Burp Intruder function.
Slideshow
· .
01. Introduction to Attacking Web Applications with Security
Tools
Recap of the concepts covered in the last class:
· Back-end component vulnerabilities are vulnerabilities that
exist within the back-end components of web application
servers.
· Back-end components apply the business logic, or how the
application works. They can include the following:
· Server content management and access control
· Back-end languages like PHP and Java
· Directory traversal is a web app back-end component
vulnerability in which an attacker accesses files and directories

from a web application outside a user's authorized permissions.
· In a directory traversal attack, attackers can modify the user
input, using a dot-slash method, to access unintended files in
other directories.
· Local file inclusion, or LFI, is another web app back-end
component vulnerability, in which an attacker tricks the
application into running unintended back-end code or scripts
that are LOCAL to the application's file system.
· An example of a back-end coding language that can be used is
PHP.
· LFI is typically conducted by an attacker uploading a
malicious script into the web app's LOCAL file system, using
the file upload functionality.
· After successfully completing the upload, the attacker can
arbitrarily execute command-line code with that script.
· Remotely executing command-line code is defined as remote
code execution.
· Remote file inclusion, or RFI, is a back-end component web
app vulnerability in which an attacker tricks the application into
running unintended back-end code or scripts—similar to LFI,
except that the scripts are REMOTE to the application's file
system.
· RFI is typically conducted by an attacker modifying the URL
to reference a REMOTE malicious script.
· After successfully referencing the script, the attacker can
arbitrarily execute command-line code with that script.
· Because the attacker can remotely execute command-line
code, this is also considered remote code execution.
· Directory traversal, LFI, and RFI all fall under the OWASP
risk broken access control.
· Per , broken access control is explained as follows:
· "Restrictions on what authenticated users are allowed to do are
often not properly enforced. Attackers can exploit these flaws to
access unauthorized functionality and/or data, such as access
other users’ accounts, view sensitive files, modify other users’
data, change access rights, etc."

Web Application Security Tools
In the last two classes, we have covered several different
vulnerabilities (SQL injection, XSS, directory traversal, LFI,
and RFI), as well as methods to exploit them.
· Note that we exploited each of these vulnerabilities by directly
interacting with the web application. For example:
· For SQL injection, we interacted with the web application by
inserting a malicious SQL script payload into an input field.
· For LFI, we interacted directly with the web application by
uploading a malicious PHP script.
While we successfully exploited these web app vulnerabilities
with direct interaction with the web application, sometimes
security professionals run into certain challenges during their
testing.
For example:
· The following image shows a recap of the SQL injection
attack that was demonstrated on the first day of this unit:
· This image represents where we used the always true payload
(jsmith OR '1' = '1) to conduct a SQL injection attack and
displayed all the contents from a database table.
Note that while we successfully conducted this SQL injection
attack on the first attempt, most security professionals have to
try many different payloads before determining which payl oad
works.
· For example, a security professional might have to try lots of
different types of payloads, such as the following:
· jsmith" or true--
· jsmith OR "1" = "1
· jsmith -- OR '1' = '1
· jsmith') or true--
The challenge is that it is very time-consuming and inefficient
for the security professional to manually enter one payload at a
time and examine each individual result.
· Fortunately, there are web application security tools that can
help you solve challenges like this.

Web application security tools can assist security professionals
by automating testing processes.
· Web application security tools can also assist with capturing,
displaying, and modifying web application requests and
responses.
· Certain web application security tools have built-in features
that are designed to test for certain web app vulnerabilities.
In today's lesson we will be introducing and demonstrating a
popular web application security tool that offers all three of the
preceding features: Burp Suite.
· Additionally, we will be demonstrating how Burp Suite can be
used to exploit vulnerabilities that fall under the OWASP risk
broken authentication.
· Broken authentication risks are risks that permit an attacker to
either view or bypass the authentication methods that are used
by a web application.
Class Overview
Today's class will cover how to use Burp to exploit two broken
authentication vulnerabilities. The class will proceed as
follows:
· We will begin with introducing Burp Suite and Foxy Proxy
and how to configure them to capture and analyze HTTP
requests and responses.
· Then we will learn how to use the Burp Repeater feature to
determine session hijacking vulnerabilities.
· Lastly, we will show how to use the Burp Intruder feature to
conduct an automated brute force attack.
⚠ IMPORTANT HEADS UP: ⚠
The techniques we will learn throughout this unit can be used to
cause serious damage to an organization's systems. This is
ILLEGAL when done without permission. All of the labs we
provide are safe locations to test the methods and tools taught
during the week.
NEVER apply any of these methods to any web applications you
do not own or do not have clear, written permission to be
interacting with.

Make sure to cover the daily objectives and answer any
questions before proceeding on to the first topic of the day.
02. Introduction to Web Proxies and Burp Suite (0:15)
In last week's class, we illustrated how the browser, using a web
application, interacts with the back-end web server by using
HTTP requests and responses.
· For example, let's say that a user wants to view a picture of a
car by clicking on a link on a website.
· A user's browser (the client) requests an image of a car to be
displayed with an HTTP request.
· The web server (the server) responds with that car image by
sending an HTTP response.
· The browser receives the HTTP response and renders the
image of the car to the user.
· The following image illustrates the HTTP request-response
cycle:
Behind the scenes in this process, HTML requests and responses
are constantly exchanged between the browser and the web
server.
· Note that security professionals often need to examine and
modify these raw HTML requests and responses to test for
security vulnerabilities.
Web Proxy
Security professionals can capture and view these requests and
responses by using a web proxy. Introduce web proxies by
covering the following:
· A web proxy is an intermediary between the client and the
server.
· In its simplest terms, internet traffic flows through the proxy
on the way to its intended destination.
· Web proxies can be used for the following scenarios:
· By organizations, to monitor and block harmful web traffic, as
some web proxies can be configured to block specific websites.
· By individuals, to provide themselves anonymity when using
the internet, as some web proxies can change the source IP

address.
· The following image show how the client's request for the car
image and the server returning the car image flows through the
proxy:
· Some web proxy tools can also intercept and hold the requests
or responses before passing them along to their destination.
· Security professionals use this intercept functionality to
analyze or modify the raw HTTP requests and responses.
· The security tool that we will be using in the class, which has
this intercept functionality, is called Burp Suite.
Burp Suite
Burp Suite is a web application security tool that lies between
your browser and your target application.
· Burp Suite intercepts raw HTTP traffic from the browser or
the server.
· This means that it functions as a web proxy.
· Burp offers many additional features and capabilities to allow
a security professional to analyze, modify, and automate the
HTTP traffic before passing it along to its final destination.
· We can only cover a few of its many features in class.
· If you want to learn about all of Burp's features, refer to the
following resource: .
· In this lesson, we will be using the free version of Burp Suite,
called the Burp Suite Community Edition.
· There are paid versions, Burp Suite Pro and Burp Enterprises,
that offer many additional features that we will not use in this
class.
Burp Demonstration
In the next demonstration, we will complete the following steps
to configure Burp to capture and inspect a simple HTTP request.
1. Start and access Burp Suite.
2. Navigate Burp Suite.
3. Configure the proxy on Burp Suite.
4. Configure Foxy Proxy on your browser.
5. Enable Foxy Proxy to send traffic to Burp Suite.

6. View the captured traffic on Burp Suite.
Part 1: Launch and Access Burp Suite
1. We will begin by launching and accessing Burp Suite.
· Open a terminal within Vagrant and run the command sudo
burpsuite, then press Enter.
· This will open the Burp Suite application:
2. On the first page of Burp Suite, select Temporary project
from the list of options. Select Next on the bottom right of the
page.
· ⚠ If you encounter any pop-ups about updating Burp Suite,
DO NOT update. Cancel the pop-up.
3. On the second page, select Use Burp defaults from the list of
options. Select Start Burp on the bottom right of the page.
· Do not select any other options on this page:
· The Burp Suite Dashboard will appear once you have
successfully accessed Burp Suite.
· The following image illustrates the page that should be
displayed:
Part 2: Navigate Burp Suite
4. Now we will navigate the Burp interface to access Burp
features.
· We are currently on the Burp Suite Dashboard.
· � Note that features on the Burp Suite Dashboard are outside
the scope of the class, but if students want to learn about them,
you can send them the following link: .
· We will use the following three features, which you will find
to the right of the Dashboard tab:
· Proxy
· Intruder
· Repeater
· These features contain their own tabs as well. For example,

Proxy contains the following sub-options:
· Intercept
· HTTP history
· WebSockets history
· Options
· In the demonstrations and activities, you will be accessing
several sub-options.
Part 3: Configure the Proxy on Burp Suite
5. We will now navigate the various features within Burp. Let's
begin by configuring the proxy to capture a HTTP request.
· Select the Proxy tab from the tool bar at the top of the Burp
window.
· When you open the Proxy feature, you will be taken to the
default sub-option Intercept.
· On this page, confirm that Intercept is on. You should see a
gray button that reads Intercept is on:
· Note that when Intercept is on, the traffic will be captured and
held.
· When Intercept is off, the traffic will flow right through to its
destination.
· If the button says Intercept is off, click the button to turn it
back on.
6. Under Proxy, select the Options tab.
· Under Proxy Listeners, confirm that you have the interface
127.0.0.1:8080 set up, with the Running option checked.
· The following image illustrates how the listener should be set
up.
· Note that this is the default proxy setup in Burp.
· This means that Burp will listen for traffic directed to the
following:
· IP: 127.0.0.1 (your localhost)
· Port: 8080
Part 4: Set Up the Proxy on Firefox

7. Now that the proxy is configured to listen for web traffic, we
need to configure the browser to send the traffic to this IP and
port.
· Begin by opening the Firefox browser. You can open Firefox
from the Vagrant menu or type "firefox" in your terminal.
· Next we need to add a free add-on browser feature called Foxy
Proxy.
· In your browser, search for "Foxy Proxy":
· It should be the first result listed in a Google search. Select
that option, which should take you to a page like the one shown
in the following image:
· Select Add to Firefox.
· If a pop-up appears on the top of your screen, select Add to
proceed.
· Once you have added it, you will see the Foxy Proxy icon in
the top-right corner of your browser:
8. Let's configure Foxy Proxy to send the web traffic to Burp
Suite.
· Click on and open the Foxy Proxy add-on.
· Within the Foxy Proxy window that opens, select Options.
· This will take you to a page where you can create the various
proxy options to send your traffic to.
· Select Add on the top left, to go to the Add Proxy page.
· Under Title, enter "Burp".
· On the right, update the following fields to match what we
configured in Burp:
· Proxy Type: HTTP
· Proxy IP address or DNS name: 127.0.0.1
· Port: 8080
· Leave the rest of the fields blank.
· Select Save on the bottom right to save your proxy:

· After selecting Save, you should now see your new Burp proxy
option listed on the Options page:
· Burp is not yet enabled.
Part 5: Capture Proxy Traffic from Your Browser
9. Now that we have configured the proxy settings on Burp and
Foxy Proxy, let's capture the first HTTP traffic request!
· Open a new tab on your browser. The webpage will look
something like the following image:
· Click the Foxy Proxy icon and select the proxy that you just
configured: Burp/Burp Suite.
· A check mark will appear to the left of that option once you
have selected it. This green icon indicates that all future traffic
will be forwarded to Burp Suite!
10. Let's send the first HTTP request to Burp.
· From the webpage, enter the URL "www.example.com" and
press Enter.
· Notice how, after you enter the URL, the screen turns blank
and the page appears to be spinning.
· The bottom of the webpage states, Waiting for ...
· This indicates that the HTTP request has been sent to Burp
and the browser is awaiting a response:
· Burp has intercepted and hung on to the HTTP request!
Part 6: View the Captured Traffic from Burp Suite
11. Return to Burp Suite and find the intercepted traffic.
· Select Proxy on the primary tool bar.
· Within Proxy, select Intercept.
· Your captured HTTP request will appear:
· Look at the Host line of your HTTP request.
· Important: It is very likely that your Firefox browser sends
requests looking for WiFi networks to log into. You will notice

this if the HTTP traffic you see shows the host as
detectportal.firefox.com.
· To prevent Burp from capturing these requests, right-click on
the HTTP traffic and select Don't intercept requests > To this
host.
· This will prevent Burp from capturing future requests.
· You may have many of these captured detectportal requests.
To remove them you can do one of the following:
· Continue to select Drop from the Intercept page until the host
of your HTTP traffic is www.example.com.
· Alternatively, toggle the Intercept is on button to Intercept is
off, then back to Intercept is on again. This will clear all the
captured requests.
· Note that with this method, you will need to return to the
browser and re-enter "example.com" in the URL to create a new
capture.
· You have successfully captured the HTTP traffic request when
the HTTP traffic shows the following:
· GET / HTTP/1.1
· Host: www.example.com
· User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64;
rv:68.0) Gecko/20100101 Firefox/68.0
· Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/ *;q=0.
8
· Accept-Language: en-US,en;q=0.5
· Accept-Encoding: gzip, deflate
· Connection: close
Upgrade-Insecure-Requests: 1
· Note that this is the raw HTTP GET request that your browser
sent to request example.com.
· Additionally, note that what has happened is that Burp has
captured and held this HTTP request before it is forwarded to
the host, .

· This is why the loading bar on the browser tab is still
spinning.
12. Now we will let go of the hold and forward this HTTP
request to the host.
· Select the forward option to forward the HTTP request to .
· Return to the browser and note that we can now see that the
response was returned, as the correct webpage has been
displayed:
13. Finally, it is good practice to disable your Burp Suite Foxy
Proxy setting when you are done capturing traffic.
· To disable the setting, click on the Foxy Proxy icon again and
select Turn Off.
Demonstration Summary
The walkthrough we just completed illustrated the steps that a
security professional would take to capture and view raw HTTP
traffic using Foxy Proxy and Burp Suite.
03. Configuring Burp Suite Activity
·
04. Session Management Vulnerabilities
Recap:
· Security professionals use web application security tools to
assist with analyzing and automating web application securi ty
tests.
· Burp Suite is a popular web application security tool that has a
functionality called a web proxy.
· A web proxy is an intermediary through which traffic flows
between the client and the server.
· A web proxy can intercept web traffic, so that security
professionals can analyze or modify it.
· In addition to the web proxy intercept functionality, Burp
Suite offers many custom features designed for testing security
vulnerabilities.
In this next section, we will learn how to use a Burp Suite
feature called Repeater to test for session management
vulnerabilities.

Before we start using Burp Suite, we will revisit how
applications use cookies to manage a user's session.
Cookies and Session Management
Remember that last week we covered the following:
· HTTP resources are inherently stateless, meaning that
whenever your browser requests a webpage, there is no way for
that webpage to distinguish you from anyone else.
· Websites need a way to deliver content that is specific to each
user. To do so, they establish sessions, using cookies.
· Sessions are unique server-side sets of user data used to
specify the webpages being accessed and the content displayed
on them, for the specific user accessing them.
· Cookies are small pieces of text data that, when sent by an
HTTP server's response header, are saved by the user's HTTP
client.
· After a user authenticates into a secure website, the web
server issues the user a unique session cookie, so that the
information displayed is specific just to that user.
· For example, if a user logs in with their correct username and
password to an online banking website, they will receive their
own unique session cookie, providing them with all their private
account information (accounts, balances, transactions) when
they navigate within the online banking application.
· When the user logs out, or after a period of inactivity, the
session cookie should expire.
The intended purpose of session cookies is to maintain a state
between webpages when a user accesses a web application.
Session Hijacking
After a user authenticates into a web application, the data that is
displayed is specific and private to the user accessing the
application.
Note that if a malicious user can obtain another user's unique
session cookie, the malicious user could hijack the victim's
private session.
· This unintended attack method is defined as session hijacking.
· Note that in last week's lesson, we conducted a session

hijacking attack when we used the Chrome browser extension
Cookie-Editor to swap sessions.
· Session hijacking attacks exploit session management
vulnerability.
· It falls under the OWASP Top 10 risk of broken authentication
because if an attacker has access to a user's session, they can
bypass the application's authentication measures.
Session hijacking can be conducted by several methods:
· Sniffing traffic: If a malicious user can sniff encrypted traffic,
then they can potentially capture the session cookie and take
over a victim's session.
· Client-side attacks: A malicious user can deploy a cross-site
scripting attack to steal a user's session cookie.
· Predictable sessions: A malicious user can predict what a
unique session cookie might be.
Session Hijacking with Predictable Sessions Scenario
The following scenario explains how an attacker could use the
predictable sessions method of session hijacking.
· Henry, a malicious user, is using a stock-trading website to
buy and sell stocks and mutual funds.
· Henry logs in with his own credentials on Monday, February
9th, 2021, to the stock-trading site, then views his session
cookie in his browser settings: 020921MON-1454.
· He logs out and immediately logs back in again with his own
credentials, then checks his session cookie again: 020921MON-
1455.
· Henry logs in the following day, Tuesday, February 10th,
2021, and his session cookie is now 021021TUE-3834.
· Henry can look at these session cookies that are generated and
determine that the algorithm used by the stock trading site
likely comprises the following:
· The six-digit numerical date
· The three-letter day of the week
· A four-digit number that increments
· By figuring out the algorithm, Henry can try and guess another

user's session cookie, then hijack another user's session.
· For example, on Wednesday, Henry can manually update his
session cookie using the Chrome Cookie-Editor, until he
manages to hijack another user's session:
· Henry might first try 021121WED-1111.
· If that doesn't work, he might next try 021121WED-1112.
· If that doesn't work, he can keep trying.
· Note that with this method, the victim that Henry is attacking
is usually random, as the attacker likely does not know who is
accessing the application at what time.
· Eventually, after many tries, Henry tries a session cookie of
021121WED-1187, and then he ends up inside the stock-trading
account of another user, Julie Jones.
· Henry can now view Julie's private stock information and even
potentially sell her stocks without her permission.
Scenario Summary
· In this scenario, the session management vulnerability was
that the session cookie was predictable, as Henry was able to
predict the session cookie of another user, Julie Jones.
· Henry exploited the vulnerability by conducting a session
hijacking attack, using the predicted session cookie of
021121WED-1187 to hijack Julie Jones's private session.
· Lastly, note that in this scenario, Henry had to log out and log
back in again to determine the pattern of the session cookies.
· Note that this manual process can be time-consuming and
inefficient.
05. Analyzing Session Management Vulnerabilities with Burp
Repeater
We just covered the following:
· How session cookies are intended to maintain a private session
within a web application.
· That an unintended session management vulnerability exists if
an attacker can obtain or determine the session cookie, as the
attacker could hijack the user's private session.

· There are several methods that an attacker can use to obtain or
determine the session cookie: sniffing traffic, client-side
attacks, and predictable sessions.
· With the predictable sessions method, if an attacker can
determine the algorithm being used to create session cookies,
they can use the algorithm to predict future session cookies and
hijack another user's private session.
Note that in the scenario, we illustrated how Henry used an
inefficient method of logging out and back in each time to view
his session cookies and determine the algorithm.
· Burp Suite has a feature called the Repeater that can simplify
this process.
· We will now demonstrate how we can determine an algorithm
used for generating session cookies, by using the Burp Repeater
feature.
Burp Repeater Demonstration Setup
In this demonstration, we will continue to work on the
Replicants web application.
Specifically, we will conduct this demonstration by completing
the following four steps:
· Access the session cookie generator and enable proxy settings.
· Generate and view the session cookie.
· Move the HTTP request to Burp Repeater.
· Use Burp Repeater to view the HTTP response.
Part 1: Access the Session Cookie Generator and Enable Proxy
Settings
1. To access the Replicants website within Vagrant, access the
following page: .
· We will select the Weak Session IDs option from the menu on
the left side of the page.
· Alternatively, access the webpage directly by accessing this
page: .
· Note: If you have any issues accessing this webpage, you
might need to repeat the Activity Setup steps from the
06_SQL_Injection activity from 15.1.
· The page will look like the following image:

· Note that while this webpage is technically part of the
Replicants website, it is designed to simulate the session ID that
is created each time a different user logs into the application.
· View how it works by clicking the Generate button.
· While it looks like nothing happened, an HTTP request for a
new session cookie is made behind the scenes.
· The page states, "This page will set a new cookie called
dvwaSession each time the button is clicked."
· We will be viewing this new dvwaSession cookie shortly.
2. Next, to enable the Burp proxy, repeat the same steps we
completed in the previous activity:
· On your browser, enable the Burp selection from Foxy Proxy.
· From Burp Suite, under Proxy > Intercept, confirm that
Intercept is on.
· Now we are ready to capture this new request!
Part 2: Generate and View the Session Cookie
3. We will now capture the HTTP request that is generated when
we click the button.
· Click the Generate button again.
· Note that the loading bar on the browser tab should be
spinning:
· This means that the HTTP request has been intercepted by
Burp, and the browser is waiting on the response.
4. Now we'll return to Burp Suite to view this intercepted HTTP
request.
· Under Proxy > Intercept, we should see an HTTP POST
request that looks similar to the following image:
POST /vulnerabilities/weak_id/ HTTP/1.1
Host: 192.168.13.25
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64;
rv:68.0) Gecko/20100101 Firefox/68.0
Accept:

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.
8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Connection: close
Referer: http://192.168.13.25/vulnerabilities/weak_id/
Cookie: PHPSESSID=kk3k2ir7hf156ultvtetcv7br4;
security=low
Upgrade-Insecure-Requests: 1
· This is a raw HTTP POST request that gets generated and sent
to the web server after we select the Generate option.
· Similar to the previous activity, because Intercept is ON, this
request is being held and has not yet reached the destination
web server.
· We're now ready to send this to the Burp Repeater feature, to
assist with analyzing the responses.
Part 3: Move the HTTP Request to Burp Repeater
5. Send this request to the Repeater tool by completing the
following steps:
· Right-click on the Intercept page and select Send to Repeater
(or press CTRL+R):
· Note that now the Repeater icon color on your tool bar has
changed from black to orange.
· This indicates that the HTTP request has been sent to
Repeater.
· Click on the Repeater icon from your tool bar to view this
HTTP request.
· Note that this should display the same HTTP POST request
that you …

15.3 student guide web application tool time overviewtodays c

15.3 student guide web application tool time overviewtodays c

More Related Content

What's hot (20)

Similar to 15.3 student guide web application tool time overviewtodays c (20)

More from UMAR48665 (20)

Recently uploaded (20)

15.3 student guide web application tool time overviewtodays c