Security Testing Report: Snakerr

SECURITY TESTING REPORT
Snakerr
Tue, 21 Jan 2020 10:35:01 GMT
P1
Snakerr SECURITY TESTING REPORT
TABLE OF CONTENTS
P3 Executive Summary
P5 Testing Summary
P5 Scope
P5 Project Team
P5 Retesting History
P6 Summary of Vulnerabilities
P6 Critical Priority Vulnerabilities
P6 High Priority Vulnerabilities
P6 Medium Priority Vulnerabilities
P6 Low Priority Vulnerabilities
P6 Informational Vulnerabilities
P6 Vulnerability Details
P7 XSS on Apache HTTP Server 413 Error Pages via Malformed HTTP Method
P8 API Manipulation
P10 Cookie With Secure Flag Missing
P12 Detect Unpublicized Web Pages
P14 Missing X-XSS-Protection Header
P15 Subvert Code-signing Facilities
P17 Port Scanning
P19 Robots.txt File Found
P21 Server Discloses Supporting Technology
P23 Appendix: Overview Explained
P24 Appendix: Severity Definitions
P25 Appendix: Testcases
P36 Appendix: Vulnerability-to-Asset Mapping
P37 Appendix: Asset-to-Vulnerability Mapping
P2
EXECUTIVE SUMMARY
Security Testing Overview
For more information on what this all means, please refer to APPENDIX: OVERVIEW EXPLAINED.
1 0 5 3
220
0 0 220 0
P3
P4
TESTING SUMMARY
START PROGRESS END

Sat Jan 18 2020 0% Sun Jan 19 2020
Total Vulnerabilities For All Assets - 9

Total Fixed Vulnerabilities For All Assets - 0
Total Vulnerabilities Retesting For All Assets - 0
Total Not Fixed Vulnerabilities For All Assets - 9
ASSETS TESTED
1. snakerr.com
PROJECT TEAM
Hasan Mahmud
RETESTING HISTORY
No retesting performed.
P5
VULNERABILITIES
CRITICAL
1. [Not Fixed] XSS on Apache HTTP Server 413 Error Pages via Malformed HTTP Method
total assets affected: 1 - fixed: 0 - retesting: 0 - not fixed: 1
HIGH
No High vulnerabilities
MEDIUM
2. [Not Fixed] API Manipulation
3. [Not Fixed] Cookie With Secure Flag Missing
4. [Not Fixed] Detect Unpublicized Web Pages
5. [Not Fixed] Missing X-XSS-Protection Header
6. [Not Fixed] Subvert Code-signing Facilities
LOW
7. [Not Fixed] Port Scanning
8. [Not Fixed] Robots.txt File Found
9. [Not Fixed] Server Discloses Supporting Technology
INFORMATIONAL
No Informational vulnerabilities
P6
VULNERABILITY PRIORITY
1. XSS on Apache HTTP Server 413 Error Pages via Malformed Critical
HTTP Method
EASILY EXPLOITABLE
DESCRIPTION
It is possible to cause Apache HTTP server to return client-supplied scripting code by submitting a malformed HTTP
method which would actually carry the payload (i.e.: malicious JavaScript) and invalid length data. Consult web
references for more information about this vulnerability.
ATTACK SCENARIO
This type of attack can result in non-persistent defacement of the target site, or the redirection of confidential
information (i.e. session IDs) to unauthorised third parties provided that a web browser is tricked to submit a malformed
HTTP method. In order to exploit this for cross-site scripting, the attacker would have to get the victim to supply an
arbitrary malformed HTTP method to a target site.
RECOMMENDATION
Upgrade to the latest version of Apache server.
TAGS
Web Application
AFFECTED ASSETS
1. snakerr.com
NOTES
Vulnerability Remediation
Input validation and Output Sanitization can completely prevent Cross Site Scripting (XSS) attacks. XSS attacks can be
mitigated in future by properly following a secure coding methodology. The following comprehensive resource provides
detailed information on fixing this vulnerability. https://www.owasp.org/index.php/
XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
STEPS TO REPRODUCE
An attacker will be able to steal cookies, deface web application or redirect to any third party address that can serve
malware.
P7
2. API Manipulation Medium
EASILY EXPLOITABLE
DESCRIPTION
An adversary manipulates the use or processing of an Application Programming Interface (API) resulting in an adverse
impact upon the security of the system implementing the API. This can allow the adversary to execute functionality not
intended by the API implementation, possibly compromising the system which integrates the API. API manipulation can
take on a number of forms including forcing the unexpected use of an API, or the use of an API in an unintended way.
For example, an adversary may make a request to an application that leverages a non-standard API that is known to
incorrectly validate its data and thus it may be manipulated by supplying metacharacters or alternate encodings as
input, resulting in any number of injection flaws, including SQL injection, cross-site scripting, or command execution.
Another example could be API methods that should be disabled in a production application but were not, thus
exposing dangerous functionality within a production environment.
TAGS
CAPEC-113
AFFECTED ASSETS
1. snakerr.com
STEPS TO REPRODUCE
jlhjlhljhl
SCREENSHOTS
P8
cYber aeronautYcs80x80.png
P9
3. Cookie With Secure Flag Missing Medium
DESCRIPTION
If the secure flag is set on a cookie, then browsers will not submit the cookie in any requests that use an unencrypted
HTTP connection, thereby preventing the cookie from being trivially intercepted by an attacker monitoring network
traffic.
If the secure flag is not set, then the cookie will be transmitted in clear-text if the user visits any HTTP URLs within the
cookie's scope. An attacker may be able to induce this event by feeding a user suitable links, either directly or via
another web site. Even if the domain which issued the cookie does not host any content that is accessed over HTTP, an
attacker may be able to use links of the form http://example.com:443/ to perform the same attack. Secure flag on
cookies is often either misconfigured or overlooked during application development and subsequently transferred to
the production environment.
ATTACK SCENARIO
An attacker may be able to force the users browser to make a request through the use of other application or server
weaknesses, over an insecure channel. As the cookie is not protected by the secure attribute, the browser will honour
this request, passing the unprotected session cookie. The cookie value may then be disclosed to other parties when
passed over the insecure channel. This issue cannot be exploited alone an attacker must exploit a secondary attack
vector, such as a man-in-the-middle attack or cross-site scripting to exploit this issue. This issue alone provides minimal
benefit to an attacker. However, this makes it easier for an attacker to exploit issues such as cross-site scripting.
RECOMMENDATION
The secure flag should be set on all cookies that are used for transmitting sensitive data when accessing content over
HTTPS. Session tokens in use should never be transmitted over unencrypted communications.
TAGS
Web Application
AFFECTED ASSETS
1. snakerr.com
NOTES
We recommend reconfiguring the web server in order to set the flag(s) HttpOnly to all sensitive cookies.
STEPS TO REPRODUCE
Lack of the `HttpOnly` flag permits the browser to access the cookie from client-side scripts (ex. JavaScript, VBScript,
etc). This can be exploited by an attacker in conjuction with a Cross-Site Scripting (XSS) attack in order to steal the
affected cookie. If this is a session cookie, the attacker could gain unauthorized access to the victim's web session.
P10
SCREENSHOTS
Screenshot at 2020-01-21 16-29-49.png
P11
4. Detect Unpublicized Web Pages Medium
DESCRIPTION
An attacker searches a targeted web site for web pages that have not been publicized. Generally this involves mapping
the published web site by spidering through all the published links and then attempt to access well-known debugging
or logging pages, or otherwise predictable pages within the site tree. For example, if an attacker might be able to
notice a pattern in the naming of documents and extrapolate this pattern to discover additional documents that have
been created but are no longer externally linked. Using this, the attacker may be able to gain access to information that
the targeted site did not intend to make public.
TAGS
CAPEC-143
AFFECTED ASSETS
1. snakerr.com
REMEDIATION NOTES
Mon, 20 Jan 2020 13:20:12 GMT - Ensure proper restrictions are in place, or remove the file if the file is not required.
STEPS TO REPRODUCE
##### Description:
An information disclosure vulnerability exists in the remote web server due to the disclosure of the web.config file. An
unauthenticated, remote attacker can exploit this, via a simple GET request, to disclose potentially sensitive
configuration information.
I was able to exploit the issue using the following request :
GET /web.config HTTP/1.1

