Sample Report Templete

This is a template for the technical report, which explains all the parameters of the report.

Vulnerability Name

The essential part of a great vulnerability report would always be a descriptive title/vulnerability name, as this would be the first part checked by the security team. Therefore, always try to keep the title detailed and simple instead of complicated and short.

Vulnerability Name: Filename parameter on Home Page - "https://example.com/home" is vulnerable to Local File Inclusion (LFI)

Affected URL and Area

The affected URL/area refers to specific web addresses or sections of a website that have been identified as vulnerable. In this section, you can also mention the form or parameter details that have been identified as vulnerable. For Example:

Affected URL: https://example.com/home (Home Page) (Filename parameter)

OR

Vulnerable URL/Area: https://example.com/home - Home Page
Vulnerable Form/Parameter: Filename parameter

Vulnerability Description

The Vulnerability Description section should contain an in-depth explanation of the identified vulnerability that is relevant to the particular web application. It is important not to rely solely on general explanations found on the internet. Instead, provide specific details and context about how the vulnerability was discovered, including the methodology, tools, or techniques used, as well as any other relevant technical information. This ensures that the security team receives accurate and tailored information about the discovered vulnerability.

Vulnerability Description: The Filename parameter on the Home Page (https://example.com/home) is vulnerable to Local File Inclusion (LFI) attacks. By sending a POST request to the server with a specially crafted payload in the Filename parameter (e.g., "../../../../../../etc/passwd"), an attacker can exploit this vulnerability to disclose sensitive information from the server. This payload allows the attacker to traverse the directory structure and access system files such as the "/etc/passwd" file, which contains user account information. The lack of proper input validation and sanitization of the Filename parameter enables this security risk, exposing the application to unauthorized disclosure of sensitive serverinformation.

Severity and Risk Rating

Severity and Risk Rating are used to assess the impact and potential harm of the vulnerability on the Web Application.

Severity refers to the seriousness or degree of harm that a vulnerability can cause if exploited. It is used to prioritize vulnerabilities based on their potential impact, helping organizations understand the level of risk and urgency in addressing them. Severity ratings assist in making informed decisions regarding vulnerability remediation and risk management strategies.

Risk Rating is a measure that assesses the likelihood and potential impact of a vulnerability being exploited. It helps organizations prioritize vulnerabilities based on their level of risk, allowing them to allocate resources efficiently and address the most critical threats first.

Severity: Critical
Risk Rating: High

CVE, CWE, CVSS Score and Vulnerability Class

CVE, CWE, and CVSS Score will provide specific identification of vulnerabilities, their associated weakness categories, and a quantitative measure of their severity. This information assists organizations in understanding the nature of vulnerabilities, their potential impact, and the urgency required for their remediation.

CVE (Common Vulnerabilities and Exposures) is a dictionary that provides unique identifiers for publicly known vulnerabilities. It helps in identifying and referencing specific vulnerabilities across different platforms and tools.

CWE (Common Weakness Enumeration) is a list of common software weaknesses or vulnerabilities. It provides a standardized language to describe and categorize different types of vulnerabilities, helping in better understanding and communication.

CVSS (Common Vulnerability Scoring System) Score is a numerical value assigned to a vulnerability to assess its severity and prioritize remediation efforts. CVSS provides a consistent and standardized way of measuring the impact of vulnerabilities based on factors such as exploitability, impact on confidentiality, integrity, and availability.

Vulnerability Class A vulnerability class is a category or group of vulnerabilities that share similar characteristics or exploit methods. It helps to classify and understand different types of security weaknesses in the applicatons.

CVE: CVE-2023-31904
CWE-ID: CWE-22
CVSS Score: 8.6 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L
Vulnerability Class: Broken Access Control

Impact of Vulnerability

Impact definec the potential consequences and severity of a vulnerability if being exploited. It assesses the extent of damage or harm that could occur to the system, network, or organization. Impact considers factors such as data loss, unauthorized access, disruption of services, financial losses, reputational damage, and compliance violations. Impact of the vulnerability should be relevant to the particular web application.

Impact of Vulnerability: The vulnerability of Local File Inclusion (LFI) on the home page "https://example.com/home" can be attributed to the impact of the filename parameter. This vulnerability allows an attacker to manipulate the filename parameter in the URL to include arbitrary local files from the server. By exploiting this vulnerability, an attacker can potentially access sensitive system files, confidential information, or execute malicious code on the server.

Steps to Reproduce

Steps to reproduce helps the security team with the specific steps taken during the assessment process. Ensure the steps are detailed enough for another person or security team to follow up and replicate the findings accurately.

Steps to reproduce:
1. Go to the Home Page (https://example.com/home).
2. Select any file from the selection section.
3. Intercept the request in the Burp Suite Proxy tool and send it to the request repeater tab in Burp Suite Proxy tool.
4. Change the value of the "filename" parameter to the payload (../../../../../etcpasswd).
5. In the response section, you will be able to see the sensitive data being disclosed.

Proof of Concept (PoC)

Proof of Concept (PoC) refers to the demonstration or evidence that showcases the existence and exploitability of the vulnerability discovered. In the PoCs you should always highlight the vulnerable url and parameter as given in the below example.

image

Mitigation/Remediation

Mitigation/Remediation refers to the process of resolving a security vulnerability discovered in the application. It involves taking appropriate actions to address the root cause of the problem, implementing necessary fixes or countermeasures, and ensuring that the affected application is secure and functioning properly. Remediation could consist of general steps according to the vulnerability or could be specific to the application; this depends on the information you have.

Mitigation Steps for Local File Inclusion:

1. Implement input validation and sanitize user input to prevent the inclusion of unauthorized file paths or malicious input.

2. Avoid using user-supplied input directly in file inclusion functions. Instead, use a whitelist approach or predefined file mappings.

3. Use absolute file paths or well-defined relative paths to ensure that files are accessed from the intended locations only.

4. Apply appropriate access controls and permissions to restrict file inclusion to authorized directories or files.

5. Regularly update and patch your software and frameworks to address any known vulnerabilities.

References

In the References section, you can provide external sources that offer supporting information or documentation regarding the identified vulnerability. These references serve as additional resources for understanding the nature of the vulnerabilities, their potential impact, and the recommended remediation steps.

https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_Local_File_Inclusion#:~:text=The%20File%20Inclusion%20vulnerability%20allows,supplied%20input%20without%20proper%20validation.
https://brightsec.com/blog/local-file-inclusion-lfi/
https://www.acunetix.com/blog/articles/local-file-inclusion-lfi/

---

Here I have attached the sample vulnerability report from TCM security :

4MB

SAMPLE VAPT REPORT TCM.pdf

PDF

Open