xref web application and api penetration test report

Xref Web Application and API Penetration Test Report

Prepared for Xref on the 13th July 2021

Red Cursor Pty Ltd – Client Confidential 2

Table of Contents

1 Document Control ..................................................................................................... 3

1.1 Revision History ............................................................................................................... 3

1.2 Document Distribution..................................................................................................... 3

2 Executive Summary ................................................................................................... 4

3 Scope ........................................................................................................................ 6

4 Technical Summary ................................................................................................... 7

5 Detailed Technical Findings ....................................................................................... 8

5.1 Insufficient Input Validation............................................................................................. 8

5.2 Remotely Hosted Resources........................................................................................... 11

5.3 HSTS Header Missing ...................................................................................................... 14

5.4 Insecure Content Security Policy .................................................................................... 18

5.5 TCP Timestamps ............................................................................................................. 22

6 Appendices ............................................................................................................. 24

6.1 Appendix 1 – Technical Risk Calculation ......................................................................... 24

6.1.1 Impact Calculation ........................................................................................................................ 24

6.1.2 Likelihood Calculation ................................................................................................................... 25

6.1.3 Overall Technical Risk Calculation Matrix ..................................................................................... 27

6.2 Appendix 2 – Tools Used During This Test ...................................................................... 29


1 Document Control

1.1 Revision History

Version Author Date

Initial Draft v0.9 Gordon Maddern 20th April 2021

QA and Final Release v1.0 Michael Bielenberg 30th April 2021

Retesting v1.1 Michael Bielenberg 13th of July 2021

1.2 Document Distribution

Version Date Details of Distribution

Final Release v1.0 30th April 2021 Released to Xref as password protected file. Password sent via SMS

Retest Release v1.1 13th July 2021 Released to Xref as password protected file. Password sent via SMS

This document is Copyright Red Cursor Pty Ltd 2021.


2 Executive Summary

Red Cursor was engaged by Xref on the 20th of April 2021 to perform web application and API penetration testing of their Xref application. This application is used to streamline the reference checking process for employers.

This testing was designed to simulate both a malicious user on the Internet, as well as a malicious or compromised authenticated user. During the testing eight security issues were identified.

After performing retesting only 5 issues remained. The graph below shows the number and security rating of the risks identified after retesting:

Risk Summary Chart

Very High

High

Medium

Low

Informational

None of the issues found pose any significant risk.

0 1 2 3

Number of issues identified


Industry Comparison

Figure 1. Security posture relative to peers

The yellow ball on the above bell curve shows where Xref aligns relative to their peers. This is based on performing 1000’s of penetration tests, comparing similar in-house built SaaS applications, industries, and sized IT departments. The results of this penetration test are considered very good and well above average.


3 Scope

Red Cursor was engaged by Xref to perform web application and API penetration testing against their Xref application. The environment used for testing was the sandbox environment. This application is made up of multiple microservices.

Red Cursor performed both authenticated and unauthenticated testing against the applications and APIs which are located at the following URLs:

• api-app.sandbox.xref.com

• api-candidate.sandbox.xref.com

• api-help.sandbox.xref.com

• api-questionnaire.sandbox.xref.com

• api-referee.sandbox.xref.com

• api-search.sandbox.xref.com

• app.sandbox.xref.com

• auth.sandbox.xref.com

• candidate.sandbox.xref.com

• id.sandbox.xref.com

• login.sandbox.xref.com

• pages.xref.com

• referee.sandbox.xref.com

• search.sandbox.xref.com

• template-builder.sandbox.xref.com

• xref-assets.xref.com

• help.sandbox.xref.com

• api-open.xref.com

Testing was performed from the 20th to the 30th of April 2021.

Retesting was performed on the 13th of July 2021.


4 Technical Summary

This section is targeted towards Project Managers or IT Managers wishing to delegate remediation tasks to various parties. It is a summary of all vulnerabilities with related risk ratings and business impacts designed to help prioritise resourcing for remediation.

Risk Reference Business Impact

Low

5.1 - Insufficient Input Validation

The application accepts and stores in its database malicious characters and payloads. There is no risk to this application. However, secondary systems that trust and ingest this data may be affected.

Low

5.2 - Remotely

Hosted Resources

The application is using remotely hosted 3rd party JavaScript libraries. This means that a 3rd party or a compromised 3rd party has complete control over what data is taken from the site and what code gets executed.

Informational

5.3 - HSTS Header

