Module : MOD004891

SID: 2170041
Module name: Penetration Testing
Title: 011-2 Pen Test Report
Table of Content

CONFIDENTIALITY CLAUSE 3

DOCUMENT OVERVIEW 4

DISCLAIMER 5

1. SCOPE 6

2. PROJECT SCOPE 6

3. PROJECT OBJECTIVES 6

4. APPROACH 7

5. APPROACH AND METHODOLOGY 8

6. KEY OBSERVATIONS 9

7. VULNERABILITIES DEFINITION 10

8. MANAGEMENT SUMMARY 11

8.1 VULNERABILITY DASHBOARD 11

8.2 VULNERABILITY AND RISK 11

9. DETAILED OBSERVATION 13

10. APPENDIX – A PROOF OF CONCEPTS 22

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 2

CONFIDENTIALITY CLAUSE

This document is the property of Unsafe Bank Application All ideas and information contained
within the document is the intellectual property of XBank Corporation These documents are
not for general distribution and are meant for use solely by the person/persons to whom it is
specifically issued to or shared with. XBank Corporation does not share this document with
any third party or vendor unless specifically exempted by the competent authority. Copying
or unauthorized distribution of these documents, in any form or means including electronic,
mechanical, photocopying or otherwise is illegal.

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 3

DOCUMENT OVERVIEW
Report ID
Report type Final
Document Type
Client name XBank Corporation
Project name XBC Black Box

Application type (Internet/Intranet) Internet

Description UnSafe bank is an Online Banking service
web application hosted on On-prem servers
of XBank Corp. The core business logic of
the application to Create, modify account
and Manage finances with them.
Lifecycle stage Testing
Application Contact manager@xbank.com
Consultant contact ronit@securityX.com
Test start date 14/02/2023
Test end date 14/03/2023
Reviewed by Security Architect

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 4

DISCLAIMER
This report has been issued based upon our work for Pune Municipal Corporation on 16-02-2023 to
17-03-2023. The scope of the work was to Web Application Security Assessment of XBank
Corporation UNSAFE BANK Application.

