Neura Market Web Application Penetration Test Reference

Purpose and When to Use

This reference describes a phased, proof-based web application penetration test with strict scope and authorization controls. Use it when performing authorized security testing of a web application, when a reproducible, evidence-driven workflow is required, or when the operator has written permission to test the target.

Prerequisites

Before starting any engagement, ensure the following are in place:

• Written authorization from the target owner, or the operator owns the application.
• Target URL(s) and IP(s) are known.
• Scope allowlist is defined.
• Engagement duration is agreed.
• Operator name is recorded.
• References and templates are available: references/scope-enforcement.md, references/vuln-taxonomy.md, references/exploitation-techniques.md, references/bypass-techniques.md, templates/authorization.md, templates/pentest-report.md, templates/exploitation-queue.json, scripts/recon-scan.sh.
• For source code analysis: read access to application source.
• For SSRF callback: tester-controlled callback host.
• For destructive payloads: explicit operator approval.

Parameters

The following parameters are required for every engagement:

• Target URL: The base URL of the web application to test.
• Engagement duration: Maximum hours the engagement may run.
• Authorization basis: Ownership or written authorization from a named entity.
• Scope allowlist: List of hostnames or CIDRs in scope.
• Out-of-scope items: Production systems, third-party services, etc. excluded from testing.
• Operator name: Name of the user driving the session.

Capabilities

• Enforces authorization gate before any active scanning.
• Maintains a scope allowlist and refuses off-scope requests.
• Performs optional source code analysis (Phase 1).
• Conducts read-only reconnaissance (Phase 2).
• Stages vulnerability analysis per class (Phase 3).
• Executes proof-based exploitation with bypass exhaustion (Phase 4).
• Generates a structured report with CVSS-scored findings (Phase 5).
• Redacts sensitive data in chat logs.
• Rate-limits active requests to 200ms between hosts.

Phase 0: Engagement Setup

This phase establishes the engagement directory, captures authorization, and builds the scope allowlist.

Procedure

1. Create the engagement directory with subdirectories for evidence, findings, and reports using the following command:

ENGAGEMENT=engagement-$(date +%Y%m%d-%H%M%S)
mkdir -p "$ENGAGEMENT"/{evidence,findings,reports}
cd "$ENGAGEMENT"

2. Ask the user verbatim: "Confirm: (a) the target URL is [X], (b) you own this application or have written authorization to test it, and (c) the engagement may run for up to [N] hours starting now. Reply 'authorized' to proceed."

3. Wait for an explicit authorized response. Any other answer stops the process.

4. Record authorization to engagement/authorization.md using templates/authorization.md. Include target URLs/IPs, authorization basis, engagement window, out-of-scope items, and operator name.

5. Build engagement/scope.txt with one hostname or CIDR per line. Example:

localhost
127.0.0.1
staging.example.com
192.168.1.0/24    # internal lab only, with operator OK

6. Read references/scope-enforcement.md before the first active request.

Phase 1: Pre-Recon (Code Analysis, Optional)

This phase is optional and performed only if source code access is available. It is offline work with no traffic to the target.

Procedure

1. Skip if no source access (black-box testing).

2. If source is available, map the architecture: framework, routing, and middleware stack.