Missing

If a user is being man-in-the-middled, they will be given the option to accept the certificate error and proceed. Most non-security aware users will click through certificate security warnings.

Informational

5.4 - Missing or Insecure Content Security Policy (CSP)

The application is missing protective mechanisms that keep it safe from cross-site scripting (XSS), clickjacking and serving mixed HTTP and HTTPS content. Having a secure Content Security Policy (CSP) is a defence in depth mechanism.

Informational

5.5 - TCP Timestamps It is possible to work out the uptime of devices. Disclosing uptimes indicates how effectively a device is patched.


5 Detailed Technical Findings

5.1 Insufficient Input Validation

Insufficient Input Validation

RISK RATING RISK CALCULATION

LOW

Likelihood:

Moderate

Consequence:

Low

DESCRIPTION OF VULNERABILITY

The application accepts malicious characters as input and does not properly validate that

the input is valid and expected.

In more serious instances this vulnerability can lead to critical vulnerabilities like SQL injections and remote code execution. However, in this instance, even though the input didn’t necessarily lead to an injection vulnerability, it was stored in the system and could cause a ‘second order injection’ vulnerability.

Second order injection vulnerabilities happen when other systems or applications use data from another application. For example, if an attacker was to enter their address in one web application as:

‘Drop table;

Then if a secondary billing or reporting system read this data, it could lead to data being destroyed in the database.

Furthermore, when stored cross site scripting payloads are used, it can cause other users to have their credentials compromised on secondary applications.

PROOF OF CONCEPT

Although not necessarily exploitable in this instance, the Xref application accepts malicious characters throughout the entire application.


In the screenshot below, Red Cursor entered a cross site scripting payload in to one of the fields:

Figure 2. Malicious characters entered into field

As shown below, the application saves the malicious input to its database and then displays it back:

Figure 3. Application accepted and stored malicious characters


The XSS payload did not execute because the application is using output encoding. However, if a secondary system such as a reporting system used this data, it may be possible to cause second order injection attacks.

BUSINESS IMPACT

The application accepts and stores in its database malicious characters and payloads. There is no risk to this application. However, secondary systems that trust and ingest this data may be affected.

REPRODUCTION STEPS

To reproduce the same results as the proof of concept:

• Enter malicious characters into any field

RECOMMENDATIONS

It is best practice to sanitise data at the point of entry. Red Cursor recommends:

• Ensuring that all user input is validated before being accepted. It is recommended to use a whitelisting approach. It is important to do this on the server because client-side validation checks can be disabled.


5.2 Remotely Hosted Resources

Remotely Hosted Resources


LOW

Likelihood:

Moderate

Consequence:

Low


The application is using 3rd party hosted JavaScript. Modern web applications use JavaScript libraries to extend functionality and enrich user experience. Developers can include these external libraries in their web applications in two ways: either

1) by downloading a copy of the library from a third-party vendor and uploading it to their own web server, or

2) by instructing the users’ browsers to fetch the code directly from a server operated by a third party

By using 3rd party hosted libraries the applications security boundary is extended to include the 3rd party. Developers need to trust that 3rd parties will not abuse their power or not become victims of hacks themselves. Furthermore, using semi trusted code opens the application up to the following risks:

• The loss of control over changes to the client application

• The execution of arbitrary code on client systems

• The disclosure or leakage of sensitive information to 3rd parties

The safest method of using 3rd party libraries is to download a local copy to the application server. This gives developers full control over what code runs on their application.

It is worth noting that in 2013 the Bootstrap CDN was compromised and served out malicious JavaScript to millions of sites:

https://opsec.readthedocs.io/en/latest/incidences/maxcdn.html

PROOF OF CONCEPT

https://opsec.readthedocs.io/en/latest/incidences/maxcdn.html


The following applications are using remotely hosted 3rd party JavaScript libraries that Xref has no control over:

• https://app.sandbox.xref.com/

• https://help.sandbox.xref.com

• https://pages.xref.com/

• https://template-builder.sandbox.xref.com/

As shown in the screenshot below the template builder application is requesting files from fast.wistia.com:

Figure 4. Remote hosted 3rd party library in use

This creates a risk in that the application’s security boundary is extended to include the 3rd party vendor and their security practices. Furthermore, developers do not have full control over changes to their application.

BUSINESS IMPACT

The application is using remotely hosted 3rd party JavaScript libraries. This means that a 3rd party or a compromised 3rd party has complete control over what data is taken from the site and what code gets executed.

