Vulnerability Assessment

Summary Report

Report Prepared by:

Yash Sanjay Ghogare
A/P : Satapewadi , Tal – Walwa
Dist – Sangli , Maharashtra

17th September 2023

Table of Contents
Summary -------------------------------------------------------------------------------- 3
1.Total Number of vulnerability ------------------------------------------------------ 4
2.Description of the vulnerability and solutions --------------------------------- 5

Summary
It has been observed That the URL http://testphp.vulnweb.com/ has some
Vulnerability which are categorised as risk low, risk medium, risk high, risk
critical. Reflected cross-site scripting vulnerabilities arise when data is copied
from a request and echoed into the application's immediate response in an
unsafe way. An attacker can use the vulnerability to construct a request that, if
issued by another application user, will cause JavaScript code supplied by the
attacker to execute within the user's browser in the context of that user's
session with the application. The attacker-supplied code can perform a wide
variety of actions, such as stealing the victim's session token or login
credentials, performing arbitrary actions on the victim's behalf, and logging
their keystrokes. Users can be induced to issue the attacker's crafted request in
various ways. For example, the attacker can send a victim a link containing a
malicious URL in an email or instant message. They can submit the link to
popular web sites that allow content authoring, for example in blog comments.
And they can create an innocuous looking web site that causes anyone viewing
it to make arbitrary cross-domain requests to the vulnerable application (using
either the GET or the POST method). The security impact of cross-site scripting
vulnerabilities is dependent upon the nature of the vulnerable application, the
kinds of data and functionality that it contains, and the other applications that
belong to the same domain and organization. If the application is used only to
display non-sensitive public content, with no authentication or access control
functionality, then a cross-site scripting flaw may be considered low risk.
However, if the same application resides on a domain that can access cookies
for other more security-critical applications, then the vulnerability could be
used to attack those other applications, and so may be considered high risk.
Similarly, if the organization that owns the application is a likely target for
phishing attacks, then the vulnerability could be leveraged to lend credibility to
such attacks, by injecting Trojan functionality into the vulnerable application
and exploiting users' trust in the organization in order to capture credentials for
other applications that it owns. In many kinds of application, such as those
providing online banking functionality, cross-site scripting should always be
considered high risk.

Total number of risks:

There are total 36 Vulnerability. Among them 2 are at low risk
, 14 are at medium risk , 12 are at high risk , and 8 are at
critical risk.
You should review the contents of the information being
transmitted to other domains, and also determine whether
those domains are fully trusted by the originating application.
Today's browsers may withhold the Referer header in some
situations (for example, when loading a non-HTTPS resource
from a page that was loaded over HTTPS, or when a Refresh
directive is issued), but this behavior should not be relied
upon to protect the originating URL from disclosure. Note
also that if users can author content within the application
then an attacker may be able to inject links referring to a
domain they control in order to capture data from URLs used
within the application.

Description of the vulnerability:

Low risk Vulnerability –
1. The X-Frame-Options header is missing
The lack of the X-Frame-Options header in the response
from the Web application server, makes it possible to
hijack on the user's click, where through a malicious
indexing of a page on an attacker's website, it could
allow the hiding of this domain through an overlay,
causing involuntary actions performed by a victim in the
background. This type of exploit could make other
security vulnerabilities even more serious, such as
turning a self-XSS into a reflected one. Self-XSS occurs
when a certain user input field is not properly filtered,
this type of exploitation that, in theory, would only
happen on the attacker's computer and would have to
require a lot of interaction from the victim to happen, in
addition to just clicking or visiting the page as in other
cases, however, the user click hijacking ends up hiding
from the victim's eyes what he actually ends up doing,
this exploration can end up triggering what would simply
be a self-XSS without any security impact, for a
conventional one, such as the reflected one.

2. Parameter seems vulnerable to XSS at url

http://testphp.vulnweb.com/listproducts.php?cat=%2F
%2Fgoogle.com%2F The injection type is BUILTIN and
evidences: . Reference: Found dalfox-error-mysql via
built-in grepping / payload: toOpenRedirecting
Cross-Site Scripting (XSS) is a vulnerability that occurs
when a web application allows untrusted data to be
included in a web page without proper validation. XSS
vulnerabilities in a URL can occur when a web
application takes user-supplied input, such as data from
a URL parameter, and includes it in a web page without
proper encoding or validation. When an XSS
vulnerability exists in a URL, an attacker can craft a
malicious URL that includes malicious JavaScript code,
which will be executed when the URL is visited by a user.
This can allow the attacker to steal sensitive information,
such as passwords and session tokens, or to perform
actions on behalf of the user, such as posting malicious
content.

Medium risk Vulnerability –

1. X-XSS-Protection header is missing

The X-XSS-Protection header is missing, which could

make it easier to Cross-site scripting (XSS) exploration,
as on the reviewed site, does not have any filter that
could prevent exploitation of this security hole. XSS
vulnerability happens due to a parameter that is not
well filtered and ends up reflecting entirely everything
that is typed by the user via the URL, including HTML
tags and JavaScript codes. If successfully exploited this
vulnerability could allow that an attacker could craft a
fake page within the sitetrue what would bring about
 a legitimacy in the coup. Furthermore, as this is a flaw
