Web S1 Retest Report

Reliance Comfort Limited Partnership
( Jan 18th, 2024 To Jan 23rd, 2024 )
PENETRATION RETEST
REPORT
Disclosure Statement
This document contains sensitive information about the computer security environment,
practices, and current vulnerabilities and weaknesses of the client's security
infrastructure as well as proprietary tools and methodologies used by BreachLock. This
document is subject to the terms and conditions of a non- disclosure agreement
between BreachLock and the client.
Document Information
Engagement scope Project ID

2 asset(s) REL3_EWABB_S1_DEC12
Engagement Timeframe Pentest ID

( Jan 18th, 2024 To Jan 23rd, 2024 ) REL3_EWABB_S1_DEC12_2
Version History
Version Date Author/Reviewer Comment
0.1 Jan 12th, 2024 Breachlock Initial Report
0.2 Jan 22nd, 2024 Breachlock QA
1.0 Jan 23rd, 2024 Breachlock Final Report
02
Table Of Contents
A. Assessment Scope 4
B. Executive Summary 5
C. Vulnerabilities Summary 8
D. Testing Methodology 24
1. Introduction 24
2. WEB APPLICATION ASSESSMENT 26
3. Vulnerabilities Classification 30
E. Vulnerabilities Details and Recommendations 32
E.1.1. Web Application Vulnerable to Clickjacking 32
E.2.1. Cookies Without HttpOnly Flag Detected 34
E.2.2. Cookies Without Secure Flag Detected 35
E.2.3. CORS Misconfiguration Present 36
E.2.4. Outdated Wordpress Plugins 38
E.2.5. Sensitive Data Exposure 40
E.2.6. Server Software Version(s) Disclosed 42
E.2.7. Web Application Does Not Supply a Content Security Policy 44
E.2.8. Web Application Permits MIME Type Sniffing 46
E.3.1. Server Software Information Disclosed 48
E.3.2. Server Vulnerable to Lucky13 TLS Exploit 50
E.3.3. Web Application Does Not Supply a Permissions Policy 52
E.3.4. Web Application Does Not Supply a Referrer Policy 54
E.3.5. Web Server Vulnerable to HTTP Host Header Attack 56
03
A. Assessment Scope
Web Application Penetration Retest
Organization Reliance Comfort Limited Partnership
Methodology Black box
Timeline ( Jan 18th, 2024 To Jan 23rd, 2024 )
Asset(s) https://reliancehomecomfort.com/toronto, https://reliancehc.

wpenginepowered.com
04
B. Executive Summary
The BreachLock penetration testing and ethical hacking team conducted a Web
Application Penetration Test against the hosts given by Reliance Comfort Limited
Partnership. The security assessment took place over the period of, Jan 18th, 2024 until
Jan 23rd, 2024 from BreachLock.
The main goal of this assessment was to ensure that appropriate information security
controls are implemented within the network and host environment to preserve the
integrity, confidentiality and availability of its information and computing resources.
Pen Testing team that participated in this project has the following global certifications:
CEH, OSCP, OSCE, CREST PT, SANS GSNA
During the assessment, we have identified 0 Critical, 0 High, 1 Medium, 8 Low, 5 Info
vulnerabilities. Below is a graphical representation of your risk posture based on the
results of this penetration test. The risk, likelihood and impact are calculated using the
industry-standard CVSS scoring system:
Risk
Low
Major
Medium
High
Impact
Critical
2.3,
Moderate 2.4,
2.5,
2.6,
2.7, 2.1, 1.1
2.8 2.2
Minor
Improbable Possible Probable
Likelihood
Risk A Risk is defined as the potential that a given threat will exploit
vulnerabilities of an asset or group of assets and thereby cause harm
to the organization.
Likelihood The Likelihood is defined as the probability of a given threat exploiting

vulnerability. That incorporates ease of exploitation and
determination and capability of the given threat agent.
Impact A Possible impact of an occurrence of a risk.
05
S. No. Severity Vulnerability Patch /
Unpatch
1.1 HIGH Backup file disclosure Patched
2.1 MEDIUM User Enumeration Possible Patched
2.2 MEDIUM Web Application Vulnerable to Clickjacking Unpatched
2.3 MEDIUM Web Server has HSTS Disabled Patched
3.1 LOW Cookies Without HttpOnly Flag Detected Unpatched
3.2 LOW Cookies Without Secure Flag Detected Unpatched
3.3 LOW CORS Misconfiguration Present Unpatched
3.4 LOW No DMARC Policy Supplied in Web Patched

Application DNS Records
3.5 LOW Outdated Wordpress Plugins Unpatched
3.6 LOW Sensitive Data Exposure Unpatched
3.7 LOW Server Software Version(s) Disclosed Unpatched
3.8 LOW Web Application Does Not Supply a Content Unpatched

Security Policy
3.9 LOW Web Application Permits MIME Type Sniffing Unpatched
4.1 INFORMAT All Cookies found Patched

IONAL
4.2 INFORMAT Discovered host Patched

IONAL
06
4.3 INFORMAT Domain Email Spoofing Patched
IONAL
4.4 INFORMAT Email Addresses Disclosed Patched

IONAL
4.5 INFORMAT Html Comment Patched

IONAL
4.6 INFORMAT Server Software Information Disclosed Unpatched

IONAL
4.7 INFORMAT Server Vulnerable to Lucky13 TLS Exploit Unpatched

IONAL
4.8 INFORMAT Service Provider Patched

IONAL
4.9 INFORMAT TLS/SSL Certificate Does Not Support the Patched

IONAL Latest Version of TLS
4.10 INFORMAT Web Application Does Not Supply a Unpatched

IONAL Permissions Policy
4.11 INFORMAT Web Application Does Not Supply a Referrer Unpatched

IONAL Policy
4.12 INFORMAT Web Application Firewall Present Patched

IONAL
4.13 INFORMAT Web Server Vulnerable to HTTP Host Header Unpatched