REPRODUCTION STEPS


• View the page source for the application and note that the browser is calling

remotely hosted libraries.

RECOMMENDATIONS

Red Cursor recommends copying the library files locally to the application server. This way the developers have complete control over the code that is served to the users’ browsers and can inspect it to verify its proper functionality.


If it is not possible to use a local copy, then it is recommended to implement sub-resource integrity checking for remotely hosted scripts. More information on how this works can be found here:

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity


5.3 HSTS Header Missing

HSTS Header Missing


Informational

Likelihood:

Very Low

Consequence:

Very Low


HTTP Strict Transport Security (HSTS) is a HTTP header that serves two functions:

1) It helps to protect websites against protocol downgrade attacks from tools like sslstrip. It tells browsers that they should only interact with the application using only secure HTTPS connections and never via the insecure HTTP protocol. This is how the tool sslstrip works by downgrading HTTPS to HTTP connections. It will also automatically turn any insecure links referenced in the web application into secure links.

2) It prevents the user from accepting a certificate security warning if the connection is insecure.

The second function is often overlooked. Most non-security aware users will click through security warnings if an attacker is man-in-the-middling a connection. An example of this warning screen shown is below:


Figure 5. Without the HSTS header users can still use the site insecurely by clicking proceed

However, if the HSTS header is implemented, users are not able to accept the security error and visit the site as shown below:

Figure 6. With HSTS the option to proceed is not available

Adding the HSTS header to a web application can significantly decrease the likelihood of a successful man-in-the-middle attack.


PROOF OF CONCEPT

The following servers do not correctly set the HSTS Header:


• https://candidate.sandbox.xref.com/

• https://help.sandbox.xref.com/

• https://login.sandbox.xref.com/


• https://referee.sandbox.xref.com/

• https://search.sandbox.xref.com/


As an example, the screenshot below shows that responses from the app.sandbox.xref.com server do not contain the HSTS header:

Figure 7. No HSTS header returned by application

Without this security header a user can accept certificate errors.

BUSINESS IMPACT

If a user is being man-in-the-middled, they will be given the option to accept the certificate error and proceed. Most non-security aware users will click through certificate security warnings.

REPRODUCTION STEPS



• Run a local proxy like Burp Suite

• Seta browser to use the local proxy

• Browse to the application and accept the certificate warning

• Observe that the HSTS header is missing in server responses.

RECOMMENDATIONS

Red Cursor recommends adding the following header to the application:

Strict-Transport-Security: max-age=31536000


5.4 Insecure Content Security Policy

Insecure Content Security Policy


INFORMATIONAL

Likelihood:

Very Low

Consequence:

Very Low


The application is missing a Content Security Policy or has a poorly configured Content Security Policy.

Content Security Policy (CSP) is a set of security headers introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks. CSP provides a standard method for an application to declare approved origins of content that browsers should be allowed to load on that website.

By disallowing inline scripts and allowing only trusted domains as a source of external scripts, CSP restricts a site’s capability to execute malicious client-side code. Even when an attacker is capable of finding an XSS vulnerability, CSP keeps the application safe by preventing the exploitation of the bug.

In order for a CSP policy to be effective in stopping XSS attacks, preventing script execution and not by-passable it must at a minimum have the following three conditions

1. The policy must define both the script-src and object-src (or default-src in their absence)

2. The script-src source list cannot contain the unsafe-inline keyword (unless accompanied by a nonce)

3. The script-src and object-src source lists cannot contain any endpoints that allow an attacker to control security-relevant parts of the response or contain unsafe libraries.

If any of these conditions are not met, the policy can be bypassed and is not effective at preventing script execution and XSS attacks.

To prevent clickjacking attacks, the CSP must include the following directive:


frame-ancestors 'none';

Additionally, a CSP policy can prevent HTTP and HTTPS mixed content by specifying the following directives:

block-all-mixed-content; or alternatively the upgrade-insecure-requests; directive.

It is recommended to set either or of these directives but not both.

Finally, the CSP replaces the older now obsolete security headers:

• X-XSS-Protection:

• X-Frame-Options:

More information on all directives and syntax can be found here:

https://content-security-policy.com/

PROOF OF CONCEPT

The following endpoints do not correctly set a secure Content Security Policy:

• https://api-app.sandbox.xref.com/

• https://api-candidate.sandbox.xref.com/

