Web Attacks using DVWA

Dr. Waleed Bin Shahid

 DVWA-Introduction

• Damn Vulnerable Web Application (DVWA) is a PHP/MySQL web application that is

damn vulnerable
• Its main goal is to
• security professionals to test their skills and tools in a legal environment
• help web developers better understand the processes of securing web
applications
• Help academicians and researchers to learn about web application security in a
controlled environment
DVWA-Aim

• The aim of DVWA is to practice some of the most common web

vulnerabilities, with various levels of difficulty, with a simple
straightforward interface
• It can be cloned from: https://github.com/digininja/DVWA
• You will install it on your Linux machine which you have already set up in
this course.
• After cloning start the apache and MySql services on your Linux machine.
Post Installation
Brute Force Attack
• In this attack, an attacker configuring predetermined
values, making requests to a server using those
values, and then analyzing the response
• An attacker may use a dictionary attack (with or
without mutations) or a traditional brute-force attack
(with given classes of characters e.g.: alphanumeric,
special, case (in)sensitive)

• Helpful tools: Burp, Dirbuster

Bruteforce Attack (Low & Medium)

• Provide right username with

whatever password
Intercept in Burpsuite
Send to Intruder
Give Payload Options
Analyze Response
Command Injection Attack

• Command injection is a cyber attack that involves executing

arbitrary commands on a host operating system (OS).
Typically, the threat actor injects the commands by exploiting
an application vulnerability, such as insufficient input
validation

• For example, a threat actor can use insecure transmissions of

user data, such as cookies and forms, to inject a command
into the system shell on a web server
Command Injection Attack (Low Security)
Behavior is different for Windows and Linux
Exploiting Low
Security
Command
Injection (Medium
Security)

• && and ; symbols have

been sanitized
• Have to look for other
options
Exploiting Medium Security
A little better as compared to low mode
Command
Injection (
High
Security)
Exploiting High • See the Impossible one
Security
Cross Site Request Forgery Attack
• It is a web security vulnerability that allows an attacker to induce users to perform
actions that they do not intend to perform
• In a successful CSRF attack, the attacker causes the victim user to carry out an action
unintentionally
• For example, this might be to change the email address on their account, to change their
password, or to make a funds transfer.
• Depending on the nature of the action, the attacker might be able to gain full control
over the user's account
CSRF (Low Security)
 CSRF Low Security
• That’s how intercepted request looks like
• You can give this link to some and password will be changed:
http://192.168.0.106/DVWA/vulnerabilities/csrf/?password_new=ved&password_conf=ved&Change=Change
CSRF (Medium Security)
CSRF ( Medium
Security)
• Intercept in Burpsuite
• Send to Repeater
• Check with and Without Referer
• In Low mode, password will be changed even
if referer is removed
• A HTTP Referrer is a HTTP header field that
identifies the address of the webpage (i.e. the
URI or IRI) that linked to the resource being
requested. By checking the referrer, the new
webpage can see where the request
originated.
CSRF (High Security)
 CSRF (High Security)
It won’t let the request to be sent more than once
File Inclusion Attacks

• The File Inclusion vulnerability allows an attacker to include a file, usually exploiting a
“dynamic file inclusion” mechanisms implemented in the target application
• The vulnerability occurs due to the use of user-supplied input without proper
validation.
• This can lead to something as outputting the contents of the file, but depending on the
severity, it can also lead to:
• Code execution on the web server
• Code execution on the client-side such as JavaScript which can lead to other
attacks such as cross site scripting (XSS)
• Denial of Service (DoS)
• Sensitive Information Disclosure
File Inclusion
• In this mode it is just asking user to click on any file
Attack (Low • File inclusion can be local or remote
Security)
Local File Inclusion (Low Security)
Remote File Inclusion (Low Security)
 • In order to curb remote file inclusion http:// and https://