IONAL Attack
07
C. Vulnerabilities Summary
The risk ratings allocated to each vulnerability are determined based on several factors
including asset criticality, reputation, complexity, threat likelihood, and vulnerability
severity.
CRITICAL Critical risk vulnerabilities could be expected to have a very high

threat to a company’s data and should be fixed as a top-priority
basis. Critical vulnerabilities can allow a hacker to compromise
the environment or cause other severe impacts.
HIGH High risk vulnerabilities could be expected to have a

catastrophic adverse effect on organizational operations,
organizational assets, or individuals.
MEDIUM Medium risk vulnerabilities could be expected to have a serious

adverse effect on organizational operations, organizational
assets, or individuals.
LOW These are security issues that do not functionally alter normal
systems behavior, but which may aid or enable further attacks
against the system under other circumstances. Vulnerabilities
may not violate either the system's security model or any
security objectives.
INFORMATIONAL Informational findings are not that much of a serious threat.

These findings are provided to let you know what information is
available by default to anyone enumerating the URL/ IP.
Informational findings don’t need any actions. But if you want to
make sure that no information is leaked out, then hide all basic
information.
08
The following vulnerabilities were found within each risk level. Risk level depends upon the
severity of the vulnerabilities found.
0 Critical 0 High 1 Medium 8 Low 5 Informational
Total Vulnerabilities: 14
Vulnerability Name Risk Level
C.1.1 Web Application Vulnerable to Clickjacking MEDIUM
Asset (s) impacted:
https://reliancehomecomfort.com/toronto
CVSS Score: 4.96
Vulnerability Standard:
CWE ID: 693
Description:
The web application allows itself to be embedded in other web

applications using HTML frames/iframes. An attacker may be able to
exploit this by embedding the web application into a webpage they
control and using this to get the user to interact with it without their
knowledge. This type of attack is known as clickjacking, and can be
used to trick users into changing their password etc. without realising
they are doing so. The X-Frame-Options HTTP header can help to
mitigate this by preventing the web application from being embedded
within another in this way. Setting the value to DENY will prevent
embedding of the web application anywhere. Setting the value to
SAMEORIGIN will only permit embedding by web applications hosted at
the same origin. The Content Security Policy (CSP) standard also
supports clickjacking mitigation via the 'frame-ancestors' directive.
Recommendation:
Return appropriate X-Frame-Options and/or Content-Security-Policy

HTTP headers in application responses.
CVSS Vector: CVSS2#AV:N/AC:L/Au:N/C:N/I:P/A:N
References:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-
09
Frame-Options
https://content-security-policy.com/frame-ancestors/
https://owasp.org/www-project-web-security-testing-guide/v41/4-
Web_Application_Security_Testing/11-Client_Side_Testing/09-
Testing_for_Clickjacking
10
C.2.1 Cookies Without HttpOnly Flag Detected LOW
Asset (s) impacted:
https://reliancehc.wpenginepowered.com
CVSS Score: 3.10
CWE ID: 1004
Description:
The web application serves cookies without the HttpOnly flag enabled. If
this flag is not enabled on a cookie, an attacker can use client-side
JavaScript to read or manipulate its value. Conversely, if this flag is
enabled, the cookie is no longer accessible via client-side scripts. All
cookies not required by client-side scripts (i.e. JavaScript) should have
their HttpOnly flags set.
Recommendation:
Mark/enable the HttpOnly flag on all cookies that are not required by
client-side scripts.
CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N
References:
https://owasp.org/www-community/HttpOnly
https://portswigger.net/kb/issues/00500600_cookie-without-httponly-
flag-set
11
C.2.2 Cookies Without Secure Flag Detected LOW
Asset (s) impacted:
CVSS Score: 3.10
CWE ID: 614
Description:
The web application serves cookies to the client without their Secure
flag set. Setting the Secure flag on sensitive cookies (such as cookies
containing session IDs etc.) ensures that they will not be sent over an
unencrypted (i.e. non-HTTPS) connection, protecting the session
integrity of the user.
Recommendation:
Mark/enable the Secure flag on all cookies that contain sensitive user
information such as session IDs.
References:
https://owasp.org/www-community/controls/SecureCookieAttribute
12
C.2.3 CORS Misconfiguration Present LOW
Asset (s) impacted:
CVSS Score: 3.10
CWE ID: 16
Description:
The server appears to have a cross-origin resource sharing (CORS)

misconfiguration. Cross-origin resource sharing (CORS) describes the
process of enabling access to resources from outside the current origin
(usually a domain), by relaxing the default same-origin policy (SOP).
For instance, if JavaScript embedded in a page at example1.com/home
needs to make an API call to example2.com/api, this access would
need to be granted by the Access-Control-Allow-Origin HTTP response
header served by the web application at example2.com. While CORS
can be useful under the right circumstances (for example, for hosting
REST APIs accessible to the public) it can open a web application up to
cross-domain attacks. CORS should not be confused with anti-cross-
site request forgery (CSRF) measures, which are not directly related.
Recommendation:
Audit the CORS policy carefully, and ensure that it is not inappropriately
permissive.
References:
https://medium.com/swlh/how-cors-cross-origin-resource-sharing-
works-79f959a84f0e
https://owasp.org/www-community/attacks/
CORS_OriginHeaderScrutiny
13
C.2.4 Outdated Wordpress Plugins LOW
Asset (s) impacted:
CVSS Score: 3.10
CWE ID: 1104
Description:
A plugin is a software that contains a group of functions that can be

added to a WordPress website. They are used to extend functionality or
add new features to the WordPress websites. The remote host
WordPress application has outdated plugins installed which can be
used to exploit different attacks.
Recommendation:
Update plugins through the administrative dashboard.
CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N
References:
https://wordpress.org/
https://wordpress.org/plugins/
14
C.2.5 Sensitive Data Exposure LOW
Asset (s) impacted:
CVSS Score: 3.70
CWE ID: 200
Description:
The application exposes sensitive user data. When web applications do