• https://api-help.sandbox.xref.com/

• https://api-questionnaire.sandbox.xref.com/

• https://api-referee.sandbox.xref.com/

• https://api-search.sandbox.xref.com/


• https://auth.sandbox.xref.com/

• https://candidate.sandbox.xref.com/

• https://id.sandbox.xref.com/

• https://login.sandbox.xref.com/


• https://referee.sandbox.xref.com/

• https://search.sandbox.xref.com/


• https://xref-assets.xref.com/

• https://help.sandbox.xref.com

• https://api-open.xref.com

The content security policed used is shown below:

default-src http://localhost:* https://*.xref.com https://*.xref.io

https://*.sentry.io https://inlinemanual.com https://*.inlinemanual.com

https://js.stripe.com https://www.facebook.com *.hotjar.com; img-src

'self' blob: data: http://localhost:* https://*.xref.com

https://*.xref.io https://inlinemanual.com https://*.inlinemanual.com

https://*.adsymptotic.com *.bizible.com *.bizibly.com *.linkedin.com

https://*.facebook.com https://*.amazonaws.com *.wistia.com

https://www.google-analytics.com; script-src 'self' data: blob:

https://*.facebook.net https://*.cloudfront.net https://js.stripe.com


https://api-app.sandbox.xref.com/

https://api-candidate.sandbox.xref.com/

https://api-help.sandbox.xref.com/

https://api-questionnaire.sandbox.xref.com/

https://api-referee.sandbox.xref.com/

https://api-search.sandbox.xref.com/

https://app.sandbox.xref.com/

https://auth.sandbox.xref.com/

https://candidate.sandbox.xref.com/

https://id.sandbox.xref.com/

https://login.sandbox.xref.com/

https://pages.xref.com/

https://referee.sandbox.xref.com/

https://search.sandbox.xref.com/

https://template-builder.sandbox.xref.com/

https://xref-assets.xref.com/

https://help.sandbox.xref.com/

https://api-open.xref.com/


https://inlinemanual.com https://*.inlinemanual.com *.bizible.com

*.hotjar.com *.licdn.com *.wistia.com 'unsafe-inline'

https://*.googletagmanager.com https://www.google-analytics.com 'unsafe-

eval' https://*.xref.com https://*.xref.io; style-src 'self'

http://localhost:* https://*.xref.com https://*.xref.io

https://inlinemanual.com https://*.inlinemanual.com 'unsafe-inline'

*.hotjar.com *.wistia.com; connect-src 'self' http://localhost:*

https://*.xref.com https://*.xref.io *.hotjar.com

https://inlinemanual.com https://*.inlinemanual.com

https://*.smartling.com https://*.sentry.io https://www.google-

analytics.com;

This can be trivially bypassed as it allows inline JavaScript execution (unsafe-inline), the execution of code injected into DOM APIs (unsafe-eval) and, external JavaScript execution from domains an attacker can control the contents. Allowing https://*.cloudfront.net or https://*.googletagmanager.com means an attacker can host the JavaScript on those domains and the script will be included within the CSP whitelist.

BUSINESS IMPACT

The application is missing protective mechanisms that keep it safe from cross-site scripting (XSS), clickjacking and serving mixed HTTP and HTTPS content. Having a secure Content Security Policy (CSP) is a defence in depth mechanism.

REPRODUCTION STEPS


• The tool https://csp-evaluator.withgoogle.com/ can be used to evaluate the security of a content security policy. All issues marked “High severity finding” should be fixed.

RECOMMENDATIONS

Red Cursor recommends implementing a secure Content Security Policy (CSP) to add

additional protection to the application.

A CSP policy is delivered in either the Content-Security-Policy HTTP response header or in a <meta> tag. The following examples demonstrate how to enable a CSP:

# Enable CSP in Apache

Header set Content-Security-Policy "default-src 'none'; img-src 'self';

script-src 'self' https://code.jquery.com; style-src 'self'"

https://*.cloudfront.net/

https://*.googletagmanager.com/

https://csp-evaluator.withgoogle.com/

# Enable CSP in nginx

add_header Content-Security-Policy "default-src 'none'; img-src 'self';

script-src 'self' https://code.jquery.com; style-src 'self'";

# Enable CSP in IIS

<system.webServer>

<httpProtocol>

<customHeaders>

<add name="Content-Security-Policy" value="default-src 'self';" />

</customHeaders>

</httpProtocol>

