Brisk_Sample_Website_Pentest_Report

Brisk Infosec Solutions LLP
#54, Nelson Manickam Rd, Thiruvalluvar Puram,
Choolaimedu, Chennai, Tamil Nadu,
India - 600094
Phone - 044 4352 4537
www.briskinfosec.com
www.websitepentest.com
websitepentest@briskinfosec.com
contact@briskinfosec.com
[SAMPLE WEBSITE PENTEST REPORT]
Brisk Infosec Solutions LLP pledged to secure websites which is having minimal dynamic features (i.e
Blogs, Forums, Company Websites, College and University websites, News websites etc. Our unique
security test methodology is allowing us to provide pentest service for flat $99. We are also doing
vulnerability scan and 10 months Infosec support for our Website Pentest customers. This is a sample
document to show to our customer as How we document the finding to guide our clients to secure all
vulnerability.

CONFIDENTIAL - Website Pentest Sample Report
@Copyrights by Brisk Infosec Solutions LLP
Report Details:
Title Website Penetration Testing Phase-1
Version V1.0
Author Security Engineer
Approved by Project Manager
Classification Confidential
Recipient
Name Title Company
Website Owner Name Designation Company Name
Version Control
Version Date Author Description

Contents
Report Details:........................................................................................................................................2
Recipient.................................................................................................................................................2
Version Control.......................................................................................................................................2
Executive Summary:...............................................................................................................................6
The team for this test was as follows:..................................................................................................6
Methodology ..........................................................................................................................................6
Determining the Scope:.......................................................................................................................... 7
BRISK INFOSEC SOLUTION Analysis:.................................................................................................... 7
Key strengths and weaknesses............................................................................................................ 7
High-Level Recommendation ............................................................................................................. 7
The risk is classified as follows: ...............................................................................................................8
Summary of Findings..............................................................................................................................9
OS command injection ......................................................................................................................... 12
Description....................................................................................................................................... 12
Remediation .................................................................................................................................... 12
Typical severity High..................................................................................................................... 13
Expression Language Injection.............................................................................................................. 13
Description....................................................................................................................................... 13
Proof of Concept (POC) .................................................................................................................. 13
Remediation .................................................................................................................................... 13
References ....................................................................................................................................... 13
Typical severity ................................................................................................................................ 13
local file path manipulation (DOM-based)............................................................................................. 14
Description....................................................................................................................................... 14
Remediation .................................................................................................................................... 14
REMOTE FILE INCLUDE ....................................................................................................................... 15

Description .......................................................................................................................................... 15
Proof of Concept (POC) .................................................................................................................... 15
LDAP injection...................................................................................................................................... 16
Description....................................................................................................................................... 16
Remediation .................................................................................................................................... 16
XPath injection ......................................................................................................................................17
Description........................................................................................................................................17
Proof of Concept (POC) ...................................................................................................................17
Remediation .....................................................................................................................................17
Typical severity .................................................................................................................................17
Directory listings................................................................................................................................... 18
Description....................................................................................................................................... 18
Remediation .................................................................................................................................... 18
ASP.NET tracing Enabled ..................................................................................................................... 19
Description....................................................................................................................................... 19
Remediation .................................................................................................................................... 19
Session Token in URL............................................................................................................................20
Description........................................................................................................................................20
Proof of Concept (POC) ..................................................................................................................20
Remediation ....................................................................................................................................20
Typical severity ................................................................................................................................20
PATH DISCLOSURE.............................................................................................................................. 21

Description ..........................................................................................................................................21
Proof of Concept (POC) .................................................................................................................... 21
Reference:......................................................................................................................................... 21
Source Code disclosed .......................................................................................................................... 21
Description....................................................................................................................................... 21
Remediation .................................................................................................................................... 21
Typical severity ................................................................................................................................22
File upload functionality........................................................................................................................22
Description.......................................................................................................................................22
Proof of Concept (POC) ..................................................................................................................22
Remediation ....................................................................................................................................22
References .......................................................................................................................................22
File path traversal ................................................................................................................................. 23
Description....................................................................................................................................... 23
Remediation .................................................................................................................................... 23

Executive Summary:
In accordance with the contract signed between BRISK INFOSEC SOLUTION and SAMPLE WEBSITE
the Website penetration test PART -1 was performed between ______to _______. Applications
tested for 20 working days and Reporting took 10 work hours. The application was tested against the
ASVS Security Certification Criteria as well as ensure the OWASP recommended security framework.
The scope of this test was as follows:
IP Number Domain
XX.XX.XX.XX https://XX.XX.XX.XX//
The team for this test was as follows:
Methodology
Security testing involves looking for problems on the information systems being
tested that may allow a malicious attacker to perform unwanted or undesirable
actions. Information systems are comprised of a number of different software and
hardware components. Errors in the configuration or programming of these
components may create vulnerabilities, or potential weaknesses, that may allow an
opportunity for an attacker to perform a malicious action. Different vulnerabilities
require different levels of access or skill to be successfully used in a malicious way.
An exploit is a software program that allows an attacker to leverage an existing
vulnerability to perform a malicious act against the targeted system. Exploits can
be custom developed by an advanced attacker, or exploits that have already been
written by others may be downloaded and used to attack a vulnerable system by
even the most novice attackers.
When a potential vulnerability is detected by our testing team, we will attempt to
exploit the vulnerable system to verify whether or not the risk to the system is
genuine. In some cases, particular software may be vulnerable to an exploit, but an
additional security device, such as an application layer firewall, may be in place to
block the exploit before it can reach the vulnerable system.
Test Engineer Project Lead Start Date End Date

Determining the Scope:
BRISK INFOSEC SOLUTION determining the scope of the security test along with architecture. Since
this is a SAMPLE WEBSITE Penetration test against https://XX.XX.XX.XX// using DAST and SAST.
The Penetration Tester will identify architectural diagrams, credentials, demonstrations of the
application, and was permitted communication with the target website.
BRISK INFOSEC SOLUTION Analysis:
Security test found 3 Opportunistic Risk vulnerabilities. The "Detailed Steps" section in
each Opportunistic risk is aimed at helping system/application owners to recreate the findings
by following the steps mentioned in the section
Key strengths and weaknesses
The test revealed the following strengths:
 The application directories are protected safely.
 Application has good session management practice.
High-Level Recommendation
It is recommended that an action plan should be created in order to mitigate all the
vulnerabilities found, using the solutions provided in this report. BRISK INFOSEC SOLUTION
may initiate a prioritized approach to vulnerability mitigation by fixing the opportunistic Risk
vulnerabilities followed by the Observations.
In parallel, SAMPLEWEBSITE should also incorporate the recommended changes to their
system deployment lifecycle so as to ensure that security is addressed in a sustainable and
proactive manner rather than purely addressing the list of vulnerabilities found, as a one-off
exercise.

The risk is classified as follows:
Risk
Classification
Characteristics
Critical Risk Vulnerabilities in this category usually have the following
characteristics:
 Exploitation of the vulnerability results in
root/administrator-level access to the system;
 The information required in order to exploit the
vulnerability, such as example code, is widely
available to attackers;
High Risk Vulnerabilities that score in the high range usually have the
following characteristics:
 The vulnerability is difficult to exploit;
 Exploitation does not result in elevated privileges, but
may grant unintended access to data;
 Exploitation does not result in a significant data loss.
Medium Risk Vulnerabilities that score in the medium range usually have
the following characteristics:
 Denial of service vulnerabilities that are difficult to set
up; Exploits that require an attacker to reside on the
same local network as the victim;
 Vulnerabilities that affect only nonstandard
configurations or obscure applications; Vulnerabilities
that require the attacker to manipulate individual
victims via social engineering tactics;
 Vulnerabilities where exploitation provides only very
limited access.
Low Risk Vulnerabilities in the low range typically have very little impact
on an organization's business. Exploitation of such
vulnerabilities usually requires local or physical system access.
Informational These are not vulnerabilities, but additional information
gleaned from the target during vulnerability testing.

Summary of Findings
During our security testing, we found 1 systems that were alive and had services
running. Out of these, 1 systems had at least one vulnerability.
Category Total
Systems Scanned 1
Vulnerable
Systems
1
We have identified a total of 10 vulnerabilities and informational findings. They are
presented, ordered by severity as described in Section 2 above, in the following
table:
Severity Total
Critical risk 2
High risk 0
Medium risk 4
Low risk 3
Informational 1
Total 10

The below table identifies the individual systems that have the largest number of
findings, broken down by category:
Host Critical High Medium Low Informational Total
XXX.XX.XXX.186 2 0 4 3 1 10

Top Critical Vulnerabilities Systems
The website hosts Timthumb code vulnerable to remote code
injection
1
Old and vulnerable Wordpress installation 1
Top High Vulnerabilities Systems
Top Medium Vulnerabilities Systems
Passwords sent in clear text 1
Directory indexing enabled 1
Apache 2.2 < 2.2.23 Multiple Vulnerabilities 1
PHP 5.3.x < 5.3.15 Multiple Vulnerabilities 1
Top Low Vulnerabilities Systems
Web Server robots.txt Information Disclosure 1
HTTP TRACE / TRACK Methods Allowed 1
Apache HTTP Server httpOnly Cookie Information Disclosure 1
Top Informational Vulnerabilities Systems
Web Site Cross-Domain Policy File Detection 1

OS command injection
Description
Operating system command injection vulnerabilities arise when an application
incorporates user-controllable data into a command that is processed by a shell
command interpreter. If the user data is not strictly validated, an attacker can use shell
metacharacters to modify the command that is executed, and inject arbitrary further
commands that will be executed by the server.
OS command injection vulnerabilities are usually very serious and may lead to
compromise of the server hosting the application, or of the application's own data and
functionality. It may also be possible to use the server as a platform for attacks against
other systems. The exact potential for exploitation depends upon the security context in
which the command is executed, and the privileges that this context has regarding
sensitive resources on the server.
Remediation
If possible, applications should avoid incorporating user-controllable data into operating
system commands. In almost every situation, there are safer alternative methods of
performing server-level tasks, which cannot be manipulated to perform additional
commands than the one intended.
If it is considered unavoidable to incorporate user-supplied data into operating system
commands, the following two layers of defense should be used to prevent attacks:
 The user data should be strictly validated. Ideally, a whitelist of specific accepted
values should be used. Otherwise, only short alphanumeric strings should be
accepted. Input containing any other data, including any conceivable shell
metacharacter or whitespace, should be rejected.
 The application should use command APIs that launch a specific process via its
name and command-line parameters, rather than passing a command string to a
shell interpreter that supports command chaining and redirection. For example,
the Java API Runtime.exec and the ASP.NET API Process.Start do not support shell
metacharacters. This defense can mitigate the impact of an attack even in the
event that an attacker circumvents the input validation defenses.

Typical severity High
Expression Language Injection
Description
Server-side code injection vulnerabilities arise when an application incorporates user-
controllable data into a string that is dynamically evaluated by a code interpreter. If the
user data is not strictly validated, an attacker can use crafted input to modify the code
to be executed, and inject arbitrary code that will be executed by the server.
Proof of Concept (POC)
Screen 1
Screen 2
Remediation
Whenever possible, applications should avoid incorporating user-controllable data into
dynamically evaluated code. In almost every situation, there are safer alternative
methods of implementing application functions, which cannot be manipulated to inject
arbitrary code into the server's processing.
References
 Spring Expression Language Injection
 Remote Code Execution with Spring Expression Language Injection
Typical severity
High

local file path manipulation (DOM-based)
Description
DOM-based local file path manipulation vulnerabilities arise when a client-side script
within an application's response reads data from a controllable part of the DOM (for
example, the URL), and uses this data as the filename parameter to a file handling API.
An attacker may be able to use the vulnerability to construct a URL that, if visited by
Screen 1
Screen 2
Remediation
The most effective way to avoid DOM-based local file path manipulation vulnerabilities
is not to dynamically pass a filename to a file handling API using data that originated
from any untrusted source. If the desired functionality of the application means that this
behavior is unavoidable, then defenses must be implemented within the client-side code
to prevent malicious data from accessing arbitrary files. In general, this is best achieved
by using a whitelist of permitted filenames, and strictly validating the filename against
this list before invoking the file handling API.
Typical severity
High