not adequately protect sensitive user data, that data may become
exposed. Depending on the purpose of the web application, the
definition of "sensitive user data" may vary, potentially including include
passwords, session tokens, credit card information, private health data,
full names, IP addresses, postal addresses, and email addresses. Data
exposure commonly occurs through unsecured databases,
unauthenticated API endpoints, or forms left vulnerable to code
injection attacks.
Recommendation:
Ensure exposure of sensitive data does not continue by patching the

vulnerability that permits access to it by unauthorized parties.
CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
References:
https://owasp.org/www-project-top-ten/2017/A3_2017-
Sensitive_Data_Exposure.html
https://portswigger.net/support/using-burp-to-test-for-sensitive-
data-exposure-issues
15
C.2.6 Server Software Version(s) Disclosed LOW
Asset (s) impacted:
CVSS Score: 3.70
CWE ID: 200
Description:
The server reveals information about itself, for example, the name of
the server software running on the system and its version information.
This can present a security risk by informing attackers whether or not
the system is running old, deprecated or vulnerable software, which
can help attackers refine their attack strategies. The server can reveal
information about itself in non-standard response headers such as X-
Powered-By (which gives the name of the running server software) or
X-AspNet-Version which reveals a particular version of ASP.NET as the
technology powering the web application and by extension that the
web server is very likely to be IIS-based.
Recommendation:
As far as possible, disable all signatures that might reveal information

about the server.
CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
References:
https://www.genivia.com/doc/guide/html/index.html
https://stackoverflow.com/questions/3009631/setting-http-headers-
with-jetty
16
C.2.7 Web Application Does Not Supply a Content LOW
Security Policy
Asset (s) impacted:
https://reliancehc.wpenginepowered.com, https://
reliancehomecomfort.com/toronto
CVSS Score: 3.10
CWE ID: 693
Description:
The web application does not return a Content-Security-Policy header.

Content security policy (CSP) is a web security standard designed to
make it much harder for an attacker to exploit cross-site scripting
(XSS), clickjacking or related vulnerabilities. CSP allows the web server
to specify, through the use of the Content-Security-Policy HTTP
response header, that clients should not load CSS, JavaScript or other
page assets not specifically flagged for inclusion in the page.
Recommendation:
Return the Content-Security-Policy HTTP header in application

responses, containing an appropriate policy.
References:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
17
C.2.8 Web Application Permits MIME Type Sniffing LOW
Asset (s) impacted:
CVSS Score: 3.10
CWE ID: 693
Description:
The web application does not return an X-Content-Type-Options

header. Certain browsers may attempt to "sniff" the MIME type of pages
returned by the server, which can create an exploitable vulnerability if
the browser attempts to process a response as the incorrect MIME type,
or the response itself has been influenced by an attacker in an attempt
to deliberately deceive the MIME type sniffer. Inclusion of the X-
Content-Type-Options header with the "nosniff" value instructs the
browser to accept Content-Type headers returned by the server as
authoritative, and not to attempt MIME type sniffing.
Recommendation:
Return the X-Content-Type-Options HTTP header in application

responses with the value "nosniff".
References:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-
Content-Type-Options
18
C.3.1 Server Software Information Disclosed INFORMATIONAL
Asset (s) impacted:
CVSS Score: 0.00
CWE ID: 200
Description:
The web server reveals information about itself, for example the name
of the server software running on the system, but does not include any
version information. This can present a security risk by informing
attackers whether or not the system is running old, deprecated or
vulnerable software. Even though only the name of the server software
is revealed (e.g. apache2 or nginx) this information can help attackers
refine their attack strategies or launch spraying attacks which attempt
to exploit a multitude of vulnerabilities specific to a piece of server
software in quick succession. The server can reveal information about
itself in non-standard response headers such as X-Powered-By (which
gives the name of the running server software) or X-AspNet-Version
which reveals a particular version of ASP.NET as the technology
powering the web application and by extension that the web server is
very likely to be IIS-based.
Recommendation:
Disable all headers etc. that might reveal information about the web
server.
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N
References:
https://owasp.org/www-project-web-security-testing-guide/latest/4-
Web_Application_Security_Testing/01-Information_Gathering/02-
Fingerprint_Web_Server
19
C.3.2 Server Vulnerable to Lucky13 TLS Exploit INFORMATIONAL
Asset (s) impacted:
https://reliancehomecomfort.com/toronto, https://
reliancehc.wpenginepowered.com
CVSS Score: 0.00
CWE ID: 310
Description:
The web application seems to be vulnerable to the LUCKY13 attack.

LUCKY13 is a timing attack that can be used against servers
implementing some versions of the TLS protocol (1.1 and 1.2) that
support cipher suites that use cipher block chaining (CBC). It has the
potential to allow attackers to work out the contents of encrypted
communications between the client and server.
Recommendation:
Disable support for TLS cipher suites that use cipher block chaining
(CBC) mode.
CVSS Vector: CVSS2#AV:N/AC:L/Au:N/C:N/I:N/A:N
References:
https://en.wikipedia.org/wiki/Lucky_Thirteen_attack
https://www.openssl.org/news/vulnerabilities.html
20
C.3.3 Web Application Does Not Supply a Permissions INFORMATIONAL
Policy
Asset (s) impacted:
CVSS Score: 0.00
CWE ID: 200
Description:
The web application does not return a Permissions-Policy header. The

Permissions-Policy header (formerly named Feature-Policy) is a HTTP
response header returned by web applications that restrict the
functionality of the web application in the browser to help safeguard
against malicious behavior introduced by attackers. For example, if the
website does not need to access the microphone or camera, the
feature policy can disable the microphone/camera APIs entirely so that
a successful XSS attack would be unable to exploit them. The
Permissions-Policy header is not yet a fully-fledged web standard,
though it is widely implemented (particularly on mobile browsers,
where control over microphone/camera access is most important).
Recommendation:
Introduce a Permissions-Policy header that restricts the APIs available

