Phase 6: Professional Report Generation¶

Overview¶

Phase 6 consolidates all verified findings into a professional penetration testing report suitable for presentation to stakeholders, management, and technical teams. The report includes executive summaries, detailed findings with full technical evidence, risk analysis, and remediation guidance.

Purpose: Deliver findings in a format that is: - ✅ Credible and defensible - ✅ Actionable with clear remediation steps - ✅ Compliant with industry standards (CVSS 4.0, OWASP) - ✅ Professional in presentation

For pentests, the report must preserve the same full-evidence standard established during verification. If the finding is HTTP-backed, the generated deliverables must include the full raw HTTP request and the full raw HTTP response with complete headers and body. This applies to the report .docx itself and to any HedgeDoc/Outline publication derived from the engagement.

Report Structure¶

Executive Summary¶

Audience: C-level, project managers, non-technical stakeholders

# Executive Summary

## Engagement Overview
- **Target**: api.example.com
- **Engagement Date**: 2026-03-13 to 2026-03-15
- **Scope**: All API endpoints and web interfaces
- **Authorization**: Signed contract dated 2026-03-01

## Key Findings
- **Critical Findings**: 2 (RCE, Auth Bypass)
- **High Findings**: 4 (SQLi, Stored XSS, IDOR, Logic Flaw)
- **Medium Findings**: 6 (Missing Headers, Weak TLS)

## Risk Rating: **CRITICAL**
The application has critical vulnerabilities allowing remote code execution and authentication bypass. Immediate remediation required before production deployment.

## Recommended Actions (Priority Order)
1. Fix RCE vulnerability in file export endpoint (Critical)
2. Implement input validation for all parameters (Critical)
3. Update TLS configuration to disable weak ciphers (High)
4. Add security headers (HSTS, CSP, etc.) (Medium)

Attack Surface Overview¶

Summary of discovered attack surface: - Total endpoints: 47 - API endpoints: 38 - File upload endpoints: 3 - Admin panels: 2 - Authentication endpoints: 4

Vulnerability Summary Table¶

For quick reference: All findings in ranked order

Finding ID	Vulnerability	Severity	CVSS	Status
FINDING-001	Remote Code Execution in Export	Critical	9.8	Verified
FINDING-002	SQL Injection in /api/v1/users	High	8.2	Verified
FINDING-003	Stored XSS in Comments	High	7.5	Verified
FINDING-004	IDOR on User Profiles	High	7.1	Verified

Detailed Findings¶

Audience: Technical teams responsible for remediation

Each finding includes:

1. Finding Title¶

Clear, specific name indicating the vulnerability type and affected component

SQL Injection in User Search Parameter (/api/v1/users?sort=)

2. Vulnerability Description¶

What is the vulnerability?
Where is it located?
How can it be exploited?
What is the impact?

## Description

The `/api/v1/users` endpoint accepts a `sort` parameter that is directly
incorporated into a SQL query without proper parameterization or input validation.
This allows an authenticated attacker to inject arbitrary SQL commands, potentially
leading to:

- Unauthorized data access (reading other users' emails, phone numbers, etc.)
- Data modification (changing user roles, passwords)
- Database compromise (executing system commands on the database server)

3. Technical Evidence and Proof of Concept¶

Step-by-step instructions plus the raw evidence needed to defend the finding

## Technical Evidence

### HTTP Request
```http
GET /api/v1/users?sort=name' AND SLEEP(5) -- HTTP/1.1
Host: api.example.com
Authorization: Bearer TOKEN_HERE
Accept: */*
Connection: close

HTTP Response¶

HTTP/1.1 200 OK
Content-Type: application/json
X-Request-Id: 8f3a1b2c

[{"id":1,"email":"admin@example.com"},...]

Proof of Concept¶

Prerequisites¶

Valid authentication token (obtain via /api/v1/auth/login)

Steps¶

Save the following curl command to a file:

curl -X GET "https://api.example.com/api/v1/users?sort=name' AND SLEEP(5) --" \
  -H "Authorization: Bearer TOKEN_HERE" \
  -w "\nResponse Time: %{time_total}s\n"

Replace TOKEN_HERE with your authentication token
Execute the command
Observe: Response takes 5+ seconds (SLEEP executed)

Expected Output¶

[{"id":1,"email":"admin@example.com"},...]
Response Time: 5.23s

Why This Proves Vulnerability¶

The 5+ second delay confirms SQL query execution
Without the delay, the query would return in <100ms

This proves injection is possible and SQL is being executed

For visual/browser-driven vulnerabilities, include representative screenshots in the report. For example, XSS findings must show the triggered dialog or rendered payload state, not only the request/response pair.

#### 4. Severity Assessment (CVSS 4.0)
**Standard scoring**: CVSS 4.0 vector + severity rating

```markdown
## Severity Assessment

### CVSS 4.0 Vector
`CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:U/SI:U/SA:U`

**Score: 8.2 (HIGH)**

### Vector Explanation
- **AV:N** (Network) - Attacker can access over network
- **AC:L** (Low) - No special conditions required
- **PR:L** (Low) - Requires authentication (low bar)
- **UI:N** (None) - No user interaction required
- **VC:H** (High) - Complete confidentiality breach (read all data)
- **VI:H** (High) - Complete integrity breach (modify all data)
- **VA:H** (High) - Complete availability breach (delete/disable)

5. Impact Analysis¶

Business and technical impact

## Impact

### Technical Impact
- Unauthorized read access to all user data
- Ability to modify user records (password reset, role escalation)
- Potential database server compromise

### Business Impact
- **Confidentiality**: Users' PII (emails, phone numbers) exposed
- **Compliance**: GDPR violation (unauthorized data access)
- **Reputation**: Data breach would damage customer trust
- **Financial**: Potential fines up to $20M (GDPR) or 4% revenue

6. Remediation Guidance¶

Clear, specific fixes

## Remediation

### Immediate Fix (Code Change)
Replace the vulnerable SQL query:

**BEFORE (Vulnerable):**
```python
query = f"SELECT * FROM users WHERE 1=1 ORDER BY {sort_param}"
results = db.execute(query)

AFTER (Fixed):

allowed_columns = ['name', 'email', 'created_at']
if sort_param not in allowed_columns:
    sort_param = 'name'  # Default
query = "SELECT * FROM users WHERE 1=1 ORDER BY " + \
        db.literal_column(sort_param)
results = db.execute(query)

Verification¶

Run the PoC again after fix:

curl "https://api.example.com/api/v1/users?sort=name' AND SLEEP(5)" ...
# Should return immediately (<100ms), not wait 5 seconds

#### 7. References
CWE, OWASP, CVE links

```markdown
## References
- CWE-89: Improper Neutralization of Special Elements used in an SQL Command
- OWASP A03:2021 - Injection
- PortSwigger: SQL Injection (https://portswigger.net/web-security/sql-injection)

Risk Ranking Approach¶

Findings are ranked by risk = Impact × Probability:

Critical (9-10): - RCE with no authentication - SQLi leading to data breach - Authentication bypass to admin

High (7-8.9): - Stored XSS on high-traffic page - IDOR exposing PII - Business logic flaws affecting payments

Medium (4-6.9): - Reflected XSS requiring user interaction - CSRF on non-state-changing operations - Missing security headers

Low (0.1-3.9): - Clickjacking potential - Information disclosure (version numbers) - Deprecated TLS still accepted

Informational (0.0): - Best practice recommendations - Security improvements without immediate exploit

Report Formats¶

Standard Report (Markdown)¶

Default output format, suitable for: - Sending via email - Publishing internally - Version control in git

Command:

/report

HTML Report¶

Professionally formatted, printable

Command:

/report --format html

HWG Compliance Format (Italian)¶

For clients requiring Italian regulatory compliance (Halley Docenti, Consip, etc.)

Command:

/report --hwg

Features: - ASVS 4.0 categories (V1-V14) - Severity in Italian (Critico, Alto, Medio, Basso) - Compliance-specific language - Placeholder fields: #[Organizzazione]#, #[Penester]#, #[Versione]#

PDF Report¶

Printable format with cover page, table of contents

Command:

/report --format pdf

Multi-Engagement Reporting¶

For clients with multiple pentests (dev, staging, production), generate comparison reports:

/diff-engagements old_engagement new_engagement

Output shows: - ✅ Fixed findings - ❌ Recurring findings - 🆕 New findings - 📊 Metrics (total count, severity distribution)

Report Customization¶

After generation, customize for client:

Logo and Branding: Add client logo to cover page
Custom Metadata: Engagement date, penester name, authorized contact
Conclusion: Add risk assessment and strategic recommendations
Appendices: Add network topology diagrams, scope documents, testing methodology

Deliverables Checklist¶

✅ Before sharing with client: - [ ] All findings verified and exploit tested - [ ] Every pentest finding includes the full raw HTTP request and full raw HTTP response where HTTP is involved - [ ] The .docx report preserves the same complete evidence captured during verification - [ ] HedgeDoc/Outline notes, if published, contain the same full HTTP evidence as the final report - [ ] Persistent payloads cleaned from target - [ ] Representative screenshots included where they materially prove the issue - [ ] Executive summary written - [ ] All findings have CVSS scores - [ ] Remediation guidance is specific and actionable - [ ] References (CWE, OWASP, CVE) included - [ ] Report proofread for typos/clarity - [ ] Client metadata (dates, names) verified - [ ] Report format matches contract requirements - [ ] Confidentiality notice on cover page

Post-Report Actions¶

1. Presentation to Stakeholders¶

Schedule meeting to: - Present executive summary - Answer questions from management/technical teams - Discuss remediation priorities - Plan follow-up retest (after fixes)

2. Retest Engagement¶

After client fixes vulnerabilities:

/pentest https://api.example.com --retest

Compares previous findings, verifies fixes, checks for regressions.

3. Archive Results¶

Store engagement results in engagements/ for historical reference:

engagements/
  example-com-2026-03-13/
    findings/
    evidence/
    report.md

Next Steps¶

After Phase 6 completes, the penetration test is complete. Optional: - Retest (Phase 0-6 again after fixes) - Manual Testing (Additional scope identified) - Training (Security training for developers based on findings)