REMOTE FILE INCLUDE
Description
File inclusion vulnerability is a type of vulnerability most often found on websites. It allows an
attacker to include a file, usually through a script on the web server. The vulnerability occurs due to
the use of user-supplied input without proper validation. This can lead to something as minimal as
outputting the contents of the file or more serious events such as:
 Code execution on the web server
 Code execution on the client-side such as JavaScript which can lead to other attacks such
as cross site scripting (XSS)
 Denial of service (DoS)
 Data theft/manipulation
Screen 1
Screen 2
Typical severity
High

LDAP injection
Description
LDAP injection arises when user-controllable data is copied in an unsafe way into an
sLDAP query that is performed by the application. If an attacker can inject LDAP
metacharacters into the query, then they can interfere with the query's logic. Depending
on the function for which the query is used, the attacker may be able to retrieve
sensitive data to which they are not authorized, or subvert the application's logic to
perform some unauthorized action.
Note that automated difference-based tests for LDAP injection flaws can often be
unreliable and are prone to false positive results. Scanner results should be manually
reviewed to confirm whether a vulnerability is actually present.
Screen 1
Screen 2
Remediation
If possible, applications should avoid copying user-controllable data into LDAP queries.
If this is unavoidable, then the data should be strictly validated to prevent LDAP
injection attacks. In most situations, it will be appropriate to allow only short
alphanumeric strings to be copied into queries, and any other input should be rejected.
At a minimum, input containing any LDAP metacharacters should be rejected; characters
that should be blocked include ( ) ; , * | & = and whitespace.
Typical severity
High