to client-side code to only those necessary for the web application to
function correctly.
References:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/
Feature-Policy
21
C.3.4 Web Application Does Not Supply a Referrer Policy INFORMATIONAL
Asset (s) impacted:
CVSS Score: 0.00
CWE ID: 200
Description:
The web server does not return a Referrer-Policy header. A Referrer-

Policy header instructs the user's browser on whether or not it should
pass on information to websites linked to from the web application
about where the request originated. This can be useful, for example, for
determining how users arrive on your website and which of your other
sites they visit after they leave. The referrer policy should be audited
carefully before deploying the web application in order to ensure that
excessive information about the user's browsing habits is not leaked to
other websites unintentionally, especially over unsecured connections.
To disable referrer information completely, the Referrer-Policy header
can be set to no-referrer. Alternatively, to enable referrer information
only on the same origin, the value can be set to same-origin.
Recommendation:
Return the Referrer-Policy HTTP header in application responses,

containing an appropriate value.
References:
22
C.3.5 Web Server Vulnerable to HTTP Host Header Attack INFORMATIONAL
Asset (s) impacted:
CVSS Score: 0.00
CWE ID: 20
Description:
The "HOST" header is part of the HTTP protocol. Vulnerable applications

are vulnerable because they insert the value of this header into the
application code without proper validation. An attacker can
manipulate the Host header as seen by the web application and cause
the application to behave in unexpected ways. Developers often resort
to the exceedingly untrustworthy HTTP Host header
(_SERVER["HTTP_HOST"] in PHP).
Recommendation:
The below-mentioned host was vulnerable to host header attack, as

the site when tested for the vulnerability, showed a positive result.
References:
Web_Application_Security_Testing/07-Input_Validation_Testing/17-
Testing_for_Host_Header_Injection
23
D. Testing Methodology
1. Introduction
Penetration testing methodologies vary depending on goals, scope and customers’

specific requirements. BreachLock has adopted the best industry standards for testing -
like OWASP plus developed techniques and methodologies based on our own
experiences.
The penetration testing team used the following main methodologies depending on the
requirements:
Black Box having the following characteristics:

The penetration testing team does not possess any initial knowledge about the
target environment.
Usually, the customer provides an IP address, URL or domain addresses as a starting
point for the test.
The team emulates typical attackers’ actions who do not know the environment
(operating systems, network services, applications operations, network topology,
etc.).
Black Box testing is the most common methodology for the tests of external facing
systems and applications (like DMZ network and internet applications).
One of the critical factors in this methodology is gathering any available information
about the target environment. Passive techniques are used such as:
Passive intelligence gathering, collecting an information about application,
technologies, frameworks and APIs.
Active environment analysis: DNS enumeration, network scanning, port/ service
probing, port scanning, application scanning, OS fingerprinting, or website
spidering.
Penetration testing team can use socio-technical attacks if the client approves.
Next stage of the test is identification and analysis of possible vector attacks against
tested system or application if enough information is already available. The
penetration testing team uses fuzzing, analysis or requests and responses to/ from
tested system, and performs manual testing.
PT team verifies detected vulnerabilities to eliminate false positives.
PT team can attempt to exploit vulnerabilities, elevate privileges and attack other
parts of the system if customer approves and contractual provisions allow.
Afterwards, a detailed and comprehensive report is prepared (and undergoes QA)
which lists all problems found and suggests fixes for each one.
24
White Box (Crystal Box) having the following characteristics:
The customer furnishes detailed information about their system, usually as
documentation or interviews with those (developers, system/ application
administrators or IT architects) who know the infrastructure.
The test emulates possible actions performed by an attacker having in- depth
knowledge about the target (i.e., Advanced Persistent Threat, attacks perpetrated by
current or former employees/contractors).
Reconnaissance and intelligence gathering is reduced compared to Black Box or
Gray Box methodologies.
False positives could be confirmed after review of a part of the source code (when
source code is available for the PT team).
Other phases of the testing are common in Blackbox and Whitebox (the main
difference is the amount of knowledge about the target system).
Gray Box having the following characteristics:
This is a concatenation of White Box/Black Box.
Basic authorization into the system is granted because the goal is to test internal
system and elevate privileges if possible.
The testers can be provided with additional information about testing environment
(highlevel design, services, protocols, etc.).
This methodology is the most common for the emulation of attacks against systems
where non-privileged credentials or limited knowledge is available for an attacker.
Usually, this method is used to assess the security and effectiveness of controls of
thirdparty applications.
This mode provides an additional advantage which is providing information about
findings to a vendor. This cooperation enables performing further verification of
findings and publishing security patches for the tested system (better than
alternative workaround solutions mitigating existing risks).
25
.
2. Web Application Assessment
This methodology is based on OWASP Web Application Penetration compatible with

OWASP Testing Guide v3/v4b. The methodology consists of the following phases and
tests.
2.1 Scoping
Gathering of requirements, scope and additional information from the customer

before starting a test.
2.2 Information gathering
Conduct search engine discovery and reconnaissance for Information leakage

Fingerprint web
Review web server metalize for information leakage
Enumerate applications on a web server
Review web page comments and metadata for information leakage
Identify application entry points
Map execution paths through an application
Fingerprint web application framework
Fingerprint web application
Map network and application architecture
2.3 Configuration and deploy management testing
Network/infrastructure configuration
Application platform configuration
File extensions handling for sensitive information
26
Review old, backup and unreferenced files for sensitive information
Enumerate infrastructure and application admin interfaces
HTTP methods
HTTP strict transport security
RIA cross-domain policy
2.4 Identity management testing
Role definitions
User registration process
Account provisioning process
Account enumeration and guessable user account
Weak or unenforced username policy
2.5 Authentication testing
Credentials transported over an encrypted channel

Default credentials
A weak lockout mechanism
Bypassing authentication schema
Remember password functionality
Browser cache weakness
Weak password policy
Weak security question/answer
Weak password change or reset functionalities
Insecure authentication in alternative channel
2.6 Authorization testing
Credentials transported over an encrypted channel