Host: snakerr.com
Accept-Charset: iso-8859-1,utf-8;q=0.9,\*;q=0.1
Accept-Language: en
Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, \*/\* P12
This produced the following truncated output (limited to 5 lines) :

\------------------------------ snip ------------------------------

\[...\]
##### Solution
Ensure proper restrictions are in place, or remove the file if the file is not required.
SCREENSHOTS
P13
5. Missing X-XSS-Protection Header Medium
DESCRIPTION
The X-XSS-Protection HTTP Header is not set. This header enables the Cross-Site Scripting (XSS) filter built into most
recent web browsers. By setting the X-XSS-Protection header the browser is instructed to not render the page if an XSS
attack is detected. It is therefore a client-side defence mechanism.
ATTACK SCENARIO
Disabling (not using) this option increases the attack surface for XSS attacks.
RECOMMENDATION
Add the following HTTP header to all server responses: X-XSS-Protection: 1; mode=block. For more information visit
https://www.owasp.org/index.php/OWASP_Secure_Headers_Project
TAGS
CWE-693: Protection Mechanism Failure
AFFECTED ASSETS
1. snakerr.com
REMEDIATION NOTES
Mon, 20 Jan 2020 13:27:27 GMT - ecommendation:
We recommend reconfiguring the web server in order to set the flag(s) Secure, HttpOnly to all sensitive cookies.
More information about this issue:

https://blog.dareboost.com/en/2016/12/secure-cookies-secure-httponly-flags/.
Mon, 20 Jan 2020 13:27:45 GMT - We recommend reconfiguring the web server in order to set the flag(s) Secure,
HttpOnly to all sensitive cookies.

https://blog.dareboost.com/en/2016/12/secure-cookies-secure-httponly-flags/.
STEPS TO REPRODUCE
Since the `Secure` flag is not set on the cookie, the browser will send it over an unencrypted channel (plain HTTP) if
such a request is made. Thus, the risk exists that an attacker will intercept the clear-text communication between the
browser and the server and he will steal the cookie of the user. If this is a session cookie, the attacker could gain
unauthorized access to the victim's web session.
Lack of the `HttpOnly` flag permits the browser to access the cookie from client-side scripts (ex. JavaScript, VBScript,
etc). This can be exploited by an attacker in conjuction with a Cross-Site Scripting (XSS) attack in order to steal the
affected cookie. If this is a session cookie, the attacker could gain unauthorized access to the victim's web session. P14
6. Subvert Code-signing Facilities Medium
DESCRIPTION
Because languages use code signing facilities to vouch for code's identity and to thus tie code to its assigned privileges
within an environment, subverting this mechanism can be instrumental in an attacker escalating privilege.
Any means of subverting the way that a virtual machine enforces code signing classifies for this style of attack. This
pattern does not include circumstances through which a signing key has been stolen.
ATTACK SCENARIO
In old versions (prior to 3.0b4) of the Netscape web browser Attackers able to foist a malicious Applet into a client's
browser could execute the 'Magic Coat' attack. In this attack, the offending Applet would implement its own
getSigners() method. This implementation would use the containing VM's APIs to acquire other Applet's signatures (by
calling _their_ getSigners() method) and if any running Applet had privileged-enough signature, the malicious Applet
would have inherited that privilege just be (metaphorically) donning the others' coats.
Some (older) web browsers allowed scripting languages, such as JavaScript, to call signed Java code. In these
circumstances, the browser's VM implementation would choose not to conduct stack inspection across language
boundaries (from called signed Java to calling JavaScript) and would short-circuit 'true' at the language boundary. Doing
so meant that the VM would allow any (unprivileged) script to call privileged functions within signed code with impunity,
causing them to fall prey to luring attacks. The ability to load unsigned code into the kernel of earlier versions of Vista
and bypass integrity checking is an example of such subversion. In the proof-of-concept, it is possible to bypass the
signature-checking mechanism Vista uses to load device drivers.
RECOMMENDATION
A given code signing scheme may be fallible due to improper use of cryptography. Developers must never roll out their
own cryptography, nor should existing primitives be modified or ignored.
If an attacker cannot attack the scheme directly, he might try to alter the environment that affects the signing and
verification processes. A possible mitigation is to avoid reliance on flags or environment variables that are user-
controllable.
TAGS
CAPEC-68
OWASP Top 10
AFFECTED ASSETS
1. snakerr.com
NOTES
Remediation P15
It is sometimes wise to block sub domains like development, staging to the outside world, as it gives more information
to the attacker about the tech stack. Complex naming practices also help in reducing the attack surface as attackers find
hard to perform subdomain bruteforcing through dictionaries and wordlists.
STEPS TO REPRODUCE
Attackers may gather more information from subdomains relating to the parent domain. Attackers may even find other
services from the subdomains and try to learn the architecture of the target. There are even chances for the attacker to
find vulnerabilities as the attack surface gets larger with more subdomains discovered.
P16
7. Port Scanning Low
DESCRIPTION
An attacker who has gained access to a network will conduct reconnaissance to understand what services are exposed
and whether they are vulnerable or can be leveraged by the attacker to gain further foothold in the network.
The goal of port scanning is often broader than identifying open ports, but also give the attacker information
concerning the firewall configuration. Depending upon the method of scanning that is used, the process can be stealthy
or more obtrusive, the latter being more easily detectable due to the volume of packets involved, anomalous packet
traits, or system logging.
Typical port scanning activity involves sending probes to a range of ports and observing the responses. There are four
types of port status that a port scan usually attempts to discover:
- Open Port: The port is open and a firewall does not block access to the port.
- Closed Port: The port is closed (i.e. no service resides there) and a firewall does not block access to the port.
- Filtered Port: A firewall or ACL rule is blocking access to the port in some manner, although the presence of a listening
service on the port cannot be verified.
- Unfiltered Port: A firewall or ACL rule is not blocking access to the port, although the presence of a listening service
on the port cannot be verified.
For strategic purposes it is useful for an attacker to distinguish between an open port that is protected by a filter vs. a
closed port that is not protected by a filter. Making these fine grained distinctions is impossible with certain scan types.
A TCP connect scan, for instance, cannot distinguish a blocked port with an active service from a closed port that is not
firewalled. Other scan types can only detect closed ports, while others cannot detect port state at all, only the presence
or absence of filters. Collecting this type of information tells the attacker which ports can be attacked directly, which
must be attacked with filter evasion techniques like fragmentation, source port scans, and which ports are unprotected
(i.e. not firewalled) but aren't hosting a network service. An attacker often combines various techniques in order to gain
a more complete picture of the firewall filtering mechanisms in place for a host.
ATTACK SCENARIO
An attacker uses a combination of techniques to determine the state of the ports on a remote target. Any service or
application available for TCP or UDP networking will have a port open for communications over the network. Although
common services have assigned port numbers, services and applications can run on arbitrary ports. Additionally, port
scanning is complicated by the potential for any machine to have up to 65535 possible UDP or TCP services.
RECOMMENDATION
Consider disabling unnecessary services and open ports to reduce attack surface.
TAGS
CAPEC-300: Port Scanning
AFFECTED ASSETS P17

