Exercise 2: Vulnerability-Class Matching vs. CVE-Based Matching — Possible Solution ==================================================================== WHAT VULNERABILITY-CLASS MATCHING IS ------------------------------ Per this chapter, 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." This approach works by recognizing a general PATTERN of weakness (e.g. user input reaching a database query without parameterization) rather than looking up a specific, already-known flaw, because no one else has ever seen or documented this particular organization's own custom code. EXAMPLE OF WHEN VULNERABILITY-CLASS MATCHING IS THE RIGHT TOOL ------------------------------ A company's own internally-built customer portal has a search feature built specifically for that company, using code no one outside the company has ever reviewed. There is no CVE entry for this specific application, because it was never a publicly known, previously disclosed product. The only way to identify a potential SQL injection here is applying sqli1's own general knowledge of the vulnerability CLASS — recognizing the pattern of unparameterized user input reaching a query — directly against this specific, unique piece of code. WHAT CVE-BASED MATCHING IS ------------------------------ Per this chapter, CVE/NVD 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." This approach works by taking a SPECIFIC, already-identified piece of software and its exact version (from pentest1-5's own banner-grabbing/version-detection output) and checking it against a public database of already-disclosed flaws. EXAMPLE OF WHEN CVE-BASED MATCHING IS THE RIGHT TOOL ------------------------------ pentest1-5's version detection identifies a server running a specific, outdated version of a well-known web server software. Because this is widely-used, publicly available software, security researchers have likely already found and publicly documented specific vulnerabilities affecting that exact version, each with its own CVE identifier. Here, the right approach isn't reasoning from a general vulnerability class — it's directly checking the identified version number against the CVE/NVD database to see what's already known to be wrong with it. WHY THIS WORKS AS AN ANSWER ------------------------------ It defines both approaches using the chapter's own stated distinction (custom/undocumented code vs. known/documented third-party software) and gives one concrete, distinct example for each that couldn't be solved correctly by the other approach.