The report prepared for the period prescribed in the report as an account of work allocated by XBank
Corporation (Herein after referred as “XBC” and observed during the audit execution dates. Though
all efforts have been made to ensure the accuracy of the content in this Report, the same should not
be construed as a statement of Law, Policy or used for any legal purposes. XBC is advised to
verify/check any information with the relevant authorities(s), and to obtain any appropriate
professional advice before acting on the information provided in the Report.

Penetration testing/Application Security Assessment is a process, based upon past experiences,

currently available information, and known threats. It should be understood that all information
systems, which by their nature are dependent on human beings, are vulnerable to some degree.
Therefore, while considers the major security vulnerabilities of the analyzed applications to have
been identified, there can be no assurance that any exercise of this nature will identify all possible
vulnerabilities or propose exhaustive and operationally viable recommendations to mitigate those
exposures. In addition, the analysis set forth herein is based on the information gathered,
technologies and known threats as of the date of this report.

Links in the form of recommendations as mentioned in the report if any, are provided for reference
and further reading only. is not responsible for the contents or reliability of linked websites and does
not necessarily endorse the view expressed within them.

Details mentioned in the Report to be considered as a “Confidential” and caution to maintain the
material to be accurately and not to be used in a derogatory manner or in a misleading context.
Wherever the material is being published or issued to others, the source must be prominently
acknowledged. These terms and conditions shall be governed by and construed in accordance with
the Indian Laws. Any dispute arising under these terms and conditions shall be subject to the exclusive
jurisdiction of the courts of United Kingdom – Cambridge.

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 5

 1. SCOPE
The scope of the vulnerability and penetration testing of the application covers.

Details
In-Scope URL: http://zero.webappsecurity.com/index.html
Environment: Testing
Application Version N/A
Compilation Date: N/A
Testing Methodology Black Box Testing

2. PROJECT SCOPE
The XBC Web Application was the target of the Web Application Penetration Testing. This
outcome is meant to be an overall evaluation of the Unsafe Bank Web application that falls
within the scope of this project. Also, the findings in this study represent the conditions
discovered during testing, not necessarily current situations.

3. PROJECT OBJECTIVES
This Report highlights the findings of the Assessment conducted to assess the risks to the
XBC Online Application. The following actions were carried out in accordance with the
requested scope and aim of the engagement:

• Identifying vulnerabilities in the UnSafe Bank Web applications infrastructure.

• Assessing the impact of any discovered vulnerabilities.
• Prioritizing the vulnerabilities based on risk exposure and developing
recommendations to mitigate the vulnerabilities as SANS-25 and OWASP Top 10
Framework and CVE and CWE database.
• Providing recommendations to mitigate risks arising from the discovered
vulnerabilities.
• This report summarises the engagement's findings and suggestions. We did an
automated and manual review, one-on-one evaluation, and employed a set of tools
for this activity.

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 6

 4. APPROACH
We assumed that the specified hosts are externally hosted, that the company has applied the
applicable security rules, and that the systems have been installed and updated with the most
recent antivirus and antivirus definitions. All system and software programmes are updated
or upgraded to the most recent security updates and patches as recommended by the OEM.

Pre-
engagement • Step 1
Interaction

Intelligence • Step 2
Gathering

Threat • Step 3
modelling

Vulnerability • Step 4
Analysis

Exploitation • Step 5

Reporting •Step 6

The Workflow is presented below:

Veracode
Release onboarding (For Report
static analysis)

Onboard for Re-validation

Report
Security Testing Testing

Deployment

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 7

The aforementioned process involves both manual and automated tasks, as well as customer-
related activities.

5. APPROACH AND METHODOLOGY

This evaluation was carried out as part of the Web Application Vulnerability Assessment and
Penetration testing, which is a combination of Industry Best Practices and OWASP Web Top
10. The goal of this evaluation is to uncover security flaws in the Web Application that might
be exploited. We attempted to assess the overall security of the Application by running a
number of vulnerability tests. Also, the findings in this study represent the conditions
discovered during testing, not necessarily current situations.

The process of testing, evaluating, and reporting on the security level or security posture of
the subject IT component/s that link to the entire IT environment is known as security testing.
It is carried out to uncover faults / holes in the target system that may turn out to be
vulnerabilities and produce an impact on the company, which may be present or impending.

While completing security assessments, the following technique is used:

1. Pre-engagement phase: The following ground rules are set before beginning the
evaluation during the pre-engagement phase:

• Scope: Scoping will be done in collaboration and agreement with the customer.
Any component that is not expressly stated in the scope will not be covered.

• Test schedule: The Security Operations team conducts the security assessment in
accordance with the organization's schedules. Nonetheless, some network traffic
may be created during the evaluation, thus it is recommended to give a test
window during non-peak business hours when network traffic is minimal.

• The security operations team may conduct security assessments in a

Test/STAGING environment, which is a production-like environment for
enterprises with high availability expectations and where system continuous &
high availability is a Requirement.

• Test Selection - Grey-box Testing/White box Testing: The kind of testing chosen is
an important aspect of the pre-engagement process since it directs the security
tester prior to the assessment.

2. Information Gathering: After defining the scope of the assessment, the purpose is to
enumerate the subject system in order to obtain information about potential
vulnerabilities and relevant exploits to exploit the detected flaws.
Tools involved in this phase is : nmap, dirb, sublister, ffuf, nuclei.

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 8

 3. Threat modelling: This section outlines a threat modelling technique that is essential
for proper penetration testing execution. The report does not specify a model, but
rather demands that the model be consistent in its portrayal of threats, their
capabilities, their qualifications as per the organization being evaluated, and its
capacity to be used to future tests with the same findings. The standard focuses on
two critical components of traditional threat modelling: assets and attackers (threat
community/agent). Each is subdivided into business assets and business processes, as
well as danger communities and their capabilities.
Tools used in this section were Microsoft Threat Modeler

4. Exploitation: The purpose is to exploit vulnerabilities such as unsecured endpoints,

faulty input validation and access control, the lack of JSON Web Tokens (JWT) or API
keys, HTTP verb manipulation, improper validation of request content types, and the
exposure of sensitive information.
Tools used in this section were BurpSuite Professional, SQLmap.

5.1. OWASP Web application Security Project framework

• A1 – Injection
• A2 – Broken Authentication
• A3 – Sensitive data Exposure
• A4 – XXE
• A5 – Broken Access Control
• A6 – Security Misconfiguration
• A7 – Cross Site Scripting
• A8 – Insecure Deserialization
• A9 – Using component with known vulnerabilities.
• A10 – Insufficient logging and monitoring

6. KEY OBSERVATIONS
• Cross-Site Scripting – CWE-79
• Lack of Rate Limiting – CWE-799
• Clear text Submission of Password – CWE-319
• Weak SSL Ciphers – CWE-326
• Improper handling of error – CWE-703
• Session token in URL – CWE-598
• Using components with Known vulnerabilities – CWE-1352
• Missing Security Headers – CWE-693

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 9

 7. VULNERABILITIES DEFINITION
The following Findings section employs a ranking system based on the severity of our results.
All discoveries are vulnerabilities that pose a commercial risk to the organisation
(Vulnerability severity levels, 2022).

Vulnerability Description
Severity
The impacts of Critical severity vulnerabilities are as follows:
These vulnerabilities can allow attackers to take complete control of your Web applications and
servers. In exploiting this type of vulnerability, attackers could carry out a range of malicious
acts including (but not limited to):
• Stealing information (for example, user data)
• Tricking your users into supplying them with sensitive information (for example, credit card
details)
• Defacing your Web Application
I. By exploiting a critical severity vulnerability, attackers can access your Web application's
database. This allows them to acquire user and administrator information that might allow
Critical them to make changes such as delete or modify other user accounts.
II. On exploiting such vulnerabilities, attackers can access and control logged-in user or
administrator accounts, enabling them to hijack accounts and make changes that typically only
those users can.
Suggested Action for Critical Severity Vulnerabilities:
A Critical severity vulnerability means that your Web Application can be hacked any time. You
should make it your highest priority to fix these vulnerabilities immediately. Once you fix them,
rescan the Web Application to make sure they have been eliminated.

Impacts of High Severity Vulnerabilities:

1. Attackers can find other vulnerabilities, and potentially your database passwords, by
viewing your application's source code.
2. On exploiting such vulnerabilities, attackers can view information about your system that
High helps them find or exploit other vulnerabilities that enable them to take control of your
Web Application and access sensitive user and administrator information.
Suggested Action for High Severity Vulnerabilities:
A High severity vulnerability means that your Web Application can be hacked, and hackers can find
other vulnerabilities which have a bigger impact. Fix these types of vulnerabilities immediately.
Once you fix them, rescan your Web Application to make sure they have been eliminated
This level of vulnerability represents a moderate level of weakness in the current control
environment and requires management action attention in the near term.
Medium

Low This severity level provides for an opportunity to improve effectiveness and efficiency of the
current control environment.

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 10

 Informational Serves as an informational purpose.

Table 1.2 Illustrates the colour convention and associated meaning.

8. MANAGEMENT SUMMARY

8.1 Vulnerability dashboard

S.NO Findings Details Critical High Medium Low Info

1 Web Application Findings 0 4 5 0 1

8.2 Vulnerability and Risk

Discovered 0 Critical, 0 Medium, 0 Low, and 0 Info severity level vulnerabilities in the
Application, http://zero.webappsecurity.com/index.html, and recommends the fix to the
client. During the vulnerability closure conversation, the team presented the repercussions
and risk associated with these disclosed vulnerabilities, as well as the results if they remain
open. The client is aware of the danger and is willing to endure its negative consequences for
the time being. They have accepted that this may have an impact on the application's
availability.

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 11

 Graph 1 Illustrates the count of vulnerabilities.

Conclusion:

Managerial attention is necessary to prioritise mitigation of disclosed vulnerabilities based on

their risk ranking / severity. The report's recommendations for closing the above-mentioned
observations might be referred to as advice. Once the following observations have been
resolved, revalidation testing will be performed to check that they are compiled or closed,
and a report will be produced based on the same. Please see the comprehensive portion of
this report for further information on the vulnerability / observations, mitigation &
recommendations, risk ratings, and so on.

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 12

 9. DETAILED OBSERVATION

Vulnerability #1 CVSS Score

Cross-Site Scripting

Severity: Status: 8.3

(High)
High Unresolved

Affected URL:
https://zero.webappsecurity.com/bank/account-activity-show-transactions

Details of Vulnerability:

XSS attacks are a sort of injection in which malicious scripts are injected into otherwise
innocuous and trustworthy websites. XSS attacks occur when an attacker utilises a web
application to transmit malicious code to a separate end user, typically in the form of a
browser side script. The flaws that allow these attacks to succeed are extremely common,
and they occur whenever a web application includes user input inside the output it creates

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 13

without verifying or encoding it. [KirstenS Cross site scripting (XSS), Cross Site Scripting
(XSS)]

Impact:
An attacker may often totally compromise a user if they can manipulate a script that is
performed in the victim's browser. The attacker can, among other things (Portswigger, 2023):

• Perform any action within the application that the user can perform.
• View any information that the user is able to view.
• Modify any information that the user is able to modify.
• Initiate interactions with other application users, including malicious attacks,
that will appear to originate from the initial victim user.

Suggested Fix:

• HTML/ JavaScript/ URL Encoding

• Implement CSP
• Implement “HTTP only” Cookie.
• Input validation
• Whitelisting
• WAF rules

Proof of Concept

Vulnerability #2 CVSS Score

Lack of Rate limiting

Severity: Status: 7.1

(High)
High Unresolved

Affected URL:
https://zero.webappsecurity.com/feedback.html

Details of Vulnerability:

APIs that do not have proper constraints in place can be overrun by legitimate queries as well
as malicious actors attempting Denial of Service (DoS) attacks. A rapid rush of requests, or
even a small number of incorrect requests, might cause issues for the API server, regardless
of their source. Simple API queries are required for exploitation. There is no need for
authentication. Many concurrent requests can be handled by a single local computer or
through the use of cloud computing services.

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 14

Impact:

Exploitation may lead to DoS, making the API unresponsive or even unavailable.

Suggested Fix:

• Define proper rate limiting.

• Limit payload sizes.
• Tailor the rate limiting to be match what API methods, clients, or addresses need or should be
allowed to get.
• Add checks on compression ratios.
• Define limits for container resources. (API4:2019 - lack of resources and rate limiting 2021)

Proof of Concept

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 15

Vulnerability #3 CVSS Score

Clear text submission of password

Severity: Status: 7.3

(High)
High Unresolved

Affected URL:
http://zero.webappsecurity.com/login.html?login_error=true

Details of Vulnerability:

Vulnerabilities that result in the disclosure of users' passwords can result in compromises that
are extremely difficult to investigate due to obscured audit trails. Even if the application itself
only handles non-sensitive information, exposing passwords puts users who have re-used
their password elsewhere at risk.

Impact:

• Passwords can be intercepted.

• Passwords can be stolen.
• Reduced security
• Compliance violations
• Loss of trust

Suggested Fix:

To assuage the deleterious effects of submitting passwords as plain text, entities must
institute measures that ensure their password handling practices are impervious to
infringement. Such steps may encompass fortified encryption methods and resilient
transmission protocols that seek to forestall surreptitious admittance into sensitive
information reservoirs and user accounts alike while simultaneously bolstering user faith in
the system or application at hand.

Proof of Concept

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 16

Vulnerability #4 CVSS Score

Vulnerable version of SSL

Severity: Status: 7.4

(High)
High Unresolved

Affected URL:
http://zero.webappsecurity.com/login.html?login_error=true

Details of Vulnerability:

When sensitive data is sent via a network, it must be safeguarded. User credentials and credit
cards are examples of such data. As a general rule, if data must be safeguarded when stored,
it must also be protected during transit.

HTTP is a clear-text protocol that is often protected over an SSL/TLS tunnel, resulting in HTTPS
transmission. This protocol guarantees not just secrecy but also authentication. Servers are
authenticated using digital certificates, and client certificates can also be used for mutual
authentication.

Impact:

• Plain-text communication
• Susceptible for intercept

Suggested Fix:

Upgrade to TLS

Proof of Concept

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 17

Vulnerability #4 CVSS Score

Improper handling of error

Severity: Status: 5.3

(Medium)
Medium Unresolved

Affected URL:
https://zero.webappsecurity.com/bank/account-activity-show-transactions

Details of Vulnerability:

Poor error handling can cause a range of security issues for a website. The most typical issue
is when the user sees comprehensive internal error messages such as stack traces, database
dumps, and error codes (hacker). These messages expose implementation information that
should not be made public. Such information might offer hackers with significant indications
about possible faults in the site, and such messages can be upsetting to legitimate users.

Impact:
• Information leakage
• Denial of Service
• System crash
• Elevation of privilege
• Increased attack surface

Suggested Fix:

• Identify all possible error conditions in your application and the data that is associated
with them.
• Develop a consistent and standardized error handling approach that will cover all
identified errors.
• Perform rigorous testing of your application to identify any possible error conditions
that were missed during development.

Proof of Concept

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 18

Vulnerability #5 CVSS Score

Session token in URL

Severity: Status: 5.3

(Medium)
Medium Unresolved

Affected URL:
• http://zero.webappsecurity.com/auth/accept-certs.html?user_token=505686a2-
e42a-4101-ab8e-172f157b09eb
• http://zero.webappsecurity.com/auth/security-check.html?user_token=505686a2-
e42a-4101-ab8e-172f157b09eb

Details of Vulnerability:

Sensitive information within URLs may be logged in various locations, including the user's
browser, the web server, and any forward or reverse proxy servers between the two
endpoints. URLs may also be displayed on-screen, bookmarked, or emailed around by users.
They may be disclosed to third parties via the Referrer header when any off-site links are
followed. Placing session tokens into the URL increases the risk that they will be captured by
an attacker.

Impact:
• Session hijack
• Session termination
• Session breaches

Suggested Fix:

Applications should use an alternative mechanism for transmitting session tokens, such as
HTTP cookies or hidden fields in forms that are submitted using the POST method.

Proof of Concept

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 19

Vulnerability #6 CVSS Score

Using Component with known Vulnerabilities

Severity: Status: 5.1

(High)
Medium Unresolved

Affected URL:
http://zero.webappsecurity.com/forgot-password.html
http://zero.webappsecurity.com/login.html?login_error=true
http://zero.webappsecurity.com/resources/js/jquery-1.8.2.min.js
http://zero.webappsecurity.com/search.html?searchTerm=335159

Details of Vulnerability:

Top 10 OWASP defines components as a rather wide concept. It might be a whole piece of
software from a third party, such as "It's me," an identity validation service, or it could be a
minor reliance in a script hidden someplace far away.

When we discuss A9: Employing Components with Known Vulnerabilities, we are frequently
referring to either obsolete software or software that is no longer being updated. Generally,
well-maintained software will strive to resolve any issues that develop, but putting out such
updates can be time-consuming, and users of that component may be hesitant to update.

Impact:

• Increased risk of exploitation

• Increased attack surface
• Compliance violation
• Reputation damage

Suggested Fix:

To mitigate the risks associated with using components with known vulnerabilities, it is
important to regularly monitor and update all components and dependencies in the system.
Additionally, organizations can consider implementing security policies and procedures that
include guidelines for selecting and using components and dependencies in a secure manner.

Proof of Concept

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 20

Vulnerability #7 CVSS Score

Missing Security Headers

Severity: Status: 0.0

(Info)
Info Unresolved

Affected URL:
Sitewide

Details of Vulnerability:

HTTP security headers are a subset of HTTP headers that are only concerned with security.
They are used to provide the security aspects of HTTP communication between a client (often
a web browser) and a server. Some HTTP headers, while not directly connected to privacy and
security, can also be classified as HTTP security headers.

Adding appropriate headers in your web applications and web server settings is a simple
approach to dramatically increase your web application's resilience against many common
attacks, such as cross-site scripting (XSS) and clickjacking assaults. This page just contains the
most relevant headers; for a more complete overview of various security headers, visit our
white paper on HTTP security headers (Avery, A. and Manico, J.OWASP Foundation).

Impact:
• Increased risk of attacks
• Reduced User policy

Suggested Fix:
• Strict-Transport-Security
• Content-Security-Policy
• X-Frame-Options
• X-XSS-Protection
• X-Content-Type-Options

Proof of Concept

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 21

 10. Appendix – A Proof of Concepts

Cross-Site Scripting

Fig 10.1 Illustrates Reflected XSS on the web app

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 22

Lack of Rate-limiting

Fig 10. 2 Illustrates Insufficient Rate limiting issue at Comment section

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 23

Clear text submission of Password

Fig 10.3 Illustrates clear text password submission.

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 24

Improper handling of error

Fig 10.4 Illustrates Improper error handling.

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 25

Session token in URL

Fig 10.5 Illustrates of Session token sent in the URL.

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 26

Using Components with known Vulnerabilities

Fig 10.6 Illustrates the vulnerable version of jQuery being used.

Fig 10.7 Illustrates the CVE of the vulnerable version of jQuery.

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 27

Missing Security Headers

Fig 10.8 Illustrates Missing Security Headers

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 28

Weak SSL Ciphers

Fig 10.9 Illustrates Weak Ciphers used in SSL.

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 29

References

Avery, A. and Manico, J. (no date) Owasp Secure Headers Project, OWASP Secure Headers
Project | OWASP Foundation. Available at: https://owasp.org/www-project-secure-
headers/ (Accessed: April 6, 2023).

KirstenS (no date) Cross site scripting (XSS), Cross Site Scripting (XSS) | OWASP
Foundation. Available at: https://owasp.org/www-community/attacks/xss/ (Accessed:
April 6, 2023).

42Crunch (ed.) (2021) API4:2019 - lack of resources and rate limiting, API Security News.
Available at: https://apisecurity.io/encyclopedia/content/owasp/api4-lack-of-resources-
and-rate-limiting (Accessed: April 6, 2023).

Vulnerability severity levels (2022) Invicti. Available at:

https://www.invicti.com/support/vulnerability-severity-levels-invicti/#critical-severity-
web-vulnerabilities (Accessed: April 6, 2023).

Version 1.0 UnSafe Bank Vulnerability Assessment Report 2170041 30