1. snakerr.com
NOTES
Recommendation:
We recommend reviewing the list of open ports and closing the ones which are not necessary for business purposes.
STEPS TO REPRODUCE
This is the list of ports that have been found open on the target hosts.
Having unnecessary open ports may expose the target systems to inutile risks because those network services and
applications may contain vulnerabilities.
SCREENSHOTS
P18
8. Robots.txt File Found Low
DESCRIPTION
The web server contains a robots.txt file. The file robots.txt is used to give instructions to web robots, such as search
engine crawlers, about locations within the web site which robots are allowed, or not allowed, to crawl and index.
ATTACK SCENARIO
The presence of the robots.txt does not in itself present any kind of security vulnerability. However, it is often used to
identify restricted or private areas of a site's contents. The information in the file may therefore help an attacker to map
out the site's contents, especially if some of the locations identified are not linked from elsewhere in the site.
RECOMMENDATION
The robots.txt file is not itself a security threat, and its correct use can represent good practice for non-security reasons.
However it is recommended to review the contents of the robots.txt file to ensure it does not disclose any informative
or sensitive information, such as restricted site directories, that may aid an attacker. In this instance, the disclosure of
'User-agent: *' can assist an attacker in crafting a specific payload to attack the application through the use of user
agent in header.
TAGS
CWE-200: Information Exposure
AFFECTED ASSETS
1. snakerr.com
NOTES
Recommendation:
We recommend you to remove the entries from robots.txt which lead to sensitive locations in the website (ex.
administration panels, configuration files, etc).

https://www.theregister.co.uk/2015/05/19/robotstxt/
STEPS TO REPRODUCE
****Risk description:****
There is no particular security risk in having a robots.txt file. However, this file is often misused to try to hide some web
pages from the users. This should not be done as a security measure because these URLs can easily be read from the
robots.txt file.
SCREENSHOTS
P19
P20
9. Server Discloses Supporting Technology Low
DESCRIPTION
The application was found to disclose supporting technology used by the server. Information disclosure is a common
and prevalent vulnerability in web applications. The disclosure of sensitive information either directly or implicitly
through application behaviour, may aid an attacker with information gathering or profiling, and determining or
establishing other vectors of attack against the application or host.
ATTACK SCENARIO
Whilst information disclosure is prevalent and easily obtained, in order to exploit this an attacker would need to
leverage this information to find publically known vulnerabilities or exploits for the identified server, or use this
information to tailor specific exploits. Using the information obtained from the HTTP header values and those disclosed
by the default messages, the attacker would then conduct research to ascertain if any publically known vulnerabilities or
exploits exist for the identified server, or use this information to tailor specific exploits.
RECOMMENDATION
Configure the web server config to not return this supporting technology information in headers.
TAGS
CWE-200: Information Exposure
AFFECTED ASSETS
1. snakerr.com
NOTES
Recommendation:
We recommend you to eliminate the information which permit the identification of software platform, technology,
server and operating system: HTTP server headers, HTML meta information, etc.

