Pen test report

Executive Summary

Context

The objective of this security assessment is to identify and exploit the vulnerabilities of the web application, assess the security risks and provide recommendations in order to mitigate the identified risks.

Project Scope

The web application assessment was performed in the Pre-production environment. The hosts of the target application were:

• testamp.bangdb.com
• testbe.bangdb.com
• testbrs.bangdb.com
• testtrain.bangdb.com
• testuser.bangdb.com

Key Findings

A total of six low-risk findings were found, with four informational-risk issues also identified. The following is a summary of the main findings:

• Server Header Disclosure allowed an attacker to identify exact server version via HTTP response header.
• Cross-origin Resource Sharing: Arbitrary Origin Trusted possible for an attacker to carry out privileged actions and possibly retrieve sensitive information.
• API Key Stored in Session Storage could be obtained by an attacker via Cross-site Scripting attack.

Summary of Findings

The web application suffered from a number of vulnerabilities which may affect the integrity and the confidentiality of the information contained within the system. It is recommended that remedial work be taken to ensure the future operation of the system.

Vulnerabilities in the target application fell into two broad categories: security header misconfiguration and session management.

Server Header Disclosure: The application in scope produced the exact version of the web server in use in its HTTP response headers. This issue could allow an attacker to use the disclosed web server version information to gain a greater understanding of the underlying technologies involved and tailor further attacks to these specific products.

Cross-origin Resource Sharing: Arbitrary Origin Trusted: Allowing arbitrary resource origin was the instance of security header misconfiguration flaws. By exploiting this vulnerability, it would be possible for an attacker to carry out privileged actions and retrieve sensitive information as well as bypass any IP-based access controls by proxying through users' browsers.

API Key Stored in Session Storage: Most people tend to store API key in the session storage of the web browser. This tactic leaves applications open to an attack called Cross-site Scripting (XSS). So, for example, if the attacker can find a way to inject maliciously JavaScript code inside the applications via XSS attack, the API key is immediately accessible and sent to the attacker's machine.

Strategic Recommendations

• Configure the web server so that version information is not disclosed via HTTP response header in a consistent manner, regardless of whether the requested web page exists.
• Use a whitelist of trusted domains and avoid whitelisting "null" value.
• Store the API key in cookies and ensure that HTTPOnly and Secure flags are set for sensitive cookies.

Security Assessment History

Initial Security Assessment (25th December 2022)

A security assessment report generated indicates the result of the first test. By providing this report, the assessor acknowledges that there are 10 security issues open in the application. It is recommended that remedial work be taken to ensure the future operation of the system.

Overview

Assessment Methodology

Type of tests

The test can be conducted in black-box, grey-box or white-box approach. According to Open Source Security Testing Methodology Manual (OSSTMM), the three types of tests are defined as follows:

For more details, please refer to OSSTMM v3.

Risk Level Classifications

This section of the report details the severity classification system used during the assessment according toCommon Vulnerability Scoring System Version 3.1 (CVSS v3.1):

For more details, please refer to CVSS v3.1.

Detailed Engagement Data

Port Scanning Results

testamp.bangdb.com

testbe.bangdb.com

testbrs.bangdb.com

testtrain.bangdb.com

testuser.bangdb.com

Result Summary

The following table presents the total number of vulnerabilities found, sorted by severity. Common Vulnerability Scoring System Version 3.1 (CVSS v3.1) would be covered:

Table of Findings

The following table presents the total number of findings.

Web Application

For more details, please refer to CVSS v3.1.

Detailed Findings

This section of the document is technical in nature and provides further detail about the items already discussed, for the purposes of remediation and risk-assessment.

Web Application

Issue Description:

The application in scope, when encountered an unexpected error, produced the exact version of the webserver in use in its HTTP response headers. This allows an attacker to use this information to gain a greater understanding of the underlying technologies involved and tailor further attacks to these specific products.

The following response disclosed the software version of the server:

Reference:

Configuring the Web Server to Not Disclose its Identity

https://www.acunetix.com/blog/articles/configure-web-server-disclose-identity/

CWE-200: Information Exposure https://cwe.mitre.org/data/definitions/200.html

Issue Description:

An HTML5 cross-origin resource sharing (CORS) policy controls whether and how content running on other domains can perform two-way interaction with the domain that publishes the policy. The policy is finegrained and can apply access controls per-request based on the URL and other features of the request.

Trusting arbitrary origins effectively disables the same-origin policy, allowing two-way interaction by thirdparty web sites. Unless the response consists only of unprotected public content, this policy is likely to present a security risk.