File Inclusion are blacklisted
(Medium Security) • ../ and ..\\ are blacklisted to curb local file inclusion
Remote File Inclusion Attack (Medium Security)
Local File Inclusion (Medium Security)
File Inclusion
• User input MUST contain the keyword ‘file’
Attack (High • Otherwise it would throw an error
Security)
File Inclusion
Attack (High
Security)
 SQL Injection Attack
(Basic Injection)

• On the User ID field, enter “1” and click

Submit
• It would print the ID, First_name, and
Surname on the screen
• You will see that the backend database
contains only five users
SQL Injection Attack (Basic
Injection)

• When you check the URL, you will see there is

an injectable parameter which is the ID.
• http://192.168.0.103/DVWA/vulnerabilities/sqli
/?id=3&Submit=Submit#
• The backend query looks like:
• SELECT first_name, last_name FROM users
WHERE user_id = '3';
 SQL Injection (contd..)

• Another way would be to write whatever' or

'1'=‘1 in the Username field as below to
reveal detail of all users
• In this case, the backend query looks like
this
• SELECT first_name, last_name FROM
users WHERE user_id = ‘ved' or '1'='1';
Getting the DB
Version

• To know the database version the DVWA

application is running on, the following
needs to be entered in the User ID field
• %' or 0=0 union select null,
version()--
Finding DB Details : • Capture the GET Request and save it in a txt
file
Step-1
Finding DB Details : • Run SQLMAP on the captured GET request to obtain DB
details
Step-2
Finding DB Details : • Obtain DB Tables
Step-3
Finding DB Details : • Finding Columns in Users Table
Step-4
Finding DB Details : • Obtaining username and passwords
Step-5 • Password hashes can be obtained.
 Blind SQL Injection Attacks

• Blind SQL injection is nearly identical to normal SQL Injection, the only difference being the
way the data is retrieved from the database.

• When the database does not output data to the web page, an attacker is forced to steal data
by asking the database a series of true or false questions

• This makes exploiting the SQL Injection vulnerability more difficult, but not impossible

• For instance, the URL: http://newspaper.com/items.php?id=2 sends the following query to

the database: SELECT title, description, body FROM items WHERE ID = 2
 Blind SQL Injection Attacks
• The attacker may then try to inject a query that returns ‘false’: http://newspaper.com/items.php?id=2 and
1=2

• Now the SQL query should look like this: SELECT title, description, body FROM items WHERE ID = 2 and 1=2

• If the web application is vulnerable to SQL Injection, then it probably will not return anything. To make sure,
the attacker will inject a query that will return ‘true’: http://newspaper.com/items.php?id=2 and 1=1

• If the content of the page that returns ‘true’ is different than that of the page that returns ‘false’, then the
attacker can distinguish when the executed query returns true or false

• Once this has been verified, the only limitations are privileges set up by the database administrator,
different SQL syntax, and the attacker’s imagination.
 B-SQLi
(Low
Security)
Session Management
• A web session is a sequence of network HTTP request and
response transactions associated with the same user
• Modern and complex web applications require the retaining of
information or status about each user for the duration of
multiple requests
• Therefore, sessions provide the ability to establish variables such
as access rights and localization settings which will apply to each
interaction a user has with the web application for the duration
of the session
• Web applications can create sessions to keep track of anonymous
users after the very first user request. For instance, user
language preference
• Additionally, web applications will make use of sessions once the
user has authenticated
..contd

