deardaniel/secdata-raw huggingface dataset:
Penetration Test Report (.): README

# Public penetration testing reports

A repository containing public penetration test reports published by consulting firms and academic security groups.

Maintained by Julio @ Blaze Information Security (https://www.blazeinfosec.com).

Based on a list [started in 2015](https://web.archive.org/web/[PII_REDACTED]4146/http://roselabs.nl/links#audit-reports) by Arne Padmos. See [this repo](https://github.com/arnepadmos/threats) for a similar effort in the area of threat modelling.
Penetration Test Report (CPTC): README

# Example Reports

Within this repository we are including redacted copies of every report from the teams that advanced to the final competition as part of the [Collegiate Penetration Testing Competition](http://nationalcptc.org). As organizers of CPTC, our core goal is to foster education and help the next generation of offensive security practitioners gain practical experience that they can use in their future careers.  To support this mission, we’ve been increasing the amount of feedback and information that we share with competitors in order to improve every team which participates in our event.  Sadly, our time and resources are limited and not every team has the opportunity to make it to the final round of competition and experience all that CPTC has to offer, limiting that goal. 

We are providing these reports as examples for students and practitioners around the industry as examples.  None of them are perfect, but all provide excellent examples of various approaches to reporting during penetration testing activities. 

## About CPTC
At its heart, CPTC is a bit different from several other collegiate  Cybersecurity competitions.  Instead of defending your network,  searching for flags, or claiming ownership of systems, CPTC focuses on mimicking the activities performed during a real-world penetration testing engagement conducted by companies, professional services firms,  and internal security departments around the world.
Penetration Test Report (TrailOfBits): Reserve LOA

6/5/2019 Reserve (public) - Google Docs
Trail of Bits
April 18, 2019
Defense Guided by Experience
228 Park Ave S #80688 To Whom It May Concern:
New York, NY 10003
In March 2019, Reserve Protocol engaged Trail of Bits, Inc. ("Trail of Bits") to conduct a
security assessment of the smart contracts underlying the Reserve Dollar, a fiat-pegged
Dan Guido, CEO stablecoin issued by Reserve and built on the Ethereum network according to the ERC20
dan@trailobits.com standard for tokens.
@dguido / @trailobits
Trail of Bits performed this assessment from March 4th to March 8th, 2019. One
[PII_REDACTED]
engineer from Trail of Bits conducted the assessment over the course of one
www.trailobits.com
person-week. The goal of the assessment was to discover flaws that could allow an
attacker to perform actions meant only for the issuer, Reserve Protocol.
Reserve Protocol provided Trail of Bits with direct access to their engineers and all
available source, testing, and deployment code. In addition to reviewing the code
through manual effort, the Reserve Dollar was evaluated with static analysis and
property testing.
Two medium-, five low-severity, and three informational issues were found in the course
of the assessment. In addition, Trail of Bits contributed their automated testing and
verification scripts for integration into Reserve Protocols future development.
Sincerely,
Dan Guido
httpTsr:a//idl oocfs .Bgiotosg l|e . c2o0m1/9document/d/1HoFiJpUXV-4o1fe3jPnv6AGjQun1w4MHwQNJCm1EA_Y/edit?ts=5cf821c8 Page 11 /1
# Security Policy

## Supported Versions

This repository contains documentation and educational content.
There are no executable components or deployed services associated with this project.

The `master` branch reflects the latest maintained version of the documentation.

| Version | Supported |
|--------|-----------|
| master | ✅ |
| Others | ❌ |

---

## Reporting a Vulnerability

This repository does **not** directly process user data, authentication, or runtime execution.
However, if you believe you have identified:

- A security issue affecting linked tooling or referenced examples
- A misconfiguration that could lead to unsafe usage patterns
- A vulnerability related to CI/CD workflows or repository automation

Please follow **responsible disclosure** practices.

### How to Report

- Open a **private GitHub Security Advisory** for this repository, **or**
- Contact the OWASP project maintainers through official OWASP communication channels

Please include:

- A clear description of the issue
- Steps to reproduce (if applicable)
- Potential impact
- Suggested remediation (if available)

---

## Disclosure Process

- Reports will be reviewed by project maintainers
- If applicable, fixes will be discussed and implemented
- Public disclosure may occur after remediation, with reporter credit if desired

---

## Security Best Practices for Contributors

- Do not include secrets, tokens, or credentials in documentation or workflows
- Avoid using user-controlled input in CI/CD pipelines without validation
- Follow the OWASP Cheat Sheet Series for secure development and governance practices

---

## Recognition

Security researchers and contributors who responsibly disclose issues may be acknowledged
in release notes or project documentation, unless anonymity is requested.
# Web Security Testing Guide Checklist

Contained in this folder is an Excel file which provides the following worksheets:

- _Testing Checklist_ - facilitates simple progress tracking against each of the "tests" outlined in the guide.
- _Summary Findings_ - facilitates creating a table of test outcomes and potential recommendations.
- _Risk Assessment Calculator_ - a dropdown driven sheet for calculating likelihood and impact scores, and a qualitative overall risk rating.
- _References_ - provides the lists/sets that the calculator is based upon.

**Note:** The current (Excel) checklist is based on v4.2 of the OWASP Testing Guide, as content for other versions is still under development.

## Direct Link

- [OWASP Testing Checklist (Excel)](https://raw.githubusercontent.com/OWASP/wstg/master/checklists/checklist.xlsx)
- [OWASP Testing Checklist (Markdown)](https://raw.githubusercontent.com/OWASP/wstg/master/checklists/checklist.md)

## Excel File Hash

SHA-256: e743295ab84bb14a7afaa7ff390684d5c0558dca238be84dba7aa6d46c39cdf1

## Google Sheets Template

The following instructions can be used to copy the Checklist spreadsheet template directly into a new Google sheet without having to save the doc locally first.

1. Go to this [Google Spreadsheet template](https://docs.google.com/spreadsheets/d/1csiYqA3DXhpz69K2JCLKN4H-kzkRFlFi/copy?copyCollaborators=false&copyComments=false&title=WSTG+Checklist)
2. Click `Make a copy` button. This will create a new checklist in your logged in Google Drive.
3. You should now have a fully populated and functional Web Security Testing Guide Checklist in a Google sheet, with the four tabs as mentioned above.
# Web Application Security Testing

4.0 [Introduction and Objectives](00-Introduction_and_Objectives/README.md)

4.1 [Information Gathering](01-Information_Gathering/README.md)

4.2 [Configuration and Deployment Management Testing](02-Configuration_and_Deployment_Management_Testing/README.md)

4.3 [Identity Management Testing](03-Identity_Management_Testing/README.md)

4.4 [Authentication Testing](04-Authentication_Testing/README.md)

4.5 [Authorization Testing](05-Authorization_Testing/README.md)

4.6 [Session Management Testing](06-Session_Management_Testing/README.md)

4.7 [Input Validation Testing](07-Input_Validation_Testing/README.md)

4.8 [Testing for Error Handling](08-Testing_for_Error_Handling/README.md)

4.9 [Testing for Weak Cryptography](09-Testing_for_Weak_Cryptography/README.md)

4.10 [Business Logic Testing](10-Business_Logic_Testing/README.md)

4.11 [Client-side Testing](11-Client-side_Testing/README.md)

4.12 [API Testing](12-API_Testing/README.md)
# 4.9 Testing for Weak Cryptography

4.9.1 [Testing for Weak Transport Layer Security](01-Testing_for_Weak_Transport_Layer_Security.md)

4.9.2 [Testing for Padding Oracle](02-Testing_for_Padding_Oracle.md)

4.9.3 [Testing for Sensitive Information Sent via Unencrypted Channels](03-Testing_for_Sensitive_Information_Sent_via_Unencrypted_Channels.md)

4.9.4 [Testing for Weak Cryptographic Primitives](04-Testing_for_Weak_Cryptographic_Primitives.md)
# Testing for Stack Traces

|ID          |
|------------|
|WSTG-ERRH-02|

This content has been merged into: [Testing for Improper Error Handling](01-Testing_For_Improper_Error_Handling.md).

[merged]: # (WSTG-ERRH-01)
# 4.8 Testing for Error Handling

4.8.1 [Testing for Improper Error Handling](01-Testing_For_Improper_Error_Handling.md)

4.8.2 [Testing for Stack Traces](02-Testing_for_Stack_Traces.md)
# 4.5 Authorization Testing

4.5.1 [Testing Directory Traversal File Include](01-Testing_Directory_Traversal_File_Include.md)

4.5.2 [Testing for Bypassing Authorization Schema](02-Testing_for_Bypassing_Authorization_Schema.md)

4.5.3 [Testing for Privilege Escalation](03-Testing_for_Privilege_Escalation.md)

4.5.4 [Testing for Insecure Direct Object References](04-Testing_for_Insecure_Direct_Object_References.md)

4.5.5 [Testing for OAuth Weaknesses](05-Testing_for_OAuth_Weaknesses.md)

4.5.5.1 [Testing for OAuth Authorization Server Weaknesses](05.1-Testing_for_OAuth_Authorization_Server_Weaknesses.md)

4.5.5.2 [Testing for OAuth Client Weaknesses](05.2-Testing_for_OAuth_Client_Weaknesses.md)
# 4.10 Business Logic Testing

4.10.0 [Introduction to Business Logic](00-Introduction_to_Business_Logic.md)

4.10.1 [Test Business Logic Data Validation](01-Test_Business_Logic_Data_Validation.md)

4.10.2 [Test Ability to Forge Requests](02-Test_Ability_to_Forge_Requests.md)

4.10.3 [Test Integrity Checks](03-Test_Integrity_Checks.md)

4.10.4 [Test for Process Timing](04-Test_for_Process_Timing.md)

4.10.5 [Test Number of Times a Function Can Be Used Limits](05-Test_Number_of_Times_a_Function_Can_Be_Used_Limits.md)

4.10.6 [Testing for the Circumvention of Work Flows](06-Testing_for_the_Circumvention_of_Work_Flows.md)

4.10.7 [Test Defenses Against Application Misuse](07-Test_Defenses_Against_Application_Misuse.md)

4.10.8 [Test Upload of Unexpected File Types](08-Test_Upload_of_Unexpected_File_Types.md)

4.10.9 [Test Upload of Malicious Files](09-Test_Upload_of_Malicious_Files.md)

4.10.10 [Test Payment Functionality](10-Test-Payment-Functionality.md)
# 4.12 API Testing

4.12.0 [API Testing Overview](00-API_Testing_Overview.md)

4.12.1 [API Reconnaissance](01-API_Reconnaissance.md)

4.12.2 [API Broken Object Level Authorization](02-API_Broken_Object_Level_Authorization.md)

4.12.3 [Testing for Excessive Data Exposure](03-Testing_for_Excessive_Data_Exposure.md)

4.12.4 [API Broken Function Level Authorization](04-API_Broken_Function_Level_Authorization.md)

4.12.99 [Testing GraphQL](99-Testing_GraphQL.md)
# 4.6 Session Management Testing

4.6.1 [Testing for Session Management Schema](01-Testing_for_Session_Management_Schema.md)

4.6.2 [Testing for Cookies Attributes](02-Testing_for_Cookies_Attributes.md)

4.6.3 [Testing for Session Fixation](03-Testing_for_Session_Fixation.md)

4.6.4 [Testing for Exposed Session Variables](04-Testing_for_Exposed_Session_Variables.md)

4.6.5 [Testing for Cross Site Request Forgery](05-Testing_for_Cross_Site_Request_Forgery.md)

4.6.6 [Testing for Logout Functionality](06-Testing_for_Logout_Functionality.md)

4.6.7 [Testing Session Timeout](07-Testing_Session_Timeout.md)

4.6.8 [Testing for Session Puzzling](08-Testing_for_Session_Puzzling.md)

4.6.9 [Testing for Session Hijacking](09-Testing_for_Session_Hijacking.md)

4.6.10 [Testing JSON Web Tokens](10-Testing_JSON_Web_Tokens.md)

4.6.11 [Testing for Concurrent Sessions](11-Testing_for_Concurrent_Sessions.md)
# Testing for Credentials Transported over an Encrypted Channel

|ID          |
|------------|
|WSTG-ATHN-01|

This content has been merged into: [Testing for Sensitive Information Sent via Unencrypted Channels](../09-Testing_for_Weak_Cryptography/03-Testing_for_Sensitive_Information_Sent_via_Unencrypted_Channels.md)

[merged]: # (WSTG-CRYP-03)
# 4.4 Authentication Testing

4.4.1 [Testing for Credentials Transported over an Encrypted Channel](01-Testing_for_Credentials_Transported_over_an_Encrypted_Channel.md)

4.4.2 [Testing for Default Credentials](02-Testing_for_Default_Credentials.md)

4.4.3 [Testing for Weak Lock Out Mechanism](03-Testing_for_Weak_Lock_Out_Mechanism.md)

4.4.4 [Testing for Bypassing Authentication Schema](04-Testing_for_Bypassing_Authentication_Schema.md)

4.4.5 [Testing for Vulnerable Remember Password](05-Testing_for_Vulnerable_Remember_Password.md)

4.4.6 [Testing for Browser Cache Weaknesses](06-Testing_for_Browser_Cache_Weaknesses.md)

4.4.7 [Testing for Weak Authentication Methods](07-Testing_for_Weak_Authentication_Methods.md)

4.4.8 [Testing for Weak Security Question Answer](08-Testing_for_Weak_Security_Question_Answer.md)

4.4.9 [Testing for Weak Password Change or Reset Functionalities](09-Testing_for_Weak_Password_Change_or_Reset_Functionalities.md)

4.4.10 [Testing for Weaker Authentication in Alternative Channel](10-Testing_for_Weaker_Authentication_in_Alternative_Channel.md)

4.4.11 [Testing Multi-Factor Authentication](11-Testing_Multi-Factor_Authentication.md)
# Testing for Vulnerable Remember Password

|ID          |
|------------|
|WSTG-ATHN-05|

## Summary

Credentials are the most widely used authentication technology. Due to such a wide usage of username-password pairs, users are no longer able to properly handle their credentials across the multitude of used applications.

In order to assist users with their credentials, multiple technologies surfaced:

- Applications provide a *remember me* functionality that allows the user to stay authenticated for long periods of time, without asking the user again for their credentials.
- Password Managers - including browser password managers - that allow the user to store their credentials in a secure manner and later on inject them in user-forms without any user intervention.

## Test Objectives

- Validate that the generated session is managed securely and do not put the user's credentials in danger.

## How to Test

As these methods provide a better user experience and allow the user to forget all about their credentials, they increase the attack surface area. Some applications:

- Store the credentials in an encoded fashion in the browser's storage mechanisms, which can be verified by following the [web storage testing scenario](../11-Client-side_Testing/12-Testing_Browser_Storage.md) and going through the [session analysis](../06-Session_Management_Testing/01-Testing_for_Session_Management_Schema.md#session-analysis) scenarios. Credentials shouldn't be stored in any way in the client-side application, and should be substituted by tokens generated server-side.
- Automatically inject the user's credentials that can be abused by:
    - [ClickJacking](../11-Client-side_Testing/09-Testing_for_Clickjacking.md) attacks.
    - [CSRF](../06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery.md) attacks.
- Tokens should be analyzed in terms of token-lifetime, where some tokens never expire and put the users in danger if those tokens ever get stolen. Make sure to follow the [session timeout](../06-Session_Management_Testing/07-Testing_Session_Timeout.md) testing scenario.

## Remediation

- Follow [session management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) good practices.
- Ensure that no credentials are stored in clear text or are easily retrievable in encoded or encrypted forms in browser storage mechanisms; they should be stored server-side and follow good [password storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) practices.
# Testing for HTML Injection

|ID          |
|------------|
|WSTG-CLNT-03|

## Summary

HTML injection is a type of injection vulnerability that occurs when a user is able to control an input point and is able to inject arbitrary HTML code into a vulnerable web page. This vulnerability can have many consequences, like disclosure of a user's session cookies that could be used to impersonate the victim, or, more generally, it can allow the attacker to modify the page content seen by the victims.

This vulnerability occurs when user input is not correctly sanitized and the output is not encoded. An injection allows the attacker to send a malicious HTML page to a victim. The targeted browser will not be able to distinguish (trust) legitimate parts from malicious parts of the page, and consequently will parse and execute the whole page in the victim's context.

There is a wide range of methods and attributes that could be used to render HTML content. If these methods are provided with an untrusted input, then there is an high risk of HTML injection vulnerability. For example, malicious HTML code can be injected via the `innerHTML` JavaScript method, usually used to render user-inserted HTML code. If strings are not correctly sanitized, the method can enable HTML injection. A JavaScript function that can be used for this purpose is `document.write()`.

The following example shows a snippet of vulnerable code that allows an unvalidated input to be used to create dynamic HTML in the page context:

```js
var userposition=location.href.indexOf("user=");
var user=location.href.substring(userposition+5);
document.getElementById("Welcome").innerHTML=" Hello, "+user;
```

The following example shows vulnerable code using the `document.write()` function:

```js
var userposition=location.href.indexOf("user=");
var user=location.href.substring(userposition+5);
document.write("<h1>Hello, " + user +"</h1>");
```

In both examples, this vulnerability can be exploited with an input such as:

```text
https://vulnerable.site/page.html?user=<img%20src='aaa'%20onerror=alert(1)>
```

This input will add an image tag to the page that will execute arbitrary JavaScript code inserted by the malicious user in the HTML context.

## Test Objectives

- Identify HTML injection points and assess the severity of the injected content.

## How to Test

Consider the following DOM XSS exercise <https://www.domxss.com/domxss/01_Basics/06_jquery_old_html.html>

The HTML code contains the following script:

```html
<script src="../js/jquery-1.7.1.js"></script>
<script>
function setMessage(){
    var t=location.hash.slice(1);
    $("div[id="+t+"]").text("The DOM is now loaded and can be manipulated.");
}
$(document).ready(setMessage  );
$(window).bind("hashchange",setMessage)
</script>
<body>
    <script src="../js/embed.js"></script>
    <span><a href="#message" > Show Here</a><div id="message">Showing Message1</div></span>
    <span><a href="#message1" > Show Here</a><div id="message1">Showing Message2</div>
    <span><a href="#message2" > Show Here</a><div id="message2">Showing Message3</div>
</body>
```

It is possible to inject HTML code.
# 4.11 Client-Side Testing

4.11.1 [Testing for DOM-Based Cross Site Scripting](01-Testing_for_DOM-based_Cross_Site_Scripting.md)

- 4.11.1.1 [Testing for Self DOM Based Cross Site Scripting](01.1-Testing_for_Self_DOM_Based_Cross_Site_Scripting.md)

4.11.2 [Testing for JavaScript Execution](02-Testing_for_JavaScript_Execution.md)

4.11.3 [Testing for HTML Injection](03-Testing_for_HTML_Injection.md)

4.11.4 [Testing for Client-side URL Redirect](04-Testing_for_Client-side_URL_Redirect.md)

4.11.5 [Testing for CSS Injection](05-Testing_for_CSS_Injection.md)

4.11.6 [Testing for Client-side Resource Manipulation](06-Testing_for_Client-side_Resource_Manipulation.md)

4.11.7 [Testing Cross Origin Resource Sharing](07-Testing_Cross_Origin_Resource_Sharing.md)

4.11.8 [Testing for Cross Site Flashing](08-Testing_for_Cross_Site_Flashing.md)

4.11.9 [Testing for Clickjacking](09-Testing_for_Clickjacking.md)

4.11.10 [Testing WebSockets](10-Testing_WebSockets.md)

4.11.11 [Testing Web Messaging](11-Testing_Web_Messaging.md)

4.11.12 [Testing Browser Storage](12-Testing_Browser_Storage.md)

4.11.13 [Testing for Cross Site Script Inclusion](13-Testing_for_Cross_Site_Script_Inclusion.md)

4.11.14 [Testing for Reverse Tabnabbing](14-Testing_for_Reverse_Tabnabbing.md)

4.11.15 [Testing for Client-side Template Injection](15-Testing_for_Client-Side_Template_Injection.md)
# Testing for JavaScript Execution

|ID          |
|------------|
|WSTG-CLNT-02|

## Summary

A JavaScript injection vulnerability is a subtype of cross site scripting (XSS) that involves the ability to inject arbitrary JavaScript code that is executed by the application inside the victim's browser. This vulnerability can have many consequences, like the disclosure of a user's session cookies that could be used to impersonate the victim, or, more generally, it can allow the attacker to modify the page content seen by the victims or the application's behavior.

JavaScript injection vulnerabilities can occur when the application lacks proper user-supplied input and output validation. As JavaScript is used to dynamically populate web pages, this injection occurs during this content processing phase and consequently affects the victim.

When testing for this vulnerability, consider that some characters are treated differently by different browsers. For reference, see [DOM-based XSS](https://owasp.org/www-community/attacks/DOM_Based_XSS).

Here is an example of a script that does not perform any validation of the variable `rr`. The variable contains user-supplied input via the query string, and additionally does not apply any form of encoding:

```js
var rr = location.search.substring(1);
if(rr) {
    window.location=decodeURIComponent(rr);
}
```

This implies that an attacker could inject JavaScript code simply by submitting the following query string: `www.victim.com/?javascript:alert(1)`.

## Test Objectives

- Identify sinks and possible JavaScript injection points.

## How to Test

Consider the following: [DOM XSS exercise](http://www.domxss.com/domxss/01_Basics/04_eval.html)

The page contains the following script:

```html
<script>
function loadObj(){
    var cc=eval('('+aMess+')');
    document.getElementById('mess').textContent=cc.message;
}

if(window.location.hash.indexOf('message')==-1) {
    var aMess='({"message":"Hello User!"})';
} else {
    var aMess=location.hash.substr(window.location.hash.indexOf('message=')+8)
}
</script>
```

The above code contains a source `location.hash` that is controlled by the attacker that can inject directly in the `message` value a JavaScript Code to take the control of the user browser.
# 4.3 Identity Management Testing

4.3.1 [Test Role Definitions](01-Test_Role_Definitions.md)

4.3.2 [Test User Registration Process](02-Test_User_Registration_Process.md)

4.3.3 [Test Account Provisioning Process](03-Test_Account_Provisioning_Process.md)

4.3.4 [Testing for Account Enumeration and Guessable User Account](04-Testing_for_Account_Enumeration_and_Guessable_User_Account.md)

4.3.5 [Testing for Weak or Unenforced Username Policy](05-Testing_for_Weak_or_Unenforced_Username_Policy.md)
# Testing for Weak or Unenforced Username Policy

|ID          |
|------------|
|WSTG-IDNT-05|

This test has been merged into WSTG-IDNT-04 (Testing for Account Enumeration and Guessable User Accounts) due to overlapping scope related to predictable username structures and enumeration techniques.

[merged]: # (WSTG-IDNT-04)