Default credentials
Weak lockout mechanism
Bypassing authentication schema
Remember password functionality
Browser cache weakness
Weak password policy
Weak security question/answer
Weak password change or reset functionalities
Insecure authentication in alternative channel
2.7 Session management testing
Bypassing session management schema

Cookies attributes
Session fixation
Exposed session variables
27
Cross Site Request Forgery (CSRF)
Logout functionality
Session timeout
Session puzzling references
2.8 Data validation testing
Reflected cross-site scripting

Stored cross-site scripting
HTTP verb tampering
HTTP parameter pollution
SQL injection
Oracle
MySQL
SQL server
PostgreSQL
MS Access
NoSQL injection
LDAP injection
ORM injection
XML injection
SSI injection
XPath injection
IMAP/SMTP injection
Code injection
Local file inclusion
Remote file inclusion
Command injection
Buffer overflow
Heap overflow
Stack overflow
Format string
Incubated vulnerabilities
HTTP splitting/smuggling
2.9 Testing for error handling
Analysis of error codes

Analysis of stack traces
2.10 Testing for weak cryptography
Weak SSL/TSL Ciphers, insufficient transport layer protection

Padding oracle
Sensitive information sent via unencrypted channels
28
2.11 Business logic testing
Business logic data validation

Ability to forge requests
Integrity checks
Process timing
Number of times a function can be used
The circumvention of work flows
Defenses against application misuse
Upload of unexpected file
Upload of malicious files
2.12 Client side testing
DOM based cross site scripting

JavaScript execution
HTML injection
Client-side URL redirect
CSS injection
Client-side resource manipulation
Cross origin resource sharing
cross site flashing
clickjacking
Web sockets
Web messaging
Local storage
2.13 Reporting and presentation
Announcing detected vulnerabilities to the customer according to contractual

provisions and service-level agreement (SLA).
29
3. Vulnerabilities Classification
Classification methodology is based on OWASP Risk Rating Methodology. Each finding is

analyzed in two aspects: likelihood and impact. Every factor of this aspect has a severity
between 1 and 9.
Following factors describe likelihood:
Threat Agent Factors: The first set of factors are related to the threat agent involved.
The goal here is to estimate the likelihood of a successful attack by this group of threat
agents. Use the worst-case threat agent.
Skill level: How technically skilled is this group of threat agents? Security penetration
skills (9), network and programming skills (6), an advanced computer user (4), some
technical skills (3), no technical skills (1)
Motive: How motivated is this group of threat agents to find and exploit this
vulnerability? Low or no reward (1), possible reward (4), high reward (9)
Opportunity: What resources and opportunity are required for this group of threat
agents to find and exploit this vulnerability? full access or expensive resources
required (0), special access or resources required (4), some access or resources
required (7), no access or resources required (9)
Size: How large is this group of threat agents? Developers (2), system administrators
(2), intranet users (4), partners (5), authenticated users (6), anonymous Internet
users (9)
Vulnerability Factors: The next set of factors are related to the vulnerability involved.
The goal here is to estimate the likelihood of the particular vulnerability involved being
discovered and exploited. Assume the threat agent selected above.
Ease of discovery: How easy is it for this group of threat agents to discover this
vulnerability? Practically impossible (1), difficult (3), easy (7), automated tools
available (9)
Ease of exploit: How easy is it for this group of threat agents to exploit this
vulnerability? Theoretical (1), difficult (3), easy (5), automated tools available (9)
Awareness: How well known is this vulnerability to this group of threat agents?
Unknown (1), hidden (4), obvious (6), public knowledge (9)
Intrusion detection: How likely is an exploit to be detected? Active detection in
application (1), logged and reviewed (3), logged without review (8), not logged (9)
Following factors describe possible impact:

Technical Impact Factors: Technical impact can be broken down into factors aligned
with the traditional security areas of concern: confidentiality, integrity, availability, and
accountability. The goal is to estimate the magnitude of the impact on the system if
the vulnerabilities were to be exploited.
Loss of confidentiality: How much data could be disclosed and how sensitive is it?
Minimal non- sensitive data disclosed (2), minimal critical data disclosed (6),
30
extensive non- sensitive data disclosed (6), extensive critical data disclosed (7), all
data disclosed (9)
Loss of integrity: How much data could be corrupted and how damaged is it?
Minimal slightly corrupt data (1), minimal seriously corrupt data (3), extensive slightly
corrupt data (5), extensive seriously corrupt data (7), all data totally corrupt (9)
Loss of availability: How much service could be lost and how vital is it? Minimal
secondary services interrupted (1), minimal primary services interrupted (5),
extensive secondary services interrupted (5), extensive primary services interrupted
(7), all services completely lost (9)
Loss of accountability: Are the threat agents' actions traceable to an individual? Fully
traceable (1), possibly traceable (7), completely anonymous (9)
Business Impact Factors: The business impact stems from the technical impact, but
requires a deep understanding of what is important to the company running the
application. In general, you should be aiming to support your risks with business
impact, particularly if your audience is executive level. The business risk is what justifies
investments in fixing security problems. Many companies have an asset classification
guide and/or a business impact reference to help formalize what is important to their
business. These standards can help you focus on what's truly important for security. If
these aren't available, then talk with people who understand the business to get their
take on what's important. The factors below are common areas for many businesses,
but this area is even more unique to a company than the factors related to threat
agent, vulnerability, and technical impact.
Financial damage: How much financial damage will result from an exploit? Less than
the cost to fix the vulnerability (1), minor effect on annual profit (3), significant effect
on annual profit (7), bankruptcy (9)
Reputation damage: Would an exploit result in reputation damage that would harm
the business? Minimal damage (1), Loss of major accounts (4), loss of goodwill (5),
brand damage (9)
Non- compliance: How much exposure does non- compliance introduce? Minor
violation (2), clear violation (5), high profile violation (7)
Privacy violation: How much personally identifiable information could be disclosed?
One individual (3), hundreds of people (5), thousands of people (7), millions of
people (9)
31
E. Vulnerabilities Details and Recommendations
E.1.1. Web Application Vulnerable to Clickjacking
Risk Rating: MEDIUM
Description:
The web application allows itself to be embedded in other web applications using HTML
frames/iframes. An attacker may be able to exploit this by embedding the web
application into a webpage they control and using this to get the user to interact with it
without their knowledge. This type of attack is known as clickjacking, and can be used to
trick users into changing their password etc. without realising they are doing so. The X-
Frame-Options HTTP header can help to mitigate this by preventing the web application
from being embedded within another in this way. Setting the value to DENY will prevent
embedding of the web application anywhere. Setting the value to SAMEORIGIN will only
permit embedding by web applications hosted at the same origin. The Content Security
Policy (CSP) standard also supports clickjacking mitigation via the 'frame-ancestors'
directive.
CWE ID: 693
Asset impacted: https://reliancehomecomfort.com/toronto