3. Inventory sinks: execute(, os.system(, eval(, template render, file read/write, and redirect target.

4. Map authentication: session cookie vs JWT, OAuth flows, password reset, privileged endpoints.

5. Identify trust boundaries: authenticated vs unauthenticated, request.* sources.

6. Perform backward taint analysis from each sink to the request source. Early-terminate when proper sanitization is found (e.g., shlex.quote).

7. Output evidence/pre-recon.md with architecture map, sink inventory, and suspected vulnerable code paths.

Phase 2: Recon (Live, Read-Only)

This phase involves live reconnaissance against the target, but no malicious payloads are sent.

Procedure

1. Verify scope: resolve every target hostname to IP, confirm IPs are in scope.

2. If scope permits port scanning, run:

nmap -sT -T3 --top-ports 100 -oN evidence/nmap.txt $TARGET

Use -T3 for timing. Do not use -T4/-T5 without operator approval.

3. Fingerprint technology:

whatweb -v $TARGET_URL > evidence/whatweb.txt
curl -sIk $TARGET_URL > evidence/headers.txt

4. Discover endpoints: crawl the app using browser_navigate and browser_get_images, inspect robots.txt, sitemap.xml, .well-known/*, and capture XHR/fetch calls via dev tools network panel.

5. Identify the authentication surface: login, registration, password reset, session cookie names, token formats. Do not send credentials yet.

6. Correlate with pre-recon findings: mark whether each pre-recon finding is reachable on the live surface.

7. Output evidence/recon.md with endpoints, technologies, auth model, and input vectors.

Phase 3: Vulnerability Analysis

This phase stages vulnerability analysis per class. No malicious payloads are sent yet.

Procedure

1. Use delegate_task per vulnerability class: injection, xss, auth, authz, ssrf, infra. Refer to references/vuln-taxonomy.md and references/exploitation-techniques.md.

2. Each subagent reads evidence/recon.md and evidence/pre-recon.md if present.

3. Each subagent produces findings/-queue.json using templates/exploitation-queue.json.

4. Each queue entry includes: id, vuln class, source (file:line if known), endpoint, parameter, slot type, suspected defense, verdict (identified, partial, confirmed, critical), witness payload, confidence (0-1), and notes.

Phase 4: Exploitation (Proof-Based, Conditional)

This phase executes proof-based exploitation with bypass exhaustion. Only actionable entries from the analysis queue are processed.

Procedure

1. Run a sub-agent per class only if the analysis queue has actionable entries (verdict identified or partial).

2. For each candidate, perform a pre-send check: is the host in scope? Is the auth gate satisfied? Is the payload approved if destructive?

3. Send a witness payload that provides minimal proof. Examples:

   • SQLi: ' AND 1=1-- then ' AND 1=2--
   • XSS: benign marker like <img src=x>. Never use alert(1) in stored XSS.
   • Blind injection: SLEEP(5) and measure time response.
   • SSRF: use a tester-controlled callback host.

4. Verify the witness fires. For blind injection, use a sleep probe and time response. For SSRF, use a tester-controlled callback host.

5. Promote the level:

   • L1 Identified: Pattern matched, no behavior change.
   • L2 Partial: Sink reached but defense in place.
   • L3 Confirmed: Payload changed app behavior observably.
   • L4 Critical: Data extracted, code executed, access escalated.

6. Exhaust the bypass set from references/bypass-techniques.md before classifying as a false positive. If all bypasses fail, set verdict: false_positive.

7. Record evidence for every L3/L4 finding: full request (method, URL, headers, body), response (status, headers, relevant body excerpt), reproducer command (curl one-liner), and impact statement.

8. Redact captured credentials/tokens to the last 6 characters in chat. Store the full value in findings/secrets-vault.md (gitignored). Redact other users' PII. Test credentials are fine to keep.

9. Output findings/exploitation-evidence.md.

Phase 5: Reporting

This phase generates the final report.

Procedure

1. Generate the final report using templates/pentest-report.md.

2. Include sections:

   • Executive summary
   • Engagement scope (from engagement/scope.txt)
   • Authorization (from engagement/authorization.md)
   • Findings (L3/L4 only with proof)
   • Not-exploited candidates (L1/L2 with notes)
   • Out-of-scope observations
   • Methodology/tools used
   • Limitations and what was NOT tested

3. Per finding: title, severity (CVSS 3.1), CWE, affected endpoints, proof (request+response excerpt), reproduction steps, impact, and remediation.

4. Assign CVSS only to L3/L4 findings. L1/L2 findings are candidates pending verification and do not get CVSS scores.

Constraints and Caveats

• No exploit, no report: Every finding requires reproducible evidence.
• Bounded scope: Every active request must be against a pre-declared target. Off-scope hosts are refused.
• Bypass exhaustion before false-positive dismissal: Try the bypass set before declaring a payload blocked.
• Authorization gate: Confirm written authorization before the first active scan. Record in engagement/authorization.md.
• No production systems without paper: Default targets are staging, local docker, or dedicated test instances.
• Cloud metadata is off by default: Do not probe 169.254.169.254, metadata.google.internal, 100.100.100.200, or [fd00:ec2::254] unless explicitly authorized for SSRF-to-metadata.
• Destructive payloads need approval: SQLi DROP/DELETE, filesystem-write SSTI, command injection with rm, shutdown, mkfs, etc. must be approved first. Use approval.py if available.
• Aux-client leakage risk: Redact captured tokens/credentials to the last 6 characters before logging in chat. Full values go to engagement/evidence/ files. Set auxiliary.title_generation.enabled: false in ~/.hermes/config.yaml to prevent title generation leakage.
• Rate limit yourself: Default 200ms between active requests against any single host.
• Report is a security assessment, not a PASS: Language must reflect "no exploitable issues found in scope X within time T using methods Y".
• Do not follow off-scope redirects without user confirmation.
• Do not send credentials during recon phase.
• Never use alert(1) in stored XSS (fires for other users in shared environments).
• For blind injection, use a sleep probe and time response.
• For SSRF, use a tester-controlled callback host, not public services like webhook.site for sensitive engagements.
• L1/L2 findings do not get CVSS scores.
• If a finding impacts production data without destructive testing approval, STOP and ask.
• If target returns 503/429 storms, back off and reconvene with the operator.
• If discovering something outside contracted scope, STOP, document, and report to the operator. Do not pivot without explicit approval.

Failure Modes

• User revokes authorization.
• Candidate finding impacts production data without destructive testing approval.
• Target returns 503/429 storms.
• Discovering something outside contracted scope.
• Authorization not obtained before active scanning.
• Off-scope request sent due to DNS resolution or redirect.
• Destructive payload sent without approval.
• Cloud metadata probed without authorization.
• Rate limit bypassed without operator approval.
• Sensitive data leaked via aux-client compression/title-generation.
• False positive declared without exhausting bypass set.