• Once an authenticated session has been established, the session ID (or token) is
temporarily equivalent to the strongest authentication method used by the
application
• The session ID or token binds the user authentication credentials (in the form of a
user session) to the user HTTP traffic and the appropriate access controls enforced by
the web application
• The disclosure, capture, prediction, brute force, or fixation of the session ID will lead
to session hijacking attacks, where an attacker is able to fully impersonate a victim
user in the web application
Session ID Properties
• Session ID Name Fingerprinting: The session ID names used by the most common web application development frameworks can
be easily fingerprinted, such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET),
etc. It is recommended to change the default session ID name of the web development framework to a generic name, such as id.
• Session ID Length: The session ID must be long enough to prevent brute force attacks. It must be 128 bits long at least
• Session ID Entropy: The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able
to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good CSPRNG
(Cryptographically Secure Pseudorandom Number Generator) must be used
• Session ID Content: The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an
attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web
application. The session ID must simply be an identifier on the client side, and its value must never include sensitive information
(or PII).
• Session Management Implementation: The session management implementation defines the exchange mechanism that will be
used between the user and the web application to share and continuously exchange the session ID. Cookies
(RFCs 2109 & 2965 & 6265) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities
not available in other methods
Session ID Properties
• Built-in Session Management Implementations: Web development frameworks, such as J2EE, ASP .NET,
PHP, and others, provide their own session management features and associated implementation. It is
recommended to use these built-in frameworks versus building a home made one from scratch, as they are
used worldwide on multiple web environments and have been tested by the web application security and
development communities over time
• Used vs. Accepted Session ID Exchange Mechanisms: A web application should make use of cookies for
session ID exchange management. If a user submits a session ID through a different exchange mechanism,
such as a URL parameter, the web application should avoid accepting it as part of a defensive strategy to
stop session fixation
• Transport Layer Security: In order to protect the session ID exchange from active eavesdropping and passive
disclosure in the network traffic, it is essential to use an encrypted HTTPS (TLS) connection for the entire
web session, not only for the authentication process where the user credentials are exchanged
Exploiting Weak Session IDs
The Security Mode is LOW
Send to Sequencer
Start Live Capture
Poor Entropy for Session ID
 Exploiting Weak Session IDS: Medium Security

• Here the dvwaSession ID is

changing randomly

• dvwaSession=1672658145
• dvwaSession=1672658195
• dvwaSession=1672658211
• dvwaSession=1672658224
• dvwaSession=1672658235
Excellent Entropy: Hard Level
XSS Attacks
• Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are
injected into otherwise benign and trusted websites
• XSS attacks occur when an attacker uses a web application to send malicious code,
generally in the form of a browser side script, to a different end user
• An attacker can use XSS to send a malicious script to an unsuspecting user. The end
user’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
..contd
• Cross-Site Scripting (XSS) attacks occur when:
• Data enters a Web application through an untrusted source, most frequently a web
request.
• The data is included in dynamic content that is sent to a web user without being
validated for malicious content.

• Types of XSS
• Stored XSS Attack
• Reflected XSS Attack
• DOM Based XSS Attack
Stored XSS Attack

• Stored attacks are those where the injected script is

permanently stored on the target servers, such as in
a database, in a message forum, visitor log,
comment field, etc.
• The victim then retrieves the malicious script from
the server when it requests the stored information.
• Stored XSS is also sometimes referred to as
Persistent or Type-II XSS
..Contd
• Suppose a website allows users to submit comments on blog posts, which are displayed to other
users. Users submit comments using an HTTP request like the following:
POST /post/comment HTTP/1.1
Host: vulnerable-website.com
Content-Length: 100
postId=3&comment=This+post+was+extremely+helpful.&name=Carlos+Montoya&email=carlos%40normal-
user.net
• After this comment has been submitted, any user who visits the blog post will receive the
following within the application's response:
<p>This post was extremely helpful.</p>
• Assuming the application doesn't perform any other processing of the data, an attacker can
submit a malicious comment like this:
<script>/* Bad stuff here... */</script>
Exploiting XSS: Low • Copy the URL and open anywhere
Security
Exploiting XSS: Medium
Security
Backend Code Analysis

First block is for performing input sanitization on message field

strip_tags() function removes all html tags from the message field before storing them in database

htmlspecialchars() converts all the bad characters like &, ", ', > and < in their equivalent HTML
character encoding so they won’t remain in their original form when they reflect back in the browser

So, our XSS payload becomes useless. From here we conclude that the message field is completely
secure, and we cannot inject any XSS payload into it.
Backend Code Analysis

Second block is for performing input sanitization on Name field

str_replace(). Here this function is replacing all the occurrences of <script> tag
with null or blank character
We can use this field to inject our XSS payload