1. Poc Description:
Here we can see the application is vulnerable to clickjacking.
Vulnerable URL(s):
1. https://reliancehomecomfort.com/toronto
Recommendation:
32
Return appropriate X-Frame-Options and/or Content-Security-Policy HTTP headers in
application responses.
CVSS Score: 4.96
CVSS Vector: CVSS2#AV:N/AC:L/Au:N/C:N/I:P/A:N
References:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
https://content-security-policy.com/frame-ancestors/
https://owasp.org/www-project-web-security-testing-guide/v41/4-
Web_Application_Security_Testing/11-Client_Side_Testing/09-Testing_for_Clickjacking
33
E.2.1. Cookies Without HttpOnly Flag Detected
Risk Rating: LOW
Description:
The web application serves cookies without the HttpOnly flag enabled. If this flag is not
enabled on a cookie, an attacker can use client-side JavaScript to read or manipulate its
value. Conversely, if this flag is enabled, the cookie is no longer accessible via client-side
scripts. All cookies not required by client-side scripts (i.e. JavaScript) should have their
HttpOnly flags set.
CWE ID: 1004
Asset impacted: https://reliancehc.wpenginepowered.com

1. Poc Description:
Here we can see the cookies present for the application that do not have the
HttpOnly flag enabled.
Vulnerable URL(s):
1. https://reliancehc.wpenginepowered.com/
Recommendation:
Mark/enable the HttpOnly flag on all cookies that are not required by client-side scripts.
CVSS Score: 3.10
References:
https://owasp.org/www-community/HttpOnly
https://portswigger.net/kb/issues/00500600_cookie-without-httponly-flag-set
34
E.2.2. Cookies Without Secure Flag Detected
Risk Rating: LOW
Description:
The web application serves cookies to the client without their Secure flag set. Setting the
Secure flag on sensitive cookies (such as cookies containing session IDs etc.) ensures
that they will not be sent over an unencrypted (i.e. non-HTTPS) connection, protecting the
session integrity of the user.
CWE ID: 614

1. Poc Description:
Here we can see the cookies present for the application that do not have the Secure
Flag enabled.
Vulnerable URL(s):
Recommendation:
Mark/enable the Secure flag on all cookies that contain sensitive user information such
as session IDs.
CVSS Score: 3.10
References:
35
E.2.3. CORS Misconfiguration Present
Risk Rating: LOW
Description:
The server appears to have a cross-origin resource sharing (CORS) misconfiguration.

Cross-origin resource sharing (CORS) describes the process of enabling access to
resources from outside the current origin (usually a domain), by relaxing the default
same-origin policy (SOP). For instance, if JavaScript embedded in a page at
example1.com/home needs to make an API call to example2.com/api, this access would
need to be granted by the Access-Control-Allow-Origin HTTP response header served by
the web application at example2.com. While CORS can be useful under the right
circumstances (for example, for hosting REST APIs accessible to the public) it can open a
web application up to cross-domain attacks. CORS should not be confused with anti-
cross-site request forgery (CSRF) measures, which are not directly related.
CWE ID: 16

1. Poc Description:
The asset has a wildcard (*) CORS policy, but does not seem to provide an API
intended for general public use.Consider explicitly whitelisting domains you wish to
be able to make cross-origin calls to this application.
Vulnerable URL(s):
1. https://reliancehc.wpenginepowered.com/wp-content/themes/reliance_theme/
dist/images/play_btn_b05ffc53.svg
Recommendation:
Audit the CORS policy carefully, and ensure that it is not inappropriately permissive.
36
CVSS Score: 3.10
References:
https://medium.com/swlh/how-cors-cross-origin-resource-sharing-
works-79f959a84f0e
https://owasp.org/www-community/attacks/CORS_OriginHeaderScrutiny
37
E.2.4. Outdated Wordpress Plugins
Risk Rating: LOW
Description:
A plugin is a software that contains a group of functions that can be added to a

WordPress website. They are used to extend functionality or add new features to the
WordPress websites. The remote host WordPress application has outdated plugins
installed which can be used to exploit different attacks.
CWE ID: 1104

1. Poc Description:
Here we can see several outdated WordPress plugins present.
Vulnerable URL(s):
Recommendation:
Update plugins through the administrative dashboard.
CVSS Score: 3.10
CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N
38
References:
https://wordpress.org/
https://wordpress.org/plugins/
39
E.2.5. Sensitive Data Exposure
Risk Rating: LOW
Description:
The application exposes sensitive user data. When web applications do not adequately
protect sensitive user data, that data may become exposed. Depending on the purpose
of the web application, the definition of "sensitive user data" may vary, potentially
including include passwords, session tokens, credit card information, private health data,
full names, IP addresses, postal addresses, and email addresses. Data exposure
commonly occurs through unsecured databases, unauthenticated API endpoints, or
forms left vulnerable to code injection attacks.
CWE ID: 200