https://www.owasp.org/index.php/Fingerprint_Web_Server_(OTG-INFO-002).
STEPS TO REPRODUCE
****Risk description:****
An attacker could use this information to mount specific attacks against the identified software type and version.
SCREENSHOTS
P21
P22
APPENDIX: OVERVIEW EXPLAINED
P23
APPENDIX: SEVERITY DEFINITIONS
P24
APPENDIX: TESTCASES
COMPLETED
There are no testcases which have yet been tested.
IN PROGRESS
There are no testcases currently in progress.
NOT TESTED
["OSSTMM v3 11.3.2.A"] - Verify active responses to probes from systems and services. This could be human
or machine readable notifications, packet responses, silent alarm trips, or the like.
["OSSTMM v3 11.4.1.B"] - Use network sniffing to identify emanating protocols from network service
responses or requests where applicable. For example, Netbios, ARP, SAP, NFS, BGP, OSPF, MPLS, RIPv2, etc.
["OSSTMM v3 11.3.2.B"] - Map any applications, systems, or network segments within the scope which
produce logs, alarms, or notifications. This could include Network or Host based Intrusion Detection or
Prevention Systems, syslog, Security Information Management tools (SIMs), application logs, and the like.
["OSSTMM v3 11.4.1.C"] - Query all title servers and the title servers of the ISP or hosting provider, if
available, for corresponding A, AAAA, and PTR records as well as ability to perform zone transfers to
determine the existence of all targets in the network and any related redundancies, load
balancing, caching, proxying, and virtual hosting.
["OSSTMM v3 11.4.1.D"] - Verify broadcast requests and responses from all targets.
["OSSTMM v3 11.4.1.E"] - Verify and examine the use of traffic and routing protocols for all targets.
["OSSTMM v3 11.4.1.F"] - Verify ICMP responses for ICMP types 0-255 and ICMP codes 0-2 from all targets.
["OSSTMM v3 11.4.1.G"] - Verify default and likely SNMP community titles in use are according to practical
deployments of all SNMP versions.
["OSSTMM v3 11.4.1.H"] - Verify responses from targets to select ports with TTL expiration set to less than 1
and 2 hops from the targets. For example:
- TCP 8, 22, 23, 25, 80, 443, 445, 1433
- UDP 0, 53, 139, 161
- ICMP T00:C00, T13:C00, T15:C00, T17:C00
["OSSTMM v3 11.4.1.I"] - Trace the route of ICMP packets to all targets.
["OSSTMM v3 11.4.1.J"] - Trace the route of TCP packets to all targets for ports SSH, SMTP, HTTP, and HTTPS
ports.
["OSSTMM v3 11.4.1.K"] - Trace the route of UDP packets to all targets for DNS and SNMP ports.
["OSSTMM v3 11.4.1.L"] - Identify TCP ISN sequence number predictability for all targets.
["OSSTMM v3 11.4.1.M"] - Verify IPID increments from responses for all targets.
["OSSTMM v3 11.4.2.B"] - Examine e-mail headers, bounced mails, read receipts, mail failures, and malware
rejections
to determine outgoing gateway systems and internal addressing.
["OSSTMM v3 11.4.2.A"] - Search newsgroups, forums, IRC, IM, P2P, VoIP, and web-based communications
for
P25
connecting information of the target to determine outgoing gateway systems and internal addressing.
["OSSTMM v3 11.4.1.N"] - Verify the use of Loose Source Routing to the target gateway and outer perimeter
systems to
route packets to all targets.
["OSSTMM v3 11.4.2.C"] - Examine target web-based application source code and scripts to determine the
existence of
additional targets in the network.
["OSSTMM v3 11.4.2.D"] - Examine service and application emanations. Manipulate and replay captured
traffic to
invoke new requests or responses, gain depth, or expose additional information. For example, SQL, Citrix,
HTTP, SAP, DNS, ARP, etc.
["OSSTMM v3 11.4.2.E"] - Search web logs and intrusion logs for system trails from the target network.
["OSSTMM v3 11.4.2.F"] - Verify all responses from UDP packet requests to ports 0-65535.
["OSSTMM v3 11.4.2.G"] - Verify responses to UDP packet requests FROM SOURCE ports 0, 53, 139, and 161
to 0, 53, 69, 131, and 161.
["OSSTMM v3 11.4.2.H"] - Verify responses to UDP packet requests with BAD CHECKSUMS to all discovered
ports and for 0, 53, 69, 131, and 161.
["OSSTMM v3 11.4.2.J"] - Verify responses from TCP SYN packet requests to ports 0-65535.
["OSSTMM v3 11.4.2.I"] - Verify service request responses to common and contemporary UDP remote
access malware
ports.
["OSSTMM v3 11.4.2.K"] - Verify responses from TCP service requests to ports 0, 21, 22, 23, 25, 53, 80, and
443.
["OSSTMM v3 11.4.2.L"] - Verify responses from a TCP ACK with a SOURCE port of 80 to ports 3100-3150,
10001-10050, 33500-33550, and 50 random ports above 35000.
["OSSTMM v3 11.4.2.M"] - Verify responses from TCP SYN fragments to ports 0, 21, 22, 23, 25, 53, 80, and
443.
["OSSTMM v3 11.4.2.N"] - Verify responses from all combinations of TCP flags to ports 0, 21, 22, 23, 25, 53,
80, and 443.
["OSSTMM v3 11.4.2.O"] - Verify the use of all targets with HTTP or HTTPS based VPNs, proxies, and URL
redirectors to
redirect requests for targets within the scope.
["OSSTMM v3 11.4.2.P"] - Verify the use of all targets with sequential IPIDs to enumerate systems within the
network.
["OSSTMM v3 11.4.2.Q"] - Map and verify for consistency visible systems and responding ports by TTLs.
["OSSTMM v3 11.4.3"] - Identify targets’ TTL response, system uptime, services, applications, application
faults, and correlate this with the responses from system and service fingerprinting tools.
["OSSTMM v3 11.5.1.A"] - Request known, common services which utilize UDP for connections from all
addresses.
["OSSTMM v3 11.5.1.B"] - Request known, common VPN services including those which utilize IPSEC and IKE
for
connections from all addresses.
["OSSTMM v3 11.5.1.C"] - Manipulate network service and routing to access past restrictions within the
scope. P26
["OSSTMM v3 11.5.2.A"] - Request all service banners (flags) for discovered TCP ports.
["OSSTMM v3 11.5.2.B"] - Verify service banners (flags) through interactions with the service comprising of
both valid and invalid requests.
["OSSTMM v3 11.5.2.C"] - Match each open port to a daemon (service), application (specific code or
product which
uses the service), and protocol (the means for interacting with that service or application).
["OSSTMM v3 11.5.2.D"] - Verify system uptime compared to the latest vulnerabilities and patch releases.
["OSSTMM v3 11.5.2.E"] - Verify the application to the system and the version.
["OSSTMM v3 11.5.2.F"] - Identify the components of the listening service.
["OSSTMM v3 11.5.2.G"] - Verify service uptime compared to the latest vulnerabilities and patch releases.
["OSSTMM v3 11.5.2.H"] - Verify service and application against TTL and OS fingerprint results for all
addresses.
["OSSTMM v3 11.5.2.I"] - Verify HTTP and HTTPS for virtual hosting.
["OSSTMM v3 11.5.2.K"] - Manipulate application and service requests outside of standard boundaries to
include
special characters or special terminology of that service or application to gain access.
["OSSTMM v3 11.5.2.J"] - Verify VoIP services.
["OSSTMM v3 11.5.3.A"] - Enumerate accesses requiring authentication and document all privileges
discovered which can be used to provide access.
["OSSTMM v3 11.5.3.B"] - Verify the method of obtaining the proper Authorization for the authentication.
["OSSTMM v3 11.5.3.C"] - Verify the method of being properly Identified for being provided the
authentication.
["OSSTMM v3 11.5.3.D"] - Verify the logic method of authentication.
["OSSTMM v3 11.5.3.E"] - Verify the strength of the authentication through password cracking and re-
applying
discovered passwords to all access points requiring authentication.
["OSSTMM v3 11.5.3.F"] - Verify the process for receiving authentication.
["OSSTMM v3 11.5.3.G"] - Test for logic errors in the application of the authentication.
["OSSTMM v3 11.6.1.A"] - Test measures to access property within the scope by spoofing your network
address as one of the trusted hosts.
["OSSTMM v3 11.6.1.B"] - Verify if available caching mechanisms can be poisoned.
["OSSTMM v3 11.6.2.C"] - Examine top level domain records for domains similar to those identified within
the scope.
["OSSTMM v3 11.7.1.A"] - Enumerate and test for use or inadequacies of daemons and systems to properly
identify and
log access or interactions to property for specific evidence to challenge repudiation.
["OSSTMM v3 11.7.2.A"] - Enumerate all interactions with services within the scope for communications or
assets transported over the channel using secured lines, encryption, “quieted” or “closed” interactions to
protect the confidentiality of the information property between the involved parties.
["OSSTMM v3 11.7.3.A"] - Enumerate services within the scope for communications or assets transported
using specific, individual signatures, personal identification, “quieted” or “closed room” personal interactions
to protect the privacy of the interaction and the process of providing assets only to those within the proper
security clearance for that process, communication, or asset.
["OSSTMM v3 11.7.2.C"] - Test the strength and design of the encryption or obfuscation method. P27
["OSSTMM v3 11.7.3.B"] - Correlate information with non-responsive TCP and UDP ports to determine if
availability is dependent upon a private type of contact or protocol.
["OSSTMM v3 11.7.4"] - Enumerate and test for inadequacies of integrity where using a documented
process, signatures, encryption, hash, or markings to assure that the asset cannot be changed, redirected, or
reversed without it being known to the parties involved.
["OSSTMM v3 11.9.1.A"] - Examine controls to verify the configurations and baselines of systems, equipment
and
applications meet the intent of the organization and reflect a business justification.
["OSSTMM v3 11.9.1.B"] - Examine Access Control Lists (ACLs) and business roles configured on networks,
systems, services, and applications within the scope to ensure they meet the intent of the organization and
reflect a business justification.
["OSSTMM v3 11.9.2.C"] - Verify that Administration is done locally or with controls to limit who or what can
access the remote administration interfaces of the equipment.
["OSSTMM v3 11.9.2.B"] - Verify default settings have been changed. Some devices or applications ship with
a default or hidden administrative account. These accounts should be changed, or if possible, disabled or
deleted and replaced with a new administrative account.
["OSSTMM v3 11.9.3.A"] - Check for unnecessary or unused services/features available.
["OSSTMM v3 11.9.3.C"] - Identify if any known vulnerabilities are residing on the systems (Vulnerability
Scanning).
["OSSTMM v3 11.9.3.B"] - Check for default credentials.
["OSSTMM v3 11.11.2.B"] - Verify that private information and confidential intellectual property, such as
documents, service contracts, OS/Software keys, etc. are not available to anyone without proper privileges.
["OSSTMM v3 11.12.1.A"] - Enumerate information regarding the organization such as organization charts,
key personnel titles, job descriptions, personal and work telephone numbers, mobile phone numbers,
business cards, shared documents, resumes, organizational affiliations, private and public e-mail addresses,
log-ins, log-in schemes, passwords, back-up methods, insurers, or any particular organizational information
stated implicitly as confidential in regulations and policy.
["OSSTMM v3 11.12.1.B"] - Enumerate system, service and application exposures detailing the design, type,
version, or state on the targets or from resources outside the scope such as from postings or leaks.
["OSSTMM v3 11.14.1"] - Identify and examine quarantine methods for aggressive and hostile contacts such
as malware, rogue access points, unauthorized storage devices, etc.
["OSSTMM v3 11.15.2.A"] - Examine and verify any means for gaining fraudulent authorization to gain
privileges similar to that of other personnel.
["OSSTMM v3 11.15.2.B"] - Enumerate the use of default accounts on targets.
["OSSTMM v3 11.15.2.C"] - Test access to authenticated access points through the most appropriate and
available
cracking techniques. Password cracking via dictionary or brute-force may be limited by the time frame of the
audit and therefore not a valid test of the protection from that authentication schema however any
successful discoveries do attest to its weakness.
["OSSTMM v3 11.15.3.B"] - Verify the boundaries of privileges on the target or across multiple targets and if
the means
exists to escalate those privileges.
["OSSTMM v3 11.17.2.A"] - Document and verify unprivileged access to alarm, log, and notification storage
locations and property. P28
["OWASP ASVS v2.1"] - Verify all pages and resources by default require authentication except those
specifically intended to be public (Principle of complete mediation).
["OWASP ASVS v2.2"] - Verify that all password fields do not echo the user’s password when it is entered.
["OWASP ASVS v2.4"] - Verify all authentication controls are enforced on the server side.
["OWASP ASVS v2.9"] - Verify that the changing password functionality includes the old password, the new
password, and a password confirmation.
["OWASP ASVS v2.6"] - Verify all authentication controls fail securely to ensure attackers cannot log in.
["OWASP ASVS v2.8"] - Verify all account identity authentication functions (such as update profile, forgot
password, disabled / lost token, help desk or IVR) that might regain access to the account are at least as
resistant to attack as the primary authentication mechanism.
["OWASP ASVS v2.7"] - Verify password entry fields allow, or encourage, the use of passphrases, and do not
prevent long passphrases/highly complex passwords being entered.
["OWASP ASVS v2.12"] - Verify that all suspicious authentication decisions are logged. This should include
requests with relevant metadata needed for security investigations.
["OWASP ASVS v2.13"] - Verify that account passwords make use of a sufficient strength encryption routine
and that it withstands brute force attack against the encryption routine.
["OWASP ASVS v2.16"] - Verify that credentials are transported using a suitable encrypted link and that all
pages/functions that require a user to enter credentials are done so using an encrypted link.
["OWASP ASVS v2.17"] - Verify that the forgotten password function and other recovery paths do not reveal
the current password and that the new password is not sent in clear text to the user.
["OWASP ASVS v2.19"] - Verify there are no default passwords in use for the application framework or any
components used by the application (such as “admin/password”).
["OWASP ASVS v2.18"] - Verify that information enumeration is not possible via login, password reset, or
forgot account functionality.
["OWASP ASVS v2.20"] - Verify that request throttling is in place to prevent automated attacks against
common authentication attacks such as brute force attacks or denial of service attacks.
["OWASP ASVS v2.21"] - Verify that all authentication credentials for accessing services external to the
application are encrypted and stored in a protected location.
["OWASP ASVS v2.22"] - Verify that forgotten password and other recovery paths use a soft token, mobile
push, or an offline recovery mechanism.
["OWASP ASVS v2.23"] - Verify that account lockout is divided into soft and hard lock status, and these are
not mutually exclusive. If an account is temporarily soft locked out due to a brute force attack, this should
not reset the hard lock status.
["OWASP ASVS v2.24"] - Verify that if knowledge based questions (also known as 'secret questions') are
required, the questions should be strong enough to protect the application.
["OWASP ASVS v2.25"] - Verify that the system can be configured to disallow the use of a configurable
number of previous passwords.
["OWASP ASVS v2.26"] - Verify re-authentication, step up or adaptive authentication, two factor
authentication, or transaction signing is required before any application-specific sensitive operations are
permitted as per the risk profile of the application.
["OWASP ASVS v2.27"] - Verify that measures are in place to block the use of commonly chosen passwords
and weak passphrases.
["OWASP ASVS v2.30"] - Verify that if an application allows users to authenticate, they use a proven secure
authentication mechanism P29
["OWASP ASVS v2.31"] - Verify that if an application allows usersto authenticate, they can authenticate using
two-factor authentication or other strong authentication, or any similar scheme that provides protection
against usertitle + password disclosure.
["OWASP ASVS v3.1"] - Verify that there is no custom session manager, or that the custom session manager
is resistant against all common session management attacks.
["OWASP ASVS v3.2"] - Verify that sessions are invalidated when the user logs out.
["OWASP ASVS v2.32"] - Verify that administrative interfaces are not accessible to untrusted parties.
["OWASP ASVS v3.3"] - Verify that sessions timeout/expire after a specified period of inactivity
["OWASP ASVS v3.5"] - Verify that all pages that require authentication have easy and visible access to
logout functionality.
["OWASP ASVS v3.6"] - Verify that the session id is never disclosed in URLs, error messages, or logs. This
includes verifying that the application does not support URL rewriting of session cookies.
["OWASP ASVS v3.7"] - Verify that all successful authentication and re-authentication generates a new
session and session id.
["OWASP ASVS v3.10"] - Verify that only session ids generated by the application framework are recognized
as active by the application.
["OWASP ASVS v3.11"] - Verify that session ids are sufficiently long, random and unique across the correct
active session base.
["OWASP ASVS v3.12"] - Verify that session ids stored in cookies have their path set to an appropriately
restrictive value for the application, and authentication session tokens additionally set the 'HttpOnly' and
'Secure' attributes
["OWASP ASVS v3.16"] - Verify that the application limits the number of active concurrent sessions.
["OWASP ASVS v3.17"] - Verify that an active session list is displayed in the account profile or similar of each
user. The user should be able to terminate any active session.
["OWASP ASVS v3.18"] - Verify the user is prompted with the option to terminate all other active sessions
after a successful change password process.
["OWASP ASVS v4.1"] - Verify that the principle of least privilege exists - users should only be able to access
functions, data files, URLs, controllers, services, and other resources, for which they possess specific
authorisation. This implies protection against spoofing and elevation of privilege.
["OWASP ASVS v4.4"] - Verify that access to sensitive records is protected, such that only authorised objects
or data is accessible to each user (for example, protect against users tampering with a parameter to see or
alter another user's account).
["OWASP ASVS v4.5"] - Verify that directory browsing/indexing is disabled unless deliberately desired.
Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as
Thumbs.db, .DS_Store, .git or .svn folders.
["OWASP ASVS v4.8"] - Verify that access controls fail securely.
["OWASP ASVS v4.9"] - Verify that the same access control rules implied by the presentation layer are
enforced on the server side.
["OWASP ASVS v4.10"] - Verify that all user and data attributes and policy information used by access
controls cannot be manipulated by end users unless specifically authorized.
["OWASP ASVS v4.12"] - Verify that all access control decisions can be logged and all failed decisions are
logged.
["OWASP ASVS v4.13"] - Verify that the application orframework uses strong randomanti-CSRF tokens or has
another transaction protection mechanism. P30
["OWASP ASVS v4.14"] - Verify the system can protect against aggregate or continuous access of secured
functions, resources, or data. For example, consider the use of a resource governor to limit the number of
edits per hour or to prevent the entire database from being scraped by an individual user.
["OWASP ASVS v4.15"] - Verify the application has additional authorization (such as step up or adaptive
authentication) for lower value systems, and / or segregation of duties for high value applications to enforce
anti-fraud controls as per the risk of application and past fraud.
["OWASP ASVS v4.16"] - Verify that the application correctly enforces context-sensitive authorisation so asto
not allow unauthorised manipulation by means of parameter tampering.
["OWASP ASVS v5.1"] - Verify that the runtime environment is not susceptible to buffer overflows, or that
security controls prevent buffer overflows.
["OWASP ASVS v5.3"] - Verify that server side input validation failures result in request rejection and are
logged.
["OWASP ASVS v5.5"] - Verify that input validation routines are enforced on the server side.
["OWASP ASVS v5.10"] - Verify that all SQL queries, HQL, OSQL, NOSQL and stored procedures, calling of
stored procedures are protected by the use of prepared statements or query parameterization, and thus not
susceptible to SQL injection.
["OWASP ASVS v5.11"] - Verify that the application is not susceptible to LDAP Injection, or that security
controls prevent LDAP Injection.
["OWASP ASVS v5.12"] - Verify that the application is not susceptible to OS Command Injection, or that
security controls prevent OS Command Injection.
["OWASP ASVS v5.13"] - Verify that the application is not susceptible to Remote File Inclusion (RFI) or Local
File Inclusion (LFI) when content is used that is a path to a file.
["OWASP ASVS v5.14"] - Verify that the application is not susceptible to common XML attacks, such as XPath
query tampering, XML External Entity attacks, and XML injection attacks.
["OWASP ASVS v5.15"] - Ensure that all string variables placed into HTML or other web client code is either
properly contextually encoded manually, or utilise templates that automatically encode contextually to
ensure the application is not susceptible to reflected, stored and DOM Cross-Site Scripting (XSS) attacks.
["OWASP ASVS v5.16"] - If the application framework allows automatic mass parameter assignment (also
called automatic variable binding) from the inbound request to a model, verify that security sensitive fields
such as “accountBalance”, “role” or “password” are protected from malicious automatic binding.
["OWASP ASVS v5.17"] - Verify that the application has defenses against HTTP parameter pollution attacks,
particularly if the application framework makes no distinction about the source of request parameters (GET,
POST, cookies, headers, environment, etc.)
["OWASP ASVS v5.18"] - Verify that client side validation is used as a second line of defense, in addition to
server side validation.
["OWASP ASVS v5.19"] - Verify that all input data is validated, not only HTML form fields but all sources of
input such as REST calls, query parameters, HTTP headers, cookies, batch files, RSS feeds, etc; using positive
validation (whitelisting), then lesser forms of validation such as greylisting (eliminating known bad strings), or
rejecting bad inputs (blacklisting).
["OWASP ASVS v5.20"] - Verify that structured data is strongly typed and validated against a defined schema
including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that
two related fields are reasonable, such as validating suburbs and zip or post codes match).
["OWASP ASVS v5.21"] - Verify that unstructured data is sanitised to enforce generic safety measures such as
allowed characters and length, and characters potentially harmful in given context should be escaped (e.g.P31
natural titles with Unicode or apostrophes).