</system.webServer>

#

<head>

<meta http-equiv="Content-Security-Policy" content="default-src 'none';

img-src 'self'; script-src 'self' https://code.jquery.com; style-src

'self'">

More information on all CSP directives and examples can be found at the following URLs:

https://www.owasp.org/index.php/Content_Security_Policy_Cheat_Sheet


https://www.owasp.org/index.php/Content_Security_Policy_Cheat_Sheet


5.5 TCP Timestamps

TCP Timestamps


INFORMATIONAL

Likelihood:

Very Low

Consequence:

Very Low


The server is allowing TCP timestamps. This allows an attacker to calculate the uptime of the server. This can be a rough indication of how effectively a device is patched. If a device has not been rebooted for a long time, it can be a sign that the server is missing critical security patches that require a reboot.

It is best practice to disclose as little information as possible to attackers.

PROOF OF CONCEPT

Red Cursor found that the following endpoints are disclosing their uptimes via TCP timestamps:

• api-app.sandbox.xref.com

• api-candidate.sandbox.xref.com

• api-help.sandbox.xref.com

• api-open.xref.com

• api-questionnaire.sandbox.xref.com

• api-referee.sandbox.xref.com

• api-search.sandbox.xref.com

• app.sandbox.xref.com

• auth.sandbox.xref.com

• candidate.sandbox.xref.com

• help.sandbox.xref.com

• id.sandbox.xref.com

• login.sandbox.xref.com

• referee.sandbox.xref.com


• search.sandbox.xref.com

• template-builder.sandbox.xref.com

• xref-assets.xref.com

An example of this is shown in the following screenshot:

Figure 8. login.sandbox.xref.com uptime via TCP timestamps

This allows an attacker to estimate roughly how well devices are patched.

BUSINESS IMPACT

It is possible to work out the uptime of devices. Disclosing uptimes indicates how effectively

a device is patched.

REPRODUCTION STEPS

To reproduce the proof of concept run the following Nmap command:

nmap -O -P0 -vv <HOSTNAME>

RECOMMENDATIONS

Red Cursor recommends removing TCP timestamps where possible. To remove TCP

timestamps on Linux devices run the following command:

sudo sysctl -w net.ipv4.tcp_timestamps=0

Starting with Windows Server 2008 and Vista, TCP timestamps cannot be completely disabled. Disabling TCP Timestamp only affects the outgoing traffic, for incoming traffic Microsoft has to honour it if the other side requests it.


6 Appendices

6.1 Appendix 1 – Technical Risk Calculation

Red Cursor’s risk ratings are based on the NIST 800 30 Cyber Security Framework and the ISO 27001 standard. They are designed to provide a model for calculating risks that arise from vulnerabilities in systems. The purpose is to help businesses qualitatively measure their risk and prioritise remediation of the identified issues. This calculation uses the metrics of:

Impact * Likelihood = Overall technical risk

6.1.1 Impact Calculation

The level of impact from a vulnerability is the magnitude of harm that can be expected to result if the vulnerability is exploited.

It takes into account violations of confidentiality, integrity and availability (CIA) of user, data and systems. It can include unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or system availability. Technical impact factors include:

• Loss of confidentiality

How much data could be disclosed and how sensitive is it? Minimal non-sensitive data disclosed, minimal critical data disclosed, extensive non-sensitive data disclosed, extensive critical data disclosed, or all data disclosed.

• Loss of integrity

How much data could be corrupted and how damaged is it? Minimal slightly corrupt data, minimal seriously corrupt data, extensive slightly corrupt data, extensive seriously corrupt data or all data totally corrupt.

• Loss of availability

How much service could be lost and how vital is it? Minimal secondary services interrupted, minimal primary services interrupted, extensive secondary services interrupted, extensive primary services interrupted, or all services completely lost.

The table below shows how each value is determined:


Qualitive Value Description

Very High

The threat event could be expected to have multiple severe or catastrophic adverse effects on organisational operations, organisational assets, individuals, other organisations, or data.

High

The threat event could be expected to have a severe or catastrophic adverse effect on organisational operations, organisational assets, individuals, other organisations, or data.

Moderate

The threat event could be expected to have a serious adverse effect on organisational operations, organisational assets, individuals, other organisations, or data.

Low

The threat event could be expected to have a limited adverse effect on organisational operations, organisational assets, individuals, other organisations, or data.

Very Low