Since this field is replacing all occurrences of <script> tag so we cannot use any XSS
payload which contains <script> tag in it.
 Bypassing this Sanitization
• We can bypass this security by using some other
payloads which do not contain <script> tags in it and
we can use script tag with different casing enabled
• Like we can use <Script> or <scRiPt> or <ScRiPt> in
place of <script>.
• So, our new payload will be something like this
<SCRIPT>alert(“VED”)</SCRIPT>
• But the maximum length to be entered in the name
field is 10
• Since it is a client side restriction, we can modify it
in the page source to 100 and enter the payload
easily
Exploited
 • No change in the sanitization of the message block.
• Block 2 is for performing input sanitization on Name field. It
Exploiting Stored uses just one function for performing input sanitization.
XSS: High • The function is preg_replace(). Here this function replaces
every occurrences of <script> tag irrespective of their cases
Security with null or blank. So here every XSS payload which includes
<script> tag into it will be useless.
• To bypass this we have to use some other XSS payload which
does not contains <script> tag into it.
• There are many number of payloads available to bypass this
Exploiting S-XSS: High
Security

• Here we use the payload <img src=x

onerror=alert("Hacked")> with the event
handler onerror in the input field
Reflected XSS Attacks
• Reflected cross-site scripting (or XSS) arises when an application receives data in an HTTP request
and includes that data within the immediate response in an unsafe way.
• Suppose a website has a search function which receives the user-supplied search term in a URL
parameter
https://insecure-website.com/search?term=gift
• The application echoes the supplied search term in the response to this URL
<p>You searched for: gift</p>
• Assuming the application doesn't perform any other processing of the data, an attacker can
construct an attack like this:
https://insecure-website.com/search?term=<script>/*+Bad+stuff+here...+*/</script>
• This URL results in the following response:
<p>You searched for: <script>/* Bad stuff here... */</script></p>
The basic difference
• Reflected XSS arises when an
application takes some input
from an HTTP request and
embeds that input into the
immediate response in an
unsafe way
• With stored XSS, the
application instead stores
the input and embeds it into
a later response in an unsafe
way.
 R-XSS: Low
Security
• The 1st line contains the function
that will accept input from the user
• 2nd line reflects the input provided
by the user exactly in the same way
as it was entered in the input field
without performing any sanitization
or encoding.
Exploiting R-XSS: Low Security
Exploited
 • When the following URL is shared with the victim, the website
Share with Victim will reflect it back and he/she will get exploited
R-XSS: Medium
Level
• Here Line # 2 replaces all
occurrences of <script>
tag in the user input by
null
• Line # 3 reflects back the
input provided by the user
after performing filtering
in the above line
Exploiting Medium Here we would again go for
Security <SCRIPT>alert(“RXSS”)</SCRIPT>
R-XSS: High
Security Level
• Here line # 2 peplaces all occurrences
of <script> tag whether capital or
small or both mixed with null. So, the
<script> tag is useless.
 Exploiting R-XSS:
High Security
• To bypass it we can use some other HTML
tag with event handlers to print the alert box
on the screen
• Here we use the payload <img src=x
onerror=alert("Hacked")> with the event
handler onerror in the input field
DOM Based XSS Attack
• A DOM, or Document Object Model, acts as a translator between Javascript and
HTML. It’s not a different programming language but a built-in API for Javascript.
• A web page results from several programming languages, codes, and developers
working together. As a result, myriads of code lines, frameworks, APIs, and other
elements are required for a website to run smoothly and without performance
issues.
• The DOM is one such critical component that plays an intuitively integral part in
the dynamic functioning of web pages.
..contd
If HTML is the language responsible for the website’s foundation, Javascript is the language that
adds dynamic content to the website

Therefore, HTML and Javascript must work together to develop and manage a website