["OWASP ASVS v5.22"] - Make sure untrusted HTML from WYSIWYG editors or similar are properly sanitized
with an HTML sanitizer and handle it appropriately according to the input validation task and encoding task.
["OWASP ASVS v5.23"] - For auto-escaping template technology, if UI escaping is disabled, ensure thatHTML
sanitization is enabled instead.
["OWASP ASVS v5.24"] - Verify that data transferred from one DOM context to another, uses safe JavaScript
methods, such as using .innerText and .val.
["OWASP ASVS v5.25"] - Verify when parsing JSON in browsers, that JSON.parse is used to parse JSONon
the client. Do not use eval() to parse JSON on the client.
["OWASP ASVS v7.2"] - Verify that all cryptographic modules fail securely, and errors are handled in a way
that does not enable oracle padding.
["OWASP ASVS v5.26"] - Verify that authenticated data is cleared from client storage, such as the browser
DOM, after the session is terminated.
["OWASP ASVS v7.6"] - Verify that all random numbers, random file titles, random GUIDs, and random
strings are generated using the cryptographic module’s approved random number generator when these
random values are intended to be not guessable by an attacker.
["OWASP ASVS v7.7"] - Verify that cryptographic algorithms used by the application have been validated
against FIPS 140-2 or an equivalent standard.
["OWASP ASVS v7.9"] - Verify that there is an explicit policy for how cryptographic keys are managed (e.g.,
generated, distributed,revoked, and expired). Verify thatthis key lifecycle is properly enforced.
["OWASP ASVS v7.12"] - Personally Identifiable Information should be stored encrypted at rest and ensure
that communication goes via protected channels.
["OWASP ASVS v7.14"] - Verify that all keys and passwords are replaceable, and are generated orreplaced at
installation time.
["OWASP ASVS v7.13"] - Verify that where possible, keys and secrets are zeroed when destroyed.
["OWASP ASVS v8.1"] - Verify that the application does not output error messages orstack traces containing
sensitive data that could assist an attacker, including session id, software/framework versions and personal
information.
["OWASP ASVS v8.2"] - Verify that error handling logic in security controls denies access by default.
["OWASP ASVS v8.3"] - Verify security logging controls provide the ability to log success and particularly
failure events that are identified as security-relevant.
["OWASP ASVS v8.4"] - Verify that each log event includes necessary information that would allow for a
detailed investigation of the timeline when an event happens.
["OWASP ASVS v8.6"] - Verify that security logs are protected from unauthorized access and modification.
["OWASP ASVS v8.7"] - Verify that the application does not log sensitive data as defined underlocal privacy
laws or regulations, organizational sensitive data as defined by a risk assessment, or sensitive authentication
data that could assist an attacker, including user’s session identifiers, passwords, hashes, or API tokens.
["OWASP ASVS v8.10"] - Verify that an audit log or similar allows for non-repudiation of key transactions.
["OWASP ASVS v9.1"] - Verify that all forms containing sensitive information have disabled client side
caching, including autocomplete features.
["OWASP ASVS v9.3"] - Verify that all sensitive data is sent to the server in the HTTP message body or
headers (i.e., URL parameters are never used to send sensitive data).
["OWASP ASVS v9.4"] - Verify that the application sets appropriate anti-caching headers as per the risk of the
application, such as the following: Expires: Tue, 03 Jul 2001 06:00:00 GMT; Last-Modified: {now}; GMT Cache- P32
Control: no-store, no-cache, must-revalidate, max-age=0; Cache-Control: post-check=0, pre-check=0;