The threat event could be expected to have a negligible adverse effect on organisational operations, organisational assets, individuals, other organisations, or data.

6.1.2 Likelihood Calculation

Likelihood is how likely this particular vulnerability is to be uncovered and exploited by an attacker.


The likelihood of occurrence is determined by the following factors:

• Skill level How technically skilled would an attacker have to be? Security penetration skills, network and programming skills, advanced computer user, some technical skills or no technical skills.

• Motive How motivated would an attacker have to be to find and exploit this vulnerability? Low or no reward, possible reward or high reward.

• Opportunity

What resources and opportunities are required for an attacker to find and exploit this vulnerability? Full access or expensive resources required, special access or resources required, some access or resources required, or no access or resources required.

• Size How large is this group of threat agents? Developers, system administrators, internal users, partners, authenticated users or anonymous Internet users.

• Ease of discovery How easy is it for an attacker to discover this vulnerability? Practically impossible, difficult, easy, or are automated tools available.

• Ease of exploit How easy is it for an attacker to actually exploit this vulnerability? Theoretical, difficult, easy, or are automated tools available.

• Awareness How well known is this vulnerability to Attackers? Unknown, hidden, obvious, or public knowledge.

• Intrusion detection

How likely is an exploit to be detected? Active detection in application, logged and reviewed, logged without review, or not logged.

The table below shows how each value is determined:

Qualitive Value Description

Very High An attacker is almost certain to initiate the threat event.

High An attacker is highly likely to initiate the threat event

Moderate An attacker is somewhat likely to initiate the treat event.


Low An attacker is unlikely to initiate the threat event.

Very Low An attacker is highly unlikely to initiate the threat event.

6.1.3 Overall Technical Risk Calculation Matrix

The final risk calculation uses the likelihood and impact metrics to determine technical risk. The table below demonstrates how these metrics align to calculate the final technical risk:

Likelihood

Very Low Low Moderate High Very High

Imp

act

Very High

Low

Medium

High

Very High

Very High

High

Low

Medium

Medium

High

Very High

Moderate

Low

Low

Medium

Medium

High

Low

Informational

Low

Low

Medium

Medium

Very Low

Informational

Informational

Low

Low

Low


It is important to note that the risks reported in this report are technical risks.

The final business risk stems from the technical risk but requires an in-depth understanding of what is important to the company running the systems. This information is not necessarily known to Red Cursor and the technical risk should be used in conjunction with corporate knowledge when calculating the overall business risk. A company needs to take into account the following business risk factors:

• Financial damage

• Reputational damage

• Non-compliance

• Privacy violations


6.2 Appendix 2 – Tools Used During This Test

Tool Description

Burp Suite Pro

Burp suite is the leading tool for testing web application security. It is a local proxy that allows manipulation of requests to and from a web server.

Selenium

Selenium is a suite of tools and libraries for automating browser requests. It allows scripting of web requests that can simulate a browser.

Gobuster

Gobuster is a go application designed to brute force directories and files names on web/application servers.

DirBuster

DirBuster is a java application designed to brute force directories and files names on web/application servers. It is developed by the OWASP community.

Various

Chrome/Firefox plugins

Various browser plugins like developer tools such as: Built With, No

Script, Firebug d3coder, XSS rays, cache killer, HPP finder, GHDB, cookie editor, foxyproxy.

Kali

Kali is a Linux distribution with preconfigured tools for penetration testers. Kali contains several hundred tools which are tailored for security testing.

SQLmap

SQLmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and exploiting database servers

Nessus Nessus is a commercial vulnerability scanner used for automatically identifying known security vulnerabilities.

SSL labs SSL labs is a website designed to test the security configuration of TLS connections. https://ssllabs.com

Nmap

Nmap is a very common port scanner used for identifying and fingerprinting open services. It also contains the NSE scripting engine for identifying common vulnerabilities.

https://ssllabs.com/


Testssl.sh Testssl.sh is a script/website for testing servers TLS settings.

http://testssl.sh

Hping3 Hping3 is a command-line TCP/IP packet assembler/analyser. It is used

for constructing various packet types in pen testing.

Slurp Slurp is tool for identifying unsecured AWS S3 buckets.

Exiftool Exiftool is Linux tool used for reading and modifying metadata in office

documents.

Fingerprinter Is a script that attempts to fingerprint version numbers of popular

content management systems based on checksums of common files.

http://testssl.sh/

xref web application and api penetration test report

Documents