Pentestas / help

Validation

Traditional scanners dump everything they flag into a CSV and leave you to triage. Pentestas inverts that — findings go through an Accuracy Gate before they're persisted, and only survivors are shown.

The gate

Every raw detection passes through three stages:

1. Junk filter

Fast regex-based checks: an SQLi payload that "extracted" style.css (a CSS filename) is junk; an XSS reflection that echoed your payload as a JSON-escaped string inside a plain JSON response is not exploitable. SSRF detectors strip the original payload from the response before pattern-matching, so a form field that simply echoes back 127.0.0.1 doesn't masquerade as an SSRF. Anything that clearly can't be weaponised is dropped here.

2. Second-pass verifier

Each vulnerability class has an orthogonal verifier that uses a different signal than the original detector. Examples:

  • SQLi: original detector sees a SQL error message. Verifier extracts actual database content with a UNION or boolean-blind payload — version(), a table name, a row from information_schema. Findings ship only when the response body contains real DB-shaped data; CSS filenames, framework asset names, and HTML fragments are rejected as junk extractions.
  • Default credentials: original detector logs in and reads the response. Verifier requires a new session cookie as proof — same Set-Cookie name + a new value compared to the pre-login baseline — and confirms the post-login response doesn't redirect back to a /login* path. CSRF tokens are stripped before baseline comparison so they don't masquerade as session changes. Capped at 3 confirmed findings per scan.
  • XSS: original detector sees payload reflected. Verifier renders the page in a headless Chromium with a JS hook that fires on script execution. If no alert fires, the payload was string-inserted but never executed.
  • SSRF: original detector probes URLs that should fetch internal resources. Verifier checks the response body — with the original payload string stripped first — for cloud-metadata signatures (ami-id, iam/security-credentials, EC2 IMDS keys), private-IP banners, or file-URL leakage. A form field that simply echoes the payload back to the user is rejected; an error counter bails the probe after 3 consecutive boring responses.
  • IDOR: original detector sees a 200 on a different user's ID. Verifier compares response bodies; if the response is identical (no user-specific content), it's a cache artifact, not an IDOR.
  • Login-panel discovery: a path that 302s to /login is the application's redirect target, not a login panel itself. Pentestas normalises URLs and dedupes; one panel finding per host even if many paths funnel into it.
  • Version-based CVE matches: the response that anchored the version detection must return 200. A 404 page that happens to contain Apache/2.4.49 in a footer no longer triggers a CVE finding.

If the verifier doesn't confirm, the finding is demoted to MEDIUM with a "[Accuracy Gate] external replay did not reproduce the claimed evidence — treat as a lead requiring manual verification" caveat appended to the evidence. The finding still ships.

Why not just drop it? Verifier false-negatives are real. Until April 2026 the gate dropped findings outright; we discovered that a single payload-shape bug in the SQLi verifier was silently dropping legit CRITICAL findings on every vuln-bank-class scan. Demote-with-caveat preserves the operator's ability to triage while still flagging the verification gap. The original detection's curl one-liner is stripped from the evidence so we never hand a developer a "reproduction" that doesn't reproduce.

Static-pass-through verifiers

Some finding types are static observations of the scanner's own state (TLS cipher, response header presence, JWT algorithm). External replay can't prove or disprove them. The gate registers a pass-through verifier for these so they're never demoted by the "no verifier" path:

INSECURE_TRANSPORT, MISSING_HSTS, MISSING_CSP, MISSING_X_FRAME_OPTIONS, MISSING_X_CONTENT_TYPE_OPTIONS, MISSING_REFERRER_POLICY, MISSING_PERMISSIONS_POLICY, SECURE_FLAG_MISSING, CLICKJACKING, TECHNOLOGY_DETECTED, FINGERPRINT, BANNER_LEAK, VULNERABLE_SOFTWARE, DEFAULT_CREDENTIALS, PREDICTABLE_TOKEN, CREDENTIAL_DUMP, MASS_ASSIGNMENT, AI_PROMPT_INJECTION, WERKZEUG_DEBUGGER, GRAPHQL_INTROSPECTION, AUTH_RECOVERY_LEAK, BUSINESS_LOGIC, RACE_CONDITION.

3. AI filter (Pro+)

Claude reads the verified finding + evidence and judges exploitability in context. Can mark as false-positive (dropping the finding), keep-as-is (standard), or bump/lower severity.

What "verified" means in the UI

Every finding has a verified boolean:

  • true — the second-pass verifier re-confirmed the finding independently.
  • false — detector fired, but the verifier wasn't applicable or didn't confirm. Finding is still persisted (the signal is real enough to investigate) but lacks the higher-confidence badge.

Filter for verified:true in the findings list if you only want high-confidence items.

What doesn't get filtered

The gate is tuned to favour precision. Things that survive even when they might be benign:

  • Exploitable-in-theory but low impact — e.g. a reflected XSS on a logout endpoint. The probe confirms; rating is LOW.
  • Missing headers — HSTS, CSP, X-Frame-Options missing. Can't have a false positive here; the check is a header presence test.
  • Open ports + banners — INFO-level disclosures that aren't vulns on their own.

What gets dropped

  • SQL error pages without injection semantics (just a stack trace).
  • SQLi findings whose "extracted data" is a CSS filename, a JS chunk hash, or HTML markup — proof must look like database content.
  • Default-credentials findings where the post-login response didn't issue a new session cookie or redirected back to /login.
  • XSS payload reflections in escaped JSON / quoted HTML attributes that aren't executable.
  • SSRF findings where the "leak" is just the form field echoing the payload back to the user.
  • Login panels at paths that simply 302 to the canonical /login URL — deduped to one per host.
  • Open-redirect probes on URLs that redirect anywhere based on ?next=.
  • Any finding whose "evidence" is empty or obviously templated.

Why this matters

Typical open-source scanners produce 70–90% false positives on complex apps. You spend Monday triaging Sunday's scan. Pentestas targets <10% false positive rate — the Accuracy Gate + AI filter is how we get there.

See also