Pragma: no-cache.
["OWASP ASVS v9.7"] - Verify the application minimizes the number of parameters in a request, such as
hidden fields, Ajax variables, cookies and header values.
["OWASP ASVS v9.5"] - Verify that on the server, all cached ortemporary copies ofsensitive data stored are
protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive
data.
["OWASP ASVS v9.9"] - Verify that data stored in client side storage - such as HTML5 local storage, session
storage, IndexedDB, regular cookies or Flash cookies - does not contain sensitive data or PII.
["OWASP ASVS v9.10"] - Verify accessing sensitive data is logged, if the data is collected under relevant data
protection directives or where logging of accesses is required.
["OWASP ASVS v9.11"] - Verify that sensitive data is rapidly sanitized from memory as soon as itis no longer
needed and handled in accordance to functions and techniques supported by the framework/library/
operating system.
["OWASP ASVS v10.1"] - Verify that a path can be built from a trusted CA to each Transport Layer Security
(TLS) server certificate, and that each server certificate is valid.
["OWASP ASVS v10.3"] - Verify that TLS is used for all connections (including both external and backend
connections) that are authenticated or that involve sensitive data or functions, and does not fall back to
insecure or unencrypted protocols. Ensure the strongest alternative is the preferred algorithm.
["OWASP ASVS v10.6"] - Verify that all connections to external systems that involve sensitive information or
functions are authenticated.
["OWASP ASVS v10.11"] - Verify that HTTP Strict Transport Security headers are included on all requests and
for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains
["OWASP ASVS v10.13"] - Ensure forward secrecy ciphers are in use to mitigate passive attackers recording
traffic.
["OWASP ASVS v10.14"] - Verify that proper certification revocation, such as Online Certificate Status
Protocol (OSCP) Stapling, is enabled and configured.
["OWASP ASVS v10.15"] - Verify that only strong algorithms, ciphers, and protocols are used, through all the
certificate hierarchy, including root and intermediary certificates of your selected certifying authority. This
includes verifying weak RC4 cipher or cipher less than 128bits is not in use.
["OWASP ASVS v10.16"] - Verify that the TLS settings are in line with current leading practice, particularly as
common configurations, ciphers, and algorithms become insecure.
["OWASP ASVS v11.1"] - Verify that the application accepts only a defined set of required HTTP request
methods, such as GET and POST are accepted, and unused methods (e.g. TRACE, PUT, and DELETE) are
explicitly blocked.
["OWASP ASVS v11.2"] - Verify that every HTTP response contains a content type header specifying a safe
character set (e.g., UTF-8, ISO 8859-1).
["OWASP ASVS v11.3"] - Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer
token, are authenticated by the application.
["OWASP ASVS v11.4"] - Verify that the Content Security Policy V2 (CSP) is in use for sites where content
should not be viewed in a 3rd-party X-Frame.
["OWASP ASVS v11.5"] - Verify that the HTTP headers or any part of the HTTP response do not expose
detailed version information of system components.
["OWASP ASVS v11.6"] - Verify that all API responses contain X-Content-Type-Options: nosniff and Content- P33
Disposition: attachment; filetitle = 'api.json' (or other appropriate filetitle for the content type).
["OWASP ASVS v11.7"] - Verify that the Content Security Policy V2 (CSP) is in use in a way that either disables
inline JavaScript or provides an integrity check on inline JavaScript with CSP noncing or hashing.
["OWASP ASVS v11.8"] - Verify that the X-XSS-Protection: 1; mode=block header is in place.
["OWASP ASVS v15.1"] - Verify the application will only process business logic flows in sequential step order,
with all steps being processed in realistic human time, and not process out of order, skipped steps, process
steps from another user, or too quickly submitted transactions.
["OWASP ASVS v15.2"] - Verify the application has business limits and correctly enforces on a per user basis,
with configurable alerting and automated reactions to automated or unusual attack.
["OWASP ASVS v16.1"] - Verify that URL redirects and forwards only allow whitelisted destinations, or show a
warning when redirecting to potentially untrusted content.
["OWASP ASVS v16.2"] - Verify that untrusted file data submitted to the application is not used directly with
file I/O commands, particularly to protect against path traversal, local file include, file mime type, and OS
command injection vulnerabilities
["OWASP ASVS v16.3"] - Verify that files obtained from untrusted sources are validated to be of expected
type and scanned by antivirus scanners to prevent upload of known malicious content.
["OWASP ASVS v16.4"] - Verify that untrusted data is not used within inclusion, class loader, or reflection
capabilities to prevent remote/local file inclusion vulnerabilities.
["OWASP ASVS v16.5"] - Verify that untrusted data is not used within cross-domain resource sharing (CORS)
to protect against arbitrary remote content.
["OWASP ASVS v16.6"] - Verify that files obtained from untrusted sources are stored outside the webroot,
with limited permissions, preferably with strong validation.
["OWASP ASVS v16.7"] - Verify that the web or application serveris configured by defaultto deny access to
remote resources or systems outside the web or application server.
["OWASP ASVS v16.8"] - Verify the application code does not execute uploaded data obtained from
untrusted sources.
["OWASP ASVS v16.9"] - Do not use Flash, Active-X, Silverlight,NACL, client-side Java or other clientside
technologies not supported natively via W3C browser standards.
["OWASP ASVS v18.1"] - Verify that the same encoding style is used between the client and the server.
["OWASP ASVS v18.2"] - Verify that access to administration and management functions within the
application is limited to administrators.
["OWASP ASVS v18.3"] - Verify that XML or JSON schema is in place and verified before accepting input.
["OWASP ASVS v18.4"] - Verify that all input is limited to an appropriate size limit.
["OWASP ASVS v18.6"] - Verify the use of session-based authentication and authorisation.
["OWASP ASVS v18.5"] - Verify that SOAP based web services are compliant with Web Services-
Interoperability (WS-I) Basic Profile at minimum.
["OWASP ASVS v18.7"] - Verify that the application is protected from Cross-Site Request Forgery (CSRF).
["OWASP ASVS v18.8"] - Verify the application explicitly checks the incoming Content-Type to be the
expected one, such as application/xml or application/json.
["OWASP ASVS v18.9"] - Verify that the message payload issigned to ensure reliable transport between client
and service.
["OWASP ASVS v18.10"] - Verify that alternative and less secure access paths do not exist.
["OWASP ASVS v19.2"] - Communications between components, such as between the application server and
the database server, should be encrypted, particularly when the components are in different containers orP34
on different systems.
["OWASP ASVS v19.1"] - All components should be up to date with proper security configuration(s) and
version(s). This should include removal of unneeded configurations and folderssuch as sample applications,
platform documentation, and default or example users.
["OWASP ASVS v19.3"] - Communications between components, such as between the application server and
the database server should be authenticated using an account with the least necessary privileges.
["OWASP ASVS v19.4"] - Verify application deployments are adequately sandboxed, containerized orisolated
to delay and deter attackers from attacking other applications.
["OWASP ASVS v19.5"] - Verify that the application build and deployment processes are performed in a
secure fashion.
["AF-904-01"] - Verify application does not utilise third-party scripts from different origins.
["AF-905-01"] - Verify application sets appropriate X-Frame-Options header for all application responses,
such as DENY option.
["AF-915-02"] - Verify application is not running on an outdated version of web server.
["AF-924-01"] - Verify application does not utilise hardcoded credentials or passwords.
["AF-927-01"] - Verify application does not utilise self-signed certificate.
["AF-941-01"] - Verify application does not utilise predictable location for uploaded files.
["AF-952-01"] - Verify application uses transport layer protection if transmitting sensitive information, such as
authenticated requests.
["AF-952-03"] - Verify application server does not expose clear-text protocols for communication with server
such as FTP, Telnet & SNMPv1 & 2.
["AF-961-01"] - Verify application enforces password security policy and/or requirements.
["AF-966-01"] - Verify __VIEWSTATE parameter is encrypted.
NOT APPLICABLE
There are no testcases which are not applicable.
P35
APPENDIX: VULNERABILITY-TO-ASSET MAPPING
1. Critical XSS on Apache HTTP Server 413 Error Pages via Malformed
HTTP Method
1. Not Fixed - snakerr.com
2. Medium API Manipulation

