---

name: whitebox-pentest description: > Whitebox penetration testing of web applications combining source code analysis with dynamic testing through Burp Suite MCP. Performs code review to map attack surface, generates operator-approved test plans, executes non-destructive proof-of-concept attacks via Burp, and produces structured vulnerability reports with CVSS scores and remediation. Use when: (1) the user wants to pentest a web application with source code access, (2) the user asks for whitebox security testing, (3) the user wants to find and exploit vulnerabilities in a running web app, (4) the user mentions dynamic application security testing (DAST) combined with code review.

Whitebox Web Application Penetration Test

Combines static source code analysis with dynamic exploitation through Burp Suite MCP. All HTTP traffic goes through Burp — never use curl, fetch, or requests directly.

Prerequisites

Before starting, confirm with the operator:

1. Source code path — root directory of the application codebase
2. Target URL — base URL of the running application (e.g., http://localhost:3000)
3. Target hostname and port — for Burp MCP tool calls
4. HTTPS — whether the target uses TLS
5. Authentication credentials — if available (test accounts, API keys)
6. Scope constraints — any endpoints or functionality that is off-limits

Workflow

Task Progress:

• [ ] Phase 1: Source Code Reconnaissance
• [ ] Phase 2: Test Plan (operator approval required)
• [ ] Phase 3: Dynamic Testing via Burp MCP
• [ ] Phase 4: Vulnerability Reporting

---

Phase 1: Source Code Reconnaissance

Goal: Map the full attack surface from source before sending any traffic.

1.1 Technology Stack Detection

Identify the framework, language, and key dependencies:

• Read package.json / requirements.txt / Gemfile / go.mod / pom.xml / composer.json
• Identify the web framework (Express, Flask, Django, Rails, Spring, Laravel, etc.)
• Note ORM/database layer, auth libraries, template engine, session management

1.2 Route & Endpoint Mapping

Extract every HTTP endpoint from source code. See references/code-review-patterns.md for framework-specific patterns.

For each endpoint, record:

• HTTP method and path
• Authentication requirements (public / authenticated / admin)
• Input parameters (query, body, path, headers, cookies)
• Input validation applied (if any)
• Response type (HTML, JSON, redirect, file)

1.3 Authentication & Session Analysis

Identify:

• Auth mechanism (session cookies, JWT, API keys, OAuth)
• Password hashing algorithm and configuration
• Session storage and expiration
• Token generation and validation logic
• Password reset / account recovery flows
• Multi-factor authentication (if present)
• Registration and login rate limiting

1.4 Authorization Model

Map the access control model:

• Role definitions and permission checks
• Middleware/decorators enforcing authorization
• Direct object references (database IDs in URLs/params)
• Horizontal vs. vertical privilege boundaries
• Admin/management interfaces

1.5 Dangerous Sinks Inventory

Scan for code patterns that lead to vulnerabilities. For each sink found, record file path and line number.

| Sink Category | What to Look For | |---|---| | SQL/NoSQL injection | Raw query construction, string concatenation in queries, unsanitized ORM filters | | Command injection | exec, spawn, system, popen, backticks with user input | | SSTI | User input passed to template render context or template strings | | Path traversal | User input in file paths, fs.readFile, open() with concatenated paths | | SSRF | User-controlled URLs in HTTP client calls (fetch, requests.get, http.get) | | XSS | Unescaped output in templates, innerHTML, dangerouslySetInnerHTML, v-html | | Deserialization | pickle.loads, yaml.load, JSON.parse of untrusted data into execution | | File upload | Missing type validation, stored in web root, predictable names | | Redirect | Open redirect via user-controlled redirect targets | | CORS | Wildcard or reflected origins, credentials with permissive origins |

1.6 Business Logic Review

Identify critical business operations:

• Payment/financial transactions
• Account state changes (role changes, ownership transfer)
• Rate-limited operations (voting, purchasing, coupon redemption)
• Multi-step workflows with state dependencies
• Race condition susceptible operations (balance checks, inventory)

1.7 Secrets & Configuration

Check for:

• Hardcoded secrets, API keys, database credentials in source
• Debug mode enabled in production configs
• Default credentials
• Verbose error pages that leak stack traces
• Missing security headers configuration

---

Phase 2: Test Plan

Goal: Present findings from Phase 1 and propose specific tests for operator approval.

2.1 Generate Attack Surface Summary

Present to the operator:

1. Technology stack summary
2. Endpoint inventory table (method, path, auth requirement, input types)
3. Identified sinks with file:line references and severity estimate
4. Proposed test cases grouped by vulnerability class

2.2 Test Case Format

For each proposed test, include:

[VULN-CLASS-NN] Test Title
  Target:    METHOD /path
  Sink:      file.py:42 — description of vulnerable pattern
  Payload:   brief description of what will be sent
  Risk:      None/Low — why this is safe (non-destructive, read-only, etc.)
  Priority:  Critical/High/Medium/Low

2.3 Prioritization

Order tests by:

1. Critical sinks — confirmed dangerous patterns with no validation (SQLi, RCE, SSTI)
2. Auth/AuthZ bypasses — missing middleware, IDOR, privilege escalation
3. High-impact logic flaws — payment bypass, race conditions
4. Medium sinks — XSS, SSRF, open redirect with partial validation
5. Low/informational — missing headers, verbose errors, weak crypto

2.4 Operator Approval Gate

STOP. Present the test plan and wait for explicit approval before Phase 3.

Ask:

• "Here is the proposed test plan with N test cases. May I proceed with dynamic testing?"
• Offer to add/remove/modify specific tests
• Confirm scope boundaries are respected

---

Phase 3: Dynamic Testing via Burp MCP

Goal: Execute approved tests through Burp Suite MCP and capture proof-of-concept evidence.

3.1 Burp MCP Tool Usage

All HTTP requests MUST go through Burp MCP tools. Read the "Known Pitfalls" section in references/burp-mcp-reference.md first — Content-Length errors, line endings, and HTTP/2 limitations cause the most wasted time.

Key tools:

• mcp__burp__send_http1_request — Send HTTP/1.1 requests (most common)
• mcp__burp__send_http2_request — Send HTTP/2 requests
• mcp__burp__create_repeater_tab — Save interesting requests for operator review
• mcp__burp__send_to_intruder — Set up parameter fuzzing
• mcp__burp__get_proxy_http_history — Review traffic history
• mcp__burp__url_encode / mcp__burp__base64_encode — Encode payloads

3.2 Request Construction

Build raw HTTP requests with proper formatting:

• Use actual newline characters in the content string (not literal \r\n escape sequences)
• Include Host, Content-Type, and Content-Length headers
• For POST/PUT, calculate Content-Length as the exact byte count of the body — off-by-one causes silent timeouts (too high) or empty 400s (too low)
• Carry session tokens from authentication step
• Send one baseline request first before parallelizing — a bad Content-Length in parallel calls causes all sibling calls to fail
• Use HTTP/1.1 for non-TLS targets (HTTP/2 requires usesHttps: true)

3.3 Testing Sequence

1. Baseline requests — Send legitimate requests first to establish normal behavior
2. Authentication — Log in and capture session tokens
3. Execute test cases — In priority order from the approved plan
4. Capture evidence — Save request/response for every confirmed finding
5. Create Repeater tabs — For confirmed vulns so operator can replay

3.4 Per-Vulnerability Testing

For each vulnerability class, follow the specific playbook in references/vulnerability-playbooks.md.

Use only non-destructive payloads from references/payload-library.md.

Safety rules:

• NEVER send DELETE requests to production data unless explicitly approved
• NEVER attempt DoS or resource exhaustion
• Use math-based or reflection payloads to prove injection (e.g., 1+1, {{7*7}})
• For XSS, use alert/console payloads, not cookie exfiltration
• For SQLi, use UNION SELECT or boolean-based detection, not DROP/DELETE
• For RCE, use id, whoami, or echo — never destructive commands
• For SSRF, target localhost or Burp Collaborator — never external infrastructure

3.5 Evidence Collection

For each confirmed vulnerability:

1. Save the proof-of-concept request to a Repeater tab with a descriptive name
2. Record the full request and response
3. Note the specific indicator that confirms exploitation (e.g., "response contains 49 confirming SSTI {{7*7}}")

---

Phase 4: Vulnerability Reporting

Goal: Produce a structured report for every confirmed finding.

4.1 Report Format

Generate the report following references/report-template.md.

Save to file: After presenting the report, ask the operator:

• "Would you like me to save this report as a Markdown file in the project directory?"
• If yes, write whitebox-pentest-report.md to the project's root directory (or a path the operator specifies).

4.2 Per-Finding Structure

Each finding MUST include:

| Field | Content | |---|---| | ID | VULN-YYYY-NNN sequential identifier | | Title | Concise vulnerability title | | Severity | Critical / High / Medium / Low / Informational | | CVSS 3.1 | Score and vector string | | CWE | CWE ID and name (e.g., CWE-89: SQL Injection). Every finding must have a CWE. See CWE Quick Reference in references/report-template.md. | | Affected endpoint | METHOD /path | | Affected code | file:line with relevant code snippet | | Description | What the vulnerability is and why it exists | | Proof of concept | Full HTTP request and response from Burp | | Impact | What an attacker can achieve | | Remediation | Code-level fix with before/after example |

4.3 CVSS Scoring Guide

Use CVSS 3.1 base scores:

| Severity | Score Range | Examples | |---|---|---| | Critical | 9.0-10.0 | Unauthenticated RCE, SQL injection with admin access | | High | 7.0-8.9 | Authenticated RCE, auth bypass, stored XSS on admin panel | | Medium | 4.0-6.9 | Reflected XSS, CSRF on state-changing actions, IDOR | | Low | 0.1-3.9 | Information disclosure, missing headers, verbose errors | | Info | 0.0 | Best practice deviations, hardening recommendations |

4.4 Remediation Quality

Every remediation MUST include:

• Specific code change (not just "sanitize input")
• Before and after code showing the fix
• Library/function to use (e.g., "use parameterized queries with db.query($1, [value])")
• Defense-in-depth recommendations where applicable

---

Framework-Specific Quick Reference

Route Discovery Cheat Sheet

| Framework | Where to look | |---|---| | Express.js | app.get/post/put/delete(), router.*(), route files | | Flask | @app.route(), @blueprint.route() | | Django | urls.py → urlpatterns, path(), re_path() | | Rails | config/routes.rb, resources, get/post/match | | Spring | @RequestMapping, @GetMapping, @PostMapping | | Laravel | routes/web.php, routes/api.php, Route:: | | FastAPI | @app.get/post(), APIRouter | | Go net/http | http.HandleFunc(), mux.HandleFunc() |

Auth Pattern Cheat Sheet

| Pattern | Grep for | |---|---| | JWT | jwt.sign, jwt.verify, jsonwebtoken, PyJWT | | Session | express-session, flask.session, request.session | | Passport | passport.authenticate, passport.use | | OAuth | oauth, client_id, client_secret, authorization_code | | API Key | x-api-key, apikey, api_key header checks | | Basic Auth | Authorization: Basic, base64 decode patterns |

---

Important Reminders

• Never bypass the approval gate. Phase 3 requires explicit operator consent.
• All HTTP traffic through Burp MCP. No curl, no fetch, no requests library.
• Non-destructive only. Prove vulnerabilities without causing damage.
• Source code first. Every dynamic test must trace back to a code-level finding.
• Evidence is mandatory. No finding without a captured request/response pair.