If the site specifies the header Access-Control-Allow-Credentials: true, third-party sites may be able to carry out privileged actions and retrieve sensitive information. Even if it does not, attackers may be able to bypass any IP-based access controls by proxying through users' browsers.

The following pictures show that the applications accepted an arbitrary origin:

• testbe.bangdb.com:18080

• testbrs.bangdb.com

• testtrain.bangdb.com

• testuser.bangdb.com

Reference:

Cross-origin resource sharing (CORS)
https://portswigger.net/web-security/cors

Exploiting CORS misconfigurations for Bitcoins and bounties
https://portswigger.net/research/exploitingcors-misconfigurations-for-bitcoins-and-bounties

Issue Description:

Most people tend to store API key in the session storage of the web browser. This tactic leaves applications open to an attack called Cross-site Scripting (XSS). So, for example, if the attacker can find a way to inject maliciously JavaScript code inside the applications via XSS attack, the API key is immediately accessible and sent to the attacker's machine.

The following picture shows the API key was stored in web browser's session storage.

Reference

JWT authentication: Best practices and when to use it https://blog.logrocket.com/jwt-authenticationbest-practices/

How to securely store JWT tokens. https://dev.to/gkoniaris/how-to-securely-store-jwt-tokens-51cf

Issue Description:

Clickjacking (User Interface redress attack, UI redress attack, UI redressing) is a malicious technique of tricking a Web user into clicking on something different from what the user perceives they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages.

The server did not return an X-Frame-Options header which means that this website could be at risk of a clickjacking attack.

The following picture shows that the X-Frame-Options header was not present in the response:

Reference:

CWE-1021: Improper Restriction of Rendered UI Layers or Frames
https://cwe.mitre.org/data/definitions/1021.html

Clickjacking Defense
https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html

Clickjacking
http://en.wikipedia.org/wiki/Clickjacking

The X-Frame-Options response header
https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options

Issue Description:

The HTTP X-Content-Type-Options response header prevents the browser from MIME-sniffing a response away from the declared content-type.

The server did not return a correct "X-Content-Type-Options" header, which means that this website could be at risk of a Cross-Site Scripting (XSS) attack.

The following picture shows that the X-Content-Type-Options header was not present in the response:

Reference:

X-Content-Type-Options
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-TypeOptions

Issue Description:

The application fails to prevent users from connecting to it over unencrypted connections. An attacker able to modify a legitimate user's network traffic could bypass the application's use of SSL/TLS encryption, and use the application as a platform for attacks against its users. This attack is performed by rewriting HTTPS links as HTTP, so that if a targeted user follows a link to the site from an HTTP page, their browser never attempts to use an encrypted connection. The sslstrip tool automates this process.

To exploit this vulnerability, an attacker must be suitably positioned to intercept and modify the victim's network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are 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.

The following picture shows that the Strict-Transport-Security header was not present in the response:

Reference:

HTTP Strict Transport Security https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

HSTS Preload Formhttps://hstspreload.org/

Issue Description:

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks.

It was detected that the web application did not implement Content Security Policy (CSP) as the CSP header is missing from the response.

The following picture shows that the Content-Security-Policy header was not present in the response:

Reference:

Content Security Policy (CSP) Not Implemented
https://www.netsparker.com/web-vulnerabilityscanner/vulnerabilities/content-security-policy-csp-not-implemented/

Content Security Policy (CSP)
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

Issue Description:

Referrer Policy controls behaviour of the Referrer header, which indicates the origin or web page URL the request was made from. There was no Referrer Policy header that may leak user's information to thirdparty sites.

The following picture shows that the Referrer-Policy header was not present in the response:

Reference:

Referrer-Policy
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

Issue Description:

The HTTP X-XSS-Protection response header is a feature of modern browsers that allows websites to control their XSS auditors.

The server is not configured to return a X-XSS-Protection header which means that any pages on this website could be at risk of a Cross-Site Scripting (XSS) attack. This URL is flagged as a specific example.

The following picture shows that the X-XSS-Protection header was not present in the response:

Reference:

X-XSS-Protection
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

Issue Description:

Most browsers have a facility to remember user credentials that are entered into HTML forms. This function can be configured by the user and also by applications that employ user credentials. If the function is enabled, then credentials entered by the user are stored on their local computer and retrieved by the browser on future visits to the same application.

The stored credentials can be captured by an attacker who gains control over the user's computer. Further, an attacker who finds a separate application vulnerability such as cross-site scripting may be able to exploit this to retrieve a user's browser-stored credentials.

The following picture shows that the autocomplete attribute was not included in the HTML source code.

Reference:

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
https://cwe.mitre.org/data/definitions/200.html

Appendix

Tools List