in the site, mechanisms for third party protection
would be ineffective. If the user's session is shared
with other subdomains and the victim is logged in the
moment they click the malicious link, an attacker who
injected malicious code could capture the victim's
session without having to collect passwords and
would have the same access privileges as that user.
This situation becomes even more serious if a certain
session captured for some administrative access,
which could cause the elevation of an attacker's
privileges or the exploitation of otherssecurity flaws.

2. X-Content-Type-Options header is missing

Failure to use X-Content-Type-Options header could
allow an attacker to spoof a certain type of file that
would be analyzed through MIME type detection,
which could confuse the browser from its actual
validation, where it would lead to the execution of
othervulnerabilities such as Cross-site scripting. When
a file does not have enough information to determine
its origin, such as the presence of metadata, browsers
determine the extension of that file, from its contents.
This type of behavior can become a security risk,if the
browser misinterprets a given file in some form of
uploading files, for example, a JPEG file could have
been misinterpreted, if the content of your file existed
HTML tags and Javascript codes, instead of the
browser treating this extension as a corrupted image,
 would execute the codes typed by the user or in a
malicious wayby falsifying a victim's request, after
clicking a fake link or visiting a website controlled by
an attacker.

3. The domain http://testphp.vulnweb.com may be

vulnerable to email spoofing.
Email spoofing is the creation of email messages with
a forged sender address. The term applies to email
purporting to be from an address which is not actually
the sender's; mail sent in reply to that address may
bounce or be delivered to an unrelated party whose
identity has been faked. Assistant: ['Found SPF
record:', 'v=spf1 -all', 'SPF record contains an All item:
-all', 'No DMARC record found. Looking for
organizational record', 'No organizational DMARC
record']
Solution
Set up DMARC, DKIM, and SPF for email security.
DMARC requires creating a record in your domain's
DNS, detailing report address and message failure
policy. DKIM involves generating a public/private key
pair, publishing the public key in DNS as a TXT record,
and configuring your email server to sign messages
with the private key. SPF requires creating a DNS
record that lists authorized email servers for your
domain. Setup can vary with different email server
software and hosting providers; check your specific
setup's documentation.
4. The directory
http://testphp.vulnweb.com/Mod_Rewrite_Shop/ima
ges/ is listing the contents of the folder
open_directory

Web application listing files and directories can

present several safety hazards. Here are a few
examples: Sensitive information disclosure: When a
web application allows directory listing, it may reveal
sensitive information such as file names, directory
structure, and even the content of files. This could
include sensitive data such as configuration files,
backups, and logs that contain sensitive information.
Vulnerable files and directories: When a web
application allows directory listing, it may reveal the
presence of files and directories that are known to be
vulnerable to attack. This could include old,
unpatched versions of software, or files that have
weak permissions. Attack surface: When a web
application allows directory listing, it increases the
attack surface of the application. Attackers can use the
information revealed through directory listing to
identify and exploit vulnerabilities in the application.
Phishing: Attackers can create a fake website to mimic
the real one, and use the information from the listing
directory to make it more convincing.
Solution
There are several ways to prevent directory listing in a
web service: Use a .htaccess file: This file can be used
 to configure Apache web server settings. By adding
the following line to the .htaccess file, directory listing
will be disabled: Options -Indexes Use web server's
configuration: Some web servers such as Apache have
a global configuration file where you can set the
options for directory listing. You can disable directory
listing for the entire server by adding the following
line to the configuration file: Options -Indexes Use a
default index file: By default, most web servers will
display the content of a directory if there is no index
file present. You can prevent directory listing by
creating an index file such as index.html or index.php
in every directory. Use a web application firewall:
Some web application firewall has the capability to
detect and block directory listing attempts. It's
recommended to use more than one method to
prevent directory listing, since it can add an extra
layer of security.

5.The directory
http://testphp.vulnweb.com/Mod_Rewrite_Shop/.htacc
ess is listing the contents of the folder
Web application listing files and directories can present
several safety hazards. Here are a few examples:
Sensitive information disclosure: When a web
application allows directory listing, it may reveal
sensitive information such as file names, directory
structure, and even the content of files. This could
include sensitive data such as configuration files,
backups, and logs that contain sensitive information.
Vulnerable files and directories: When a web application
allows directory listing, it may reveal the presence of
files and directories that are known to be vulnerable to
attack. This could include old, unpatched versions of
software, or files that have weak permissions. Attack
surface: When a web application allows directory listing,
it increases the attack surface of the application.
Attackers can use the information revealed through
directory listing to identify and exploit vulnerabilities in
the application. Phishing: Attackers can create a fake
website to mimic the real one, and use the information
from the listing directory to make it more convincing.
Solution
There are several ways to prevent directory listing in a
web service: Use a .htaccess file: This file can be used to
configure Apache web server settings. By adding the
following line to the .htaccess file, directory listing will
be disabled: Options -Indexes Use web server's
configuration: Some web servers such as Apache have a
global configuration file where you can set the options
for directory listing. You can disable directory listing for
the entire server by adding the following line to the
configuration file: Options -Indexes Use a default index
file: By default, most web servers will display the content
of a directory if there is no index file present. You can
prevent directory listing by creating an index file such as
index.html or index.php in every directory. Use a web
application firewall: Some web application firewall has
the capability to detect and block directory listing
attempts. It's recommended to use more than one
method to prevent directory listing, since it can add an
extra layer of security.
Like wise are all other 9 medium risks.