Vulnerability Analysis — The Toolkit This Site Already Built

Penetration Testing Methodology

Chapter 6 · Vulnerability Analysis — The Toolkit This Site Already Built

pentest1-1 opened this course with a claim worth restating in full now that it's time to prove it: a pentest is a repeatable, disciplined process, and every vulnerability class this site already teaches in depth is a tool this process calls on during one specific phase — not the process itself. This is that phase.

From Attack Surface Map to Candidate Vulnerabilities

pentest1-5 produced a real, evidence-based map: which hosts are alive, which ports are open, what service versions are running. This phase's job is to take that concrete map and match it against already-documented categories of weakness — not to invent new attack techniques, but to recognize which known vulnerability classes plausibly apply to what was actually found.

The Toolkit This Site Already Built

This site already teaches the vulnerability-class knowledge this phase draws on, in real depth, across six existing Security courses:

Attack-surface signal from pentest1-5	Relevant course	What it teaches
A page reflecting user input back into its own output	xss1	Cross-Site Scripting — the three types, injection contexts, defenses
A form performing a state-changing action	csrf1	CSRF — the confused-deputy pattern, tokens, SameSite cookies
A database-backed feature accepting user input (search, filters, login)	sqli1	SQL Injection — data-vs-code, UNION/blind techniques, parameterization
A login form or session-based feature	bc1	Authentication & Session Security — password storage, sessions, MFA, JWTs
An exposed or reachable database port	dbsec1	Database Security — access control, network exposure, encryption
Everything else — a systematic survey pass	owasp1	The full OWASP Top 10, including categories with no dedicated course (Insecure Design, Misconfiguration, Outdated Components, Integrity Failures, Logging Failures, SSRF)

Each of those courses taught how a specific vulnerability class works, how to recognize it, and how to defend against it. This phase of a real engagement is the moment that same knowledge gets applied in the other direction — using it to recognize a discovered piece of attack surface as a plausible candidate worth investigating further, rather than devising something novel from scratch.

CVE Databases & Known-Vulnerability Matching

pentest1-5's own banner-grabbing and version-detection output enables a genuinely different kind of matching: once a specific service and version is known, it can be checked against public vulnerability databases (CVE/NVD) for already-documented, publicly disclosed flaws affecting that exact version.

This is a meaningfully different tool than the vulnerability-class matching above. Vulnerability-class knowledge (from xss1/csrf1/sqli1/bc1) is the right tool for an organization's own custom application code — there's no CVE for someone's own bespoke bug, since it was never publicly disclosed anywhere. CVE matching is the right tool for known third-party software — an outdated web server, a specific library version — where the exact flaw has already been found and documented by someone else.

Matching, Not Inventing

It's worth restating the chapter's own core discipline directly: this phase's job is to recognize known patterns in what was actually discovered, not to devise brand-new attack techniques. Discovering genuinely novel vulnerabilities is a distinct, much rarer skill. The overwhelming majority of real, professional penetration tests find real, exploitable issues through exactly this kind of methodical, thorough matching against an already-documented body of knowledge — not by stumbling onto something never seen before.

A pattern match isn't proof of a real vulnerability

Finding an attack-surface element that superficially resembles a known vulnerability class doesn't confirm the vulnerability is actually real or exploitable — a login form might already be protected by rate limiting and MFA; a reflected input might already be properly encoded. This phase produces candidates, not confirmed findings. pentest1-7 is specifically about actually proving impact for a candidate, rather than assuming impact from a surface-level resemblance alone.

This is the chapter pentest1-1 was building toward

pentest1-1 named the site's own vulnerability courses as tools this process calls on, not the process itself. This chapter is where that claim becomes concrete and literal — every one of those six courses just became a direct input to a specific phase of a real methodology, exactly as promised.

Hands-On Exercises

Exercise 1

pentest1-5's scan found: a login form, a product search feature querying a database, and a directly reachable database port on 3306. Using this chapter's own table, identify which earlier course's vulnerability-class material is most directly relevant to each of the three findings, and why.

📄 View solution

Exercise 2

Explain the difference between vulnerability-class matching (the xss1/csrf1/sqli1/bc1 style) and CVE-based known-vulnerability matching, and give one example of when each is the correct tool to use.

📄 View solution

Exercise 3

Using this chapter's own warn-box, explain why finding a surface-level pattern match to a known vulnerability class isn't the same as confirming a real, exploitable vulnerability — and name the specific chapter where that gap actually gets closed.

📄 View solution

Chapter 6 Quick Reference

This phase matches pentest1-5's own attack surface map against KNOWN vulnerability classes — it doesn't invent new attack techniques
The site's own toolkit: xss1, csrf1, sqli1, bc1, dbsec1 for specific vulnerability classes; owasp1 as the systematic survey pass covering everything else
Vulnerability-class matching — the right tool for custom application code (no CVE exists for a bespoke bug) · CVE/NVD matching — the right tool for known third-party software/services with a specific, already-documented version
A surface-level pattern match produces a candidate, not a confirmed finding — pentest1-7 proves actual impact
This chapter is the direct, literal payoff of pentest1-1's own opening claim about this site's vulnerability courses being "tools this process calls on"
Next chapter: Exploitation — Proving Impact Without Causing Harm