3. Medium Cookie With Secure Flag Missing

4. Medium Detect Unpublicized Web Pages

5. Medium Missing X-XSS-Protection Header

6. Medium Subvert Code-signing Facilities

7. Low Port Scanning

8. Low Robots.txt File Found

9. Low Server Discloses Supporting Technology

P36
APPENDIX: ASSET-TO-VULNERABILITY MAPPING
1. snakerr.com
1. Critical - Not Fixed - XSS on Apache HTTP Server 413 Error Pages via Malformed HTTP Method
2. Medium - Not Fixed - API Manipulation
3. Medium - Not Fixed - Cookie With Secure Flag Missing
4. Medium - Not Fixed - Detect Unpublicized Web Pages
5. Medium - Not Fixed - Missing X-XSS-Protection Header
6. Medium - Not Fixed - Subvert Code-signing Facilities
7. Low - Not Fixed - Port Scanning
8. Low - Not Fixed - Robots.txt File Found
9. Low - Not Fixed - Server Discloses Supporting Technology
P37

Security Testing Report: Snakerr

Uploaded by

Copyright:

Available Formats

You might also like

Security Testing Report: Snakerr

Uploaded by

Document Information

Original Description:

Original Title

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

Security Testing Report: Snakerr

Uploaded by

Copyright:

