Vulnerability assessment and attack Plan report

Prepared By: Rohit Roy

Report Date: 29/05/2024 Task Level:

Hard

Table of contents

1. Introduction:

1• Purpose of the Assessment

2• Objectives

3.• Scope

4.• Methodology

2. Attack Initiation: - Reconnaissance

• -Tools Used
•-Findings

- Scanning
• Tools Used
• Scan Results

− Vulnerability Assessment
• Tools Used
• Scan Results

- Exploitation Techniques Used

• Exploited Vulnerabilities
 3.Conclusion:

• Summary of Findings
• Recommendations

Introduction:
The objective of this report is to conduct a vulnerability assessment on the website
http://testphp.vulnweb.com/ and outline an attack plan to demonstrate potential security risks.
The assessment will involve identifying and analyzing vulnerabilities within the website's
structure, functionalities, and configurations.

Purpose:
I want to find vulnerabilities in http://testphp.vulnweb.com/ to help make it more secure and
protect it from cyber threats
Methodology :

Information Gathering

Identifying the web server technology and version.

Enumerating the website's directories and files.

Planning

Prioritizing potential attack vectors based on their severity and impact.

Selecting appropriate tools and techniques for each attack.

– Defining the scope and objectives of the assessment.

Vulnerability Assessment Penetration testing

- Findings vulnerabilities
- Exploting vulnerability
 Analysis and Recommendations
- Documentation of vulnerabilities exploited and their potential impact. - Recommendations for
remediation, including patching vulnerable code, implementing input validation, and conducting
regular security assessments. - Suggestions for improving the overall security posture of the
website

(Information Gathering):

Target Website Information

Link: http://testphp.vulnweb.com/

IpAddress: 44.228.249.3

(Tools Used)

Maltego (information-gathering tool)

Sites Used : www.who.is (information gathering site )

https://sitereport.netcraft.com/?url=http://testphp.vulnweb.com

information-gathering
 Results Hostname Type TTL
Testphp.vulnweb.com SOA 1800

Content
ns1.eurodns.com [email protected] 2021110100 86400 7200 604800 86400
Registar :
Eurodns S.A. EuroDNS S.A
IANA ID: 1052
URL: http://www.eurodns.com.http://www.EuroDNS.com Whois
Server: whois.eurodns.com

[email protected]
(p) +352.27220150

Domain Name: VULNWEB.COM

Registry Domain ID: D16000066-COM

Registrant Name: Acunetix Acunetix

Registrant Organization: Acunetix Ltd

Registrant Street: 3rd Floor,, J&C Building, Road Tow

Registrant City: Tortola Registrant Country: VG Registrant Phone: +1.23456789

Registrant Email: [email protected]

Registry Admin ID: Admin Name: Acunetix Acunetix

Admin Organization: Acunetix Ltd

Admin Street: 3rd Floor,, J&C Building, Road Town

Admin City: Tortola Admin Country: VG

 Admin Phone:+1.23456789

Admin Email: [email protected]

• IpAddress : 44.228.249.3

Tools Used
• Nmap(port scanning)

• Legion (scanning )
• Dirb (directory finder)

Scan Results
Command Used: nmap -sT -sV –O testphp.vulnweb.com

• Port : 80 Open

• Service: http

• Version: nginx 1.19.0