1. Poc Description:
Here we can see the application exposes the /wp-json endpoint. This can allow for an
attacker to enumerate through all installed plugins and themes.
Vulnerable URL(s):
1. https://reliancehomecomfort.com/wp-json
Recommendation:
Ensure exposure of sensitive data does not continue by patching the vulnerability that
40
permits access to it by unauthorized parties.
CVSS Score: 3.70
CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
References:
https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure.html
https://portswigger.net/support/using-burp-to-test-for-sensitive-data-exposure-issues
41
E.2.6. Server Software Version(s) Disclosed
Risk Rating: LOW
Description:
The server reveals information about itself, for example, the name of the server software
running on the system and its version information. This can present a security risk by
informing attackers whether or not the system is running old, deprecated or vulnerable
software, which can help attackers refine their attack strategies. The server can reveal
information about itself in non-standard response headers such as X-Powered-By
(which gives the name of the running server software) or X-AspNet-Version which
reveals a particular version of ASP.NET as the technology powering the web application
and by extension that the web server is very likely to be IIS-based.
CWE ID: 200

1. Poc Description:
Here we can see the application discloses the use of "W3 Total Cache/2.21".
Vulnerable URL(s):
Recommendation:
As far as possible, disable all signatures that might reveal information about the server.
CVSS Score: 3.70
CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
42
References:
https://www.genivia.com/doc/guide/html/index.html
https://stackoverflow.com/questions/3009631/setting-http-headers-with-jetty
43
E.2.7. Web Application Does Not Supply a Content Security Policy
Risk Rating: LOW
Description:
The web application does not return a Content-Security-Policy header. Content security
policy (CSP) is a web security standard designed to make it much harder for an attacker
to exploit cross-site scripting (XSS), clickjacking or related vulnerabilities. CSP allows the
web server to specify, through the use of the Content-Security-Policy HTTP response
header, that clients should not load CSS, JavaScript or other page assets not specifically
flagged for inclusion in the page.
CWE ID: 693

1. Poc Description:
The host does not pass back a Content-Security-Policy header in HTTP responses.
Vulnerable URL(s):

2. Poc Description:
Here we can see the application does not return a "Content-Security-Policy" header.
Vulnerable URL(s):
44
Recommendation:
Return the Content-Security-Policy HTTP header in application responses, containing an

appropriate policy.
CVSS Score: 3.10
References:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
45
E.2.8. Web Application Permits MIME Type Sniffing
Risk Rating: LOW
Description:
The web application does not return an X-Content-Type-Options header. Certain

browsers may attempt to "sniff" the MIME type of pages returned by the server, which can
create an exploitable vulnerability if the browser attempts to process a response as the
incorrect MIME type, or the response itself has been influenced by an attacker in an
attempt to deliberately deceive the MIME type sniffer. Inclusion of the X-Content-Type-
Options header with the "nosniff" value instructs the browser to accept Content-Type
headers returned by the server as authoritative, and not to attempt MIME type sniffing.
CWE ID: 693

1. Poc Description:
Here we can see the application does not return the "X-Content-Type-Options"
header.
Vulnerable URL(s):
1. https://reliancehc.wpenginepowered.com

2. Poc Description:
Here we can see the application does not return the "X-Content-Type-Options"
header.
Vulnerable URL(s):
46
Recommendation:
Return the X-Content-Type-Options HTTP header in application responses with the value
"nosniff".
CVSS Score: 3.10
References:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
47
E.3.1. Server Software Information Disclosed
Risk Rating: INFORMATIONAL
Description:
The web server reveals information about itself, for example the name of the server
software running on the system, but does not include any version information. This can
present a security risk by informing attackers whether or not the system is running old,
deprecated or vulnerable software. Even though only the name of the server software is
revealed (e.g. apache2 or nginx) this information can help attackers refine their attack
strategies or launch spraying attacks which attempt to exploit a multitude of
vulnerabilities specific to a piece of server software in quick succession. The server can
reveal information about itself in non-standard response headers such as X-Powered-By
(which gives the name of the running server software) or X-AspNet-Version which
reveals a particular version of ASP.NET as the technology powering the web application
and by extension that the web server is very likely to be IIS-based.
CWE ID: 200

1. Poc Description:
Here we can see the server discloses the use of "Apache".
Vulnerable URL(s):
Recommendation:
Disable all headers etc. that might reveal information about the web server.
48
CVSS Score: 0.00
References:
Web_Application_Security_Testing/01-Information_Gathering/02-
Fingerprint_Web_Server
49
E.3.2. Server Vulnerable to Lucky13 TLS Exploit
Description:
The web application seems to be vulnerable to the LUCKY13 attack. LUCKY13 is a timing
attack that can be used against servers implementing some versions of the TLS protocol
(1.1 and 1.2) that support cipher suites that use cipher block chaining (CBC). It has the
potential to allow attackers to work out the contents of encrypted communications
between the client and server.
CWE ID: 310

1. Poc Description:
Here we can see the application supports the use of CBC ciphers.
Vulnerable URL(s):

2. Poc Description:
Here we can see the application supports the use of CBC ciphers.
Vulnerable URL(s):
50
Recommendation:
Disable support for TLS cipher suites that use cipher block chaining (CBC) mode.
CVSS Score: 0.00
References:
https://en.wikipedia.org/wiki/Lucky_Thirteen_attack
https://www.openssl.org/news/vulnerabilities.html
51
E.3.3. Web Application Does Not Supply a Permissions Policy
Description:
The web application does not return a Permissions-Policy header. The Permissions-Policy
header (formerly named Feature-Policy) is a HTTP response header returned by web
applications that restrict the functionality of the web application in the browser to help
safeguard against malicious behavior introduced by attackers. For example, if the
website does not need to access the microphone or camera, the feature policy can
disable the microphone/camera APIs entirely so that a successful XSS attack would be
unable to exploit them. The Permissions-Policy header is not yet a fully-fledged web
standard, though it is widely implemented (particularly on mobile browsers, where
control over microphone/camera access is most important).
CWE ID: 200