Available Formats

SECURITY TESTING REPORT

Tue, 21 Jan 2020 10:35:01 GMT

P23 Appendix: Overview Explained

P24 Appendix: Severity Definitions

P25 Appendix: Testcases

P36 Appendix: Vulnerability-to-Asset Mapping

P37 Appendix: Asset-to-Vulnerability Mapping

START PROGRESS END

Total Vulnerabilities For All Assets - 9

Screenshot at 2020-01-21 16-29-49.png

I was able to exploit the issue using the following request :

GET /web.config HTTP/1.1

This produced the following truncated output (limited to 5 lines) :

Screenshot at 2020-01-21 16-10-40.png

More information about this issue:

More information about this issue:

AFFECTED ASSETS P17

Screenshot at 2020-01-21 16-21-55.png

More information about this issue:

Screenshot at 2020-01-21 16-31-58.png

More information about this issue:

Screenshot at 2020-01-21 16-33-41.png

APPENDIX: OVERVIEW EXPLAINED

APPENDIX: SEVERITY DEFINITIONS

natural titles with Unicode or apostrophes).

Control: no-store, no-cache, must-revalidate, max-age=0; Cache-Control: post-check=0, pre-check=0;

APPENDIX: VULNERABILITY-TO-ASSET MAPPING

2. Medium API Manipulation

3. Medium Cookie With Secure Flag Missing

4. Medium Detect Unpublicized Web Pages

5. Medium Missing X-XSS-Protection Header

6. Medium Subvert Code-signing Facilities

7. Low Port Scanning

8. Low Robots.txt File Found

9. Low Server Discloses Supporting Technology

APPENDIX: ASSET-TO-VULNERABILITY MAPPING

You might also like