(Command Used dirb http://testphp.vulnweb.com )

Directories Found:

http://testphp.vulnweb.com/

http://testphp.vulnweb.com/admin/

http://testphp.vulnweb.com/CVS/

http://testphp.vulnweb.com/inages/

http://testphp.vulnweb.com/pictures/

http://testphp.vulnweb.com/secured/

http://testphp.vulnweb.com/vendor/

http://testphp.vulnweb.com/CVS/Entries

Vulnerability Assessment

1.Cross-Site Scripting (Self) ------------------------------------------------------

2. Flash cross-domain policy ---------------------------------------------------
3. Unencrypted communications -----------------------------------------------
4. Cross-domain Referrer leakage ---------------------------------------------
5. Frameable response (potential Clickjacking) --------------------------
6. Email addresses disclosed --------------------------------------------------
7. Blind SQL ----------------------------------------------------------------------------
8.LFI (Local File Inclusion) ------------------------------------------------------
9. Description and Risk Rating -------------------------------------------------
About B2B Testers -------------------------------------------------------------------

• Link: http://testphp.vulnweb.com/

• IpAddress: 44.228.249.3
Tools Used

• Owasp Zap (vulnerability scanner)

Risk levels

Included: High, Medium, Low, Informational

Excluded: None

Confidence levels

Included: User Confirmed, High, Medium, Low

Excluded: User Confirmed, High, Medium, Low, False Positive

Summaries Alert counts by risk and confidence

This table shows the number of alerts for each level of risk and confidence included in the report.
(The percentages in brackets represent the count as a percentage of the total number of alerts included in
the report, rounded to one decimal place.)
Alert counts by site and risk

This table shows, for each site for which one or more alerts were raised, the number of alerts raised at
each risk level. Alerts with a confidence level of "False Positive" have been excluded from these counts.
(The numbers in brackets are the number of alerts raised for the site at or above that risk level.)

Alert counts by alert type

This table shows the number of alerts of each alert type, together with the alert type's risk level
operational, and technical controls used to protect the confidentiality, integrity, and availability of the
system and the data it stores, transmits or processes.

Exploitation

Exploited Vulnerabilities:

• Cross Site Scripting (Reflected)

• Cross Site Scripting (DOM Based)
• SQL Injection
• Absence of Anti-CSRF Token

1. Cross-site scripting (self)

Issue detail

The name of an arbitrarily supplied URL parameter is copied into the HTML document as plain text
between tags. The payload was submitted in the name of an arbitrarily supplied URL parameter. This
input was echoed unmodified in the application's response. This behavior demonstrates that it is possible
to inject new HTML tags into the returned document. An attempt was made to identify a full proof-of-
concept attack for injecting arbitrary JavaScript but this was not successful. You should manually examine
the application's behavior and attempt to identify any unusual input validation or other obstacles that
may be in place.

Issue background
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
attackersupplied 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
securitycritical 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
Issue remediation
In most situations where user-controllable data is copied into application responses, cross-site scripting
attacks can be prevented using two layers of defenses:
● Input should be validated as strictly as possible on arrival, given the kind of content that it is expected to
contain. For example, personal names should consist of alphabetical and a small range of typographical
characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses
should match a well-defined regular expression. Input which fails the validation should be rejected, not
sanitized.

●User input should be HTML-encoded at any point where it is copied into application responses. All
HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (<
> etc). In cases where the application's functionality allows users to author content using a restricted
subset of HTML tags and attributes (for example, blog comments which allow limited formatting and
linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax;
this is a non-trivial task

References

● Cross-site scripting

● Reflected cross-site scripting

● Using Burp to Find XSS issues

Vulnerability classifications
● CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')● CWE-

80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

● CWE-116: Improper Encoding or Escaping of Output

● CWE-159: Failure to Sanitize Special Element

Request

2 .Flash cross-domain policy

Issue detail
The application publishes a Flash cross-domain policy which allows access from any domain. Allowing
access from all domains means that any domain can perform two-way interaction with this application.
Unless the application consists entirely of unprotected public content, this policy is likely to present a
significant security risk
Issue background
The Flash cross-domain policy controls whether Flash client components running on other domains can
perform two-way interaction with the domain that publishes the policy. If another domain is allowed by
the policy, then that domain can potentially attack users of the application. If a user is logged in to the
application, and visits a domain allowed by the policy, then any malicious content running on that domain
can potentially gain full access to the application within the security context of the logged in user. Even if
an allowed domain is not overtly malicious in itself, security vulnerabilities within that domain could
potentially be leveraged by a third-party attacker to exploit the trust relationship and attack the
application that allows access. Any domains that are allowed by the Flash crossdomain policy should be
reviewed to determine whether it is appropriate for the application to fully trust both their intentions and
security posture.
Issue remediation

Any inappropriate entries in the Flash cross-domain policy file should be removed.
Vulnerability classifications

● CWE-942: Overly Permissive Cross-domain Whitelist

 2. Unencrypted communications

Issue description

The application allows users to connect to it over unencrypted connections. An attacker suitably
positioned to view a legitimate user's network traffic could record and monitor their interactions with the
application and obtain any information the user supplies. Furthermore, an attacker able to modify traffic
could use the application as a platform for attacks against its users and thirdparty websites. Unencrypted
connections have been exploited by ISPs and governments to track users, and to inject adverts and
malicious JavaScript. Due to these concerns, web browser vendors are planning to visually flag
unencrypted connections as hazardous. To exploit this vulnerability, an attacker must be suitably
positioned to eavesdrop on the victim's network traffic. This scenario typically occurs when a client

not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting
infrastructure could also perform this attack. Note that an advanced adversary could potentially target
any connection made over the Internet's core infrastructure. Please note that using a mixture of
encrypted and unencrypted communications is an ineffective defense against active attackers, because
they can easily remove references to encrypted resources when these references are transmitted over
an unencrypted connection. Issue remediation
Applications should use transport-level encryption (SSL/TLS) to protect all communications passing
between the client and the server. The Strict-Transport-Security HTTP header should be used to ensure
that clients refuse to access the server over an insecure connection
References

● Marking HTTP as non-secure

● Configuring Server-Side SSL/TLS
● HTTP Strict Transport Security
Vulnerability classifications
● CWE-326: Inadequate Encryption Strength

3. Cross-domain Referrer leakage

Issue detail

The page was loaded from a URL containing a query string:

● http://testphp.vulnweb.com/listproducts.php
The response contains the following links to other domains:

● http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab
● http://www.acunetix.com/
● https://www.acunetix.com/
● https://www.acunetix.com/blog/articles/prevent-sql-injection-vulnerabilities-
inphpapplications/
● https://www.acunetix.com/vulnerability-scanner/
● https://www.acunetix.com/vulnerability-scanner/php-security-scanner/
● http://www.eclectasy.com/Fractal-Explorer/index.html

Issue background

When a web browser makes a request for a resource, it typically adds an HTTP header, called the
"Referer" header, indicating the URL of the resource from which the request originated. This
occurs in numerous situations, for example when a web page loads an image or script, or when a
user clicks on a link or submits a form. If the resource being requested resides on a different
domain, then the Referer header is still generally included in the cross-domain request. If the
originating URL contains any sensitive information within its query string, such as a session token,
then this information will be 12 transmitted to the other domain. If the other domain is not fully
trusted by the application, then this may lead to a security compromise. 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.
Issue remediation

Applications should never transmit any sensitive information within the URL query string. In
addition to being leaked in the Referer header, such information may be logged in various
locations and may be visible on-screen to untrusted parties. If placing sensitive information in the
URL is unavoidable, consider using the Referer-Policy HTTP header to reduce the chance of it
being disclosed to third parties.
References

● Referer Policy

Vulnerability classifications

● CWE-200: Information Exposure

4. Frameable response (potential Clickjacking)

There are 5 instances of this issue:

● /categories.php
● /comment.php
● /guestbook.php● /listproducts.php
Issue description
 If a page fails to set an appropriate X-Frame-Options or Content-Security-Policy HTTP header, it
might be possible for a page controlled by an attacker to load it within an iframe. This may enable
a clickjacking attack, in which the attacker's page overlays the target application's interface with a
different interface provided by the attacker. By inducing victim users to perform actions such as
mouse clicks and keystrokes, the attacker can cause them to unwittingly carry out actions within
the application that is being targeted. This technique allows the attacker to circumvent defenses
against cross-site request forgery, and may result in unauthorized actions. Note that some
applications attempt to prevent these attacks from within the HTML page itself, using
"framebusting" code. However, this type of defense is normally ineffective and can usually be
circumvented by a skilled attacker. You should determine whether any functions accessible within
frameable pages can be used by application users to perform any sensitive actions within the
application.

Issue remediation

To effectively prevent framing attacks, the application should return a response header with the
name X-Frame-Options and the value DENY to prevent framing altogether, or the value
SAMEORIGIN to allow framing only by pages on the same origin as the response itself. Note that
the SAMEORIGIN header can be partially bypassed if the application itself can be made to frame
untrusted websites
References

● X-Frame-Options
Vulnerability classifications

● CWE-693: Protection Mechanism Failure

5.Email addresses disclosed

There are 4 instances of this issue:
● /categories.php
● /guestbook.php
● /listproducts.php

Issue background

The presence of email addresses within application responses does not necessarily constitute a
security vulnerability. Email addresses may appear intentionally within contact information, and
 many applications (such as web mail) include arbitrary third-party email addresses within their
core content. However, email addresses of developers and other individuals (whether appearing
on-screen or hidden within page source) may disclose information that is useful to an attacker;
for example, they may represent usernames that can be used at the application's login, and they
may be used in social engineering attacks against the organization's personnel. Unnecessary or
excessive disclosure of email addresses may also lead to an increase in the volume of spam email
received
Issue remediation

Consider removing any email addresses that are unnecessary, or replacing personal addresses
with anonymous mailbox addresses (such as [email protected]). To reduce the quantity of
spam sent to anonymous mailbox addresses, consider hiding the email address and instead
providing a form that generates the email server-side, protected by a CAPTCHA if necessary
Vulnerability classifications

● CWE-200: Information Exposure

7.Blind SQL
Issue Background

SQL injection is a code injection technique, used to attack data-driven applications, in which
malicious SQL statements are inserted into an entry field for execution (e.g. to dump the database
contents to the attacker).[1] SQL injection must exploit a security vulnerability in an application's
software, for example, when user input is either incorrectly filtered for string literal escape characters
embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL
injection is mostly known as an attack vector for websites but can be used to attack any type of SQL
database
 8.LFI (Local File Inclusion)

A file inclusion vulnerability is a type of web vulnerability that is most commonly found to affect web
applications that rely on a scripting run time. This issue is caused when an application builds a path to
executable code using an attacker-controlled variable in a way that allows the attacker to control which
file is executed at run time. A file include vulnerability is distinct from a generic directory traversal attack,
in that directory traversal is a way of gaining unauthorized file system access, and a file inclusion
vulnerability subverts how an application loads code for execution. Successful exploitation of a file
inclusion vulnerability will result in remote code execution on the web server that runs the affected web
application. An attacker can use remote code execution to create a web shell on the web server, which
can be used for website defacement.
9. Description and Risk Rating
Conclusion:

• Summary of Findings
• Mitigations

Cross Site Scripting (Reflected):

Summary:

Cross-Site Scripting (XSS) occurs when an attacker injects malicious scripts into web pages viewed by
other users. In reflected XSS, the malicious script is reflected off a web server, such as in an error message
or input field, and executed when the victim visits a specially crafted link. Mitigation Methods: 1. Input
Validation and Sanitization: Validate and sanitize user inputs to remove or encode any potentially harmful
characters before processing them.
2. Output Encoding: Encode output to prevent script execution. HTML-encode dynamic content
before rendering it in the browser to neutralize any injected scripts.
3. Content Security Policy (CSP): Implement CSP headers to restrict which resources can be loaded,
reducing the risk of XSS attacks by specifying trusted sources for scripts, stylesheets, images, etc.

SQL Injection:
Summary:
SQL Injection is a code injection technique that exploits vulnerabilities in database queries. Attackers
inject malicious SQL queries through user inputs to manipulate the database or gain unauthorized access.
Mitigation Methods:

1. Parameterized Queries: Use parameterized queries or prepared statements provided by your

database framework to separate SQL code from data, preventing injection attacks.
2. Input Sanitization: Sanitize user inputs by removing or escaping special characters that could alter
the SQL query structure. Use whitelisting rather than blacklisting approaches to validate inputs.

3.Least Privilege Access Control: Enforce least privilege access control to databases by restricting
database user permissions to only necessary operations, reducing the impact of successful SQL injection
attacks.

These mitigation methods help in mitigating the risks associated with each vulnerability, strengthening
the security posture of web applications