XPath injection
Description
XPath injection vulnerabilities arise when user-controllable data is incorporated into
XPath queries in an unsafe manner. An attacker can supply crafted input to break out of
the data context in which their input appears and interfere with the structure of the
surrounding query.
Depending on the purpose for which the vulnerable query is being used, an attacker
may be able to exploit an XPath injection flaw to read sensitive application data or
interfere with application logic.
Screen 1
Screen 2s
Remediation
User input should be strictly validated before being incorporated into XPath queries. In
most cases, it will be appropriate to accept input containing only short alphanumeric
strings. At the very least, input containing any XPath metacharacters such as " ' / @ = * [
] ( and ) should be rejected.
Typical severity
High

Directory listings
Description
Web servers can be configured to automatically list the contents of directories that do
not have an index page present. This can aid an attacker by enabling them to quickly
identify the resources at a given path, and proceed directly to analyzing and attacking
those resources. It particularly increases the exposure of sensitive files within the
directory that are not intended to be accessible to users, such as temporary files and
crash dumps.
Screen 1
Screen 2
Remediation
There is not usually any good reason to provide directory listings, and disabling them
may place additional hurdles in the path of an attacker. This can normally be achieved in
two ways:
 Configure your web server to prevent directory listings for all paths beneath the
web root;
 Place into each directory a default file (such as index.htm) that the web server will