1. Poc Description:
Here we can see the application does not return a "Permissions-Policy" header.
Vulnerable URL(s):
1. https://reliancehc.wpenginepowered.com

2. Poc Description:
Here we can see the application does not return a "Permissions-Policy" header.
Vulnerable URL(s):
52
Recommendation:
Introduce a Permissions-Policy header that restricts the APIs available to client-side code
to only those necessary for the web application to function correctly.
CVSS Score: 0.00
References:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy
53
E.3.4. Web Application Does Not Supply a Referrer Policy
Description:
The web server does not return a Referrer-Policy header. A Referrer-Policy header
instructs the user's browser on whether or not it should pass on information to websites
linked to from the web application about where the request originated. This can be
useful, for example, for determining how users arrive on your website and which of your
other sites they visit after they leave. The referrer policy should be audited carefully
before deploying the web application in order to ensure that excessive information about
the user's browsing habits is not leaked to other websites unintentionally, especially over
unsecured connections. To disable referrer information completely, the Referrer-Policy
header can be set to no-referrer. Alternatively, to enable referrer information only on the
same origin, the value can be set to same-origin.
CWE ID: 200

1. Poc Description:
The host does not pass back a Referrer-Policy header in HTTP responses.
Vulnerable URL(s):
Recommendation:
Return the Referrer-Policy HTTP header in application responses, containing an

appropriate value.
CVSS Score: 0.00
54
References:
55
E.3.5. Web Server Vulnerable to HTTP Host Header Attack
Description:
The "HOST" header is part of the HTTP protocol. Vulnerable applications are vulnerable
because they insert the value of this header into the application code without proper
validation. An attacker can manipulate the Host header as seen by the web application
and cause the application to behave in unexpected ways. Developers often resort to the
exceedingly untrustworthy HTTP Host header (_SERVER["HTTP_HOST"] in PHP).
CWE ID: 20

1. Poc Description:
The server allows redirection to bing.com specifically, a behaviour reported to exist
on some Microsoft web servers.
Vulnerable URL(s):
1. http://reliancehc.wpenginepowered.com/
Recommendation:
The below-mentioned host was vulnerable to host header attack, as the site when tested
for the vulnerability, showed a positive result.
CVSS Score: 0.00
References:
56
Web_Application_Security_Testing/07-Input_Validation_Testing/17-
Testing_for_Host_Header_Injection
57

Web S1 Retest Report

Uploaded by

Copyright:

Available Formats

Web S1 Retest Report

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web S1 Retest Report

Uploaded by

Copyright:

Available Formats

Reliance Comfort Limited Partnership

( Jan 18th, 2024 To Jan 23rd, 2024 )

Engagement scope Project ID

Engagement Timeframe Pentest ID

0.1 Jan 12th, 2024 Breachlock Initial Report

0.2 Jan 22nd, 2024 Breachlock QA

1.0 Jan 23rd, 2024 Breachlock Final Report

Organization Reliance Comfort Limited Partnership

Methodology Black box

Timeline ( Jan 18th, 2024 To Jan 23rd, 2024 )

Asset(s) https://reliancehomecomfort.com/toronto, https://reliancehc.

Improbable Possible Probable

Likelihood The Likelihood is defined as the probability of a given threat exploiting

Impact A Possible impact of an occurrence of a risk.

1.1 HIGH Backup file disclosure Patched

2.1 MEDIUM User Enumeration Possible Patched

2.2 MEDIUM Web Application Vulnerable to Clickjacking Unpatched

2.3 MEDIUM Web Server has HSTS Disabled Patched

3.1 LOW Cookies Without HttpOnly Flag Detected Unpatched

3.2 LOW Cookies Without Secure Flag Detected Unpatched

3.3 LOW CORS Misconfiguration Present Unpatched

3.4 LOW No DMARC Policy Supplied in Web Patched

3.5 LOW Outdated Wordpress Plugins Unpatched

3.6 LOW Sensitive Data Exposure Unpatched

3.7 LOW Server Software Version(s) Disclosed Unpatched

3.8 LOW Web Application Does Not Supply a Content Unpatched

3.9 LOW Web Application Permits MIME Type Sniffing Unpatched

4.1 INFORMAT All Cookies found Patched

4.2 INFORMAT Discovered host Patched

4.4 INFORMAT Email Addresses Disclosed Patched

4.5 INFORMAT Html Comment Patched

4.6 INFORMAT Server Software Information Disclosed Unpatched

4.7 INFORMAT Server Vulnerable to Lucky13 TLS Exploit Unpatched

4.8 INFORMAT Service Provider Patched

4.9 INFORMAT TLS/SSL Certificate Does Not Support the Patched

4.10 INFORMAT Web Application Does Not Supply a Unpatched

4.11 INFORMAT Web Application Does Not Supply a Referrer Unpatched

4.12 INFORMAT Web Application Firewall Present Patched

4.13 INFORMAT Web Server Vulnerable to HTTP Host Header Unpatched

CRITICAL Critical risk vulnerabilities could be expected to have a very high

HIGH High risk vulnerabilities could be expected to have a

MEDIUM Medium risk vulnerabilities could be expected to have a serious

INFORMATIONAL Informational findings are not that much of a serious threat.

0 Critical 0 High 1 Medium 8 Low 5 Informational

Vulnerability Name Risk Level

C.1.1 Web Application Vulnerable to Clickjacking MEDIUM

Asset (s) impacted:

CVSS Score: 4.96

CWE ID: 693

The web application allows itself to be embedded in other web

Return appropriate X-Frame-Options and/or Content-Security-Policy

CVSS Vector: CVSS2#AV:N/AC:L/Au:N/C:N/I:P/A:N

C.2.1 Cookies Without HttpOnly Flag Detected LOW

Asset (s) impacted:

CVSS Score: 3.10

CWE ID: 1004

CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N

C.2.2 Cookies Without Secure Flag Detected LOW

Asset (s) impacted:

CVSS Score: 3.10