However, Javascript cannot understand HTML elements, which is where DOM comes for help.
The Document Object Model (DOM) turns illegible HTML and XML elements into objects,
making it easier for Javascript to comprehend and access the material
DOM plays a rather very important role in website performance
..contd
• For example, let’s say you are visiting a website and logging into your account
• After logging in, you will be greeted by the website, for example, ‘Hello <name>’ along
with your username, profile picture, etc.
• The changes to the website are solely for you. If you log out of your account, the website
will return to normal.
• This means the changes you made on the client-side of the website only appear on the
client-side, and no significant changes are made to the original website.
• if you change the theme of a particular website from light to dark, the changes for your
display alone, not for all users visiting the website.
Exploiting DOM-XSS:
Low Security
• In this DOM based XSS so our
first step should be to find
potential Source where we
can inject our XSS payload
• let us modify the value of
default parameter in the URL
with some unique string
attacked and check where
our input is reflected in HTML
DOM and how it is processed.
..contd
• Since our unique string is
reflected back in HTML
DOM so let us inject our
basic XSS payload
<script>alert('DOM
XSS')</script> in place of
hello in default parameter
..contd
• We can verify that after
successful execution, our
payload became the part
of HTML DOM.
Exploiting DOM
XSS: Medium
• Now, English value is
passing in the default
parameter in the URL.
• Input any unique string
like attacked into the
source i.e., inside default
parameter. We can see
our input string is
reflected in the HTML
DOM.
..contd
• We can bypass it by
breaking the DOM. For
this we can use </select>
html tag because <select>
tag is already opened.
After </select> tag we can
start new html tag.
• </select><svg
onload=alert('XSS')>
Exploiting DOM
High Security
• In this case the backend
code contains 4 allowed
or whitelisted languages
inside switch statement
• Moreover, if the input is
anything else then it will
redirect to the
location?default=English
..contd
• In this case we can use the
following script to bypass
the High Security
• English&</select><Svg
Onload=alert('XSS')>
File Upload Attacks
• File upload vulnerabilities are when a web server allows users to upload files to its filesystem
without sufficiently validating things like their name, type, contents, or size
• Failing to properly enforce restrictions on these could mean that even a basic image upload
function can be used to upload arbitrary and potentially dangerous files instead
• This could even include server-side script files that enable remote code execution
• In the worst case scenario, the file's type isn't validated properly, and the server configuration
allows certain types of file (such as .php and .jsp) to be executed as code
• If the filename isn't validated properly, this could allow an attacker to overwrite critical files
simply by uploading a file with the same name
• Failing to make sure that the size of the file falls within expected thresholds could also enable a
form of denial-of-service (DoS) attack, whereby the attacker fills the available disk space
Exploiting File Upload: Low Security
• Create a PHP Reverse Shell and save it in attack.php
Successful Uploading of Script
Exploiting File Upload: Medium Security
Rename to attack.php.jpg and press upload
..contd

After intercepting in Burp,

change it back to .jpeg
File Upload:
Medium
Level
Exploited
 File Upload: High Security
Add the header value of GIF98 before PHP code and save as exploit.jpeg
All uploads are
shown as below
• But the exploit.jpeg is not
executable
• We have to convert it.
• How?
Content Security Policy

• Content Security Policy (CSP) is an added layer of security that helps to detect and
mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data
injection attacks
• XSS attacks exploit the browser's trust in the content received from the server.
Malicious scripts are executed by the victim's browser because the browser trusts the
source of the content, even when it's not coming from where it seems to be coming
from
• CSP makes it possible for server administrators to reduce or eliminate the vectors by
which XSS can occur by specifying the domains that the browser should consider to
be valid sources of executable scripts
• A sample CSP Rule looks like this:
• default-src 'self'; img-src *; script-src https://www.Qalam.nust.edu.pk (self explanatory)
 • Scripts are only allowed from:
Exploiting CSP: • https://pastebin.com
• example.com

Low Security • code.jquery.com

• https://ssl.google-analytics.com ;
 • When we try to include google.com, it shows an error while inspecting
because it is not in the CSP. But its okay to include hatsebin website because
of its presence in the CSP
..contd • It can be exploited as both hastebin and Pastebin allow users to write their
own scripts