display instead of returning a directory listing.
Typical severity
Information

ASP.NET tracing Enabled
Description
ASP.NET tracing is a debugging feature that is designed for use during development to
help troubleshoot problems. It discloses sensitive information to users, and if enabled in
production contexts may present a serious security threat.
Screen 1
Screen 2
Remediation
To disable tracing, open the Web.config file for the application, and find the <trace>
element within the <system.web> section. Either set the enabled attribute to "false" (to
disable tracing) or set the localOnly attribute to "true" (to enable tracing only on the
server itself).
Note that even with tracing disabled in this way, it is possible for individual pages to
turn on page-level tracing either within the Page directive of the ASP.NET page, or
programmatically through application code. If you observe tracing output only on some
application pages, you should review the page source and the code behind, to find the
reason why tracing is occurring.
It is strongly recommended that you refer to your platform's documentation relating to
this issue, and do not rely solely on the above remediation.
Typical severity
High

Session Token in URL
Description
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 Referer 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.
Screen 1
Screen 2
Remediation
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.
Typical severity
Medium

PATH DISCLOSURE
Description
Full Path Disclosure (FPD) vulnerabilities enable the attacker to see the path to the webroot/file. e.g.:
/home/omg/htdocs/file/. Certain vulnerabilities, such as using the load_file() (within a SQL Injection)
query to view the page source, require the attacker to have the full path to the file they wish to view.
Screen 1
Screen 2
Reference:
Source Code disclosed
Description
Source code intended to be kept server-side can sometimes end up being disclosed to
users. Such code may contain sensitive information such as database passwords and
secret keys, which may help malicious users formulate attacks against the application.
Screen 1
Screen 2
Remediation
Server-side source code is normally disclosed to clients as a result of typographical
errors in scripts or because of misconfiguration, such as failing to grant executable
permissions to a script or directory. Review the cause of the code disclosure and prevent
it from happening.

Typical severity
Low
File upload functionality
Description
File upload functionality is commonly associated with a number of vulnerabilities,
including:
 File path traversal
 Persistent cross-site scripting
 Placing of other client-executable code into the domain
 Transmission of viruses and other malware
You should review file upload functionality to understand its purpose, and establish
whether uploaded content is ever returned to other application users, either through
their normal usage of the application or by being fed a specific link by an attacker.
Screen 1
Screen 2
Remediation
File upload functionality is not straightforward to implement securely. Some
recommendations to consider in the design of this functionality include:
 Use a server-generated filename if storing uploaded files on disk.
 Inspect the content of uploaded files, and enforce a whitelist of accepted, non-
executable content types. Additionally, enforce a blacklist of common executable
formats, to hinder hybrid file attacks.
 Enforce a whitelist of accepted, non-executable file extensions.
References
 Various proof-of-concept files

Typical severity
Information
File path traversal
Description
File path traversal vulnerabilities arise when user-controllable data is used within a
filesystem operation in an unsafe manner. Typically, a user-supplied filename is
appended to a directory prefix in order to read or write the contents of a file. If
vulnerable, an attacker can supply path traversal sequences (using dot-dot-slash
characters) to break out of the intended directory and read or write files elsewhere on
the filesystem.
Screen 1
Screen 2
Remediation
Ideally, application functionality should be designed in such a way that user-controllable
data does not need to be passed to filesystem operations. This can normally be
achieved by referencing known files via an index number rather than their name, and
using application-generated filenames to save user-supplied file content.
If it is considered unavoidable to pass user-controllable data to a filesystem operation,
three layers of defense can be employed to prevent path traversal attacks:
 User-controllable data should be strictly validated before being passed to any
filesystem operation. In particular, input containing dot-dot sequences should be
blocked.
Typical severity
High

Brisk_Sample_Website_Pentest_Report

Recommended

Recommended

More Related Content

Similar to Brisk_Sample_Website_Pentest_Report

Similar to Brisk_Sample_Website_Pentest_Report (20)

Brisk_Sample_Website_Pentest_Report