14.1 SQL, Command, XSS, and SSTI Injection

On CompTIA PenTest+ PT0-003, Domain 4 is Attacks and Exploits (35 percent of the exam). Objective 4.5 Given a scenario, perform application attacks using the appropriate tools is the web-application matching chapter. You already ranked the target on 4.1. 4.5 asks you to name the application attack that fits the evidence and the tool that intercepts or automates it. This section is the injection family: SQL injection (SQLi), command injection, cross-site scripting (XSS), and server-side template injection (SSTI). CSRF, SSRF, IDOR, traversal, file inclusion, API abuse, JWT work, brute-force, and collision belong in the next two sections. Domain 4.5 is not Domain 3: a Nikto row that mentions a form is discovery. It is also not 4.3 LDAP injection: directory-filter tampering is an authentication attack.

SQL injection: the query is the interpreter

SQL injection happens when the application concatenates untrusted input into a Structured Query Language statement. The database then treats the attacker's fragment as syntax, not as a bound value. Identification: intercept the request in Burp Suite or OWASP Zed Attack Proxy (ZAP), change one parameter, and watch query behavior change — a login that succeeds without a password, a search that returns extra rows, or an error that dumps a table name.

A classic pattern you should recognize, not a payload pack, is ' OR 1=1--. The quote closes a string, OR 1=1 makes the predicate true, and -- comments out the remainder. CompTIA wants that pattern classified as SQLi, not XSS and not CSRF.

Know four conceptual SQLi styles. You do not need a warehouse of queries.

• Union-based: the tester appends a UNION SELECT so extra columns from another table ride back in the same result set. Identification: the page already reflects query results in a table or list.
• Error-based: database errors print to the page or API. The error text leaks schema, column types, or host names.
• Boolean-based: there is no useful error and no extra row, but a true condition and a false condition produce different pages or different JSON.
• Blind (including time-based conceptually): nothing in the body changes except timing or a side channel. The tester infers a bit at a time. Blind is still SQLi. It is not "not injectable."

Impact: authentication bypass, disclosure of other tenants' rows, and sometimes arbitrary code execution (ACE) if the database engine exposes a dangerous routine. Remediation the exam expects: parameterize the query (prepared statements, bound parameters). String-cleaning filters are weaker than parameterization. Output encoding is the XSS control, not the SQLi control.

sqlmap is the 4.5 automation tool for SQLi. You feed it a request you already captured — URL, POST body, or a saved intercept — and it tests whether the parameter is injectable. Exam trap: answering sqlmap for every web finding. sqlmap is SQLi. It is not XSS, not SSTI, and not a WordPress CMS scanner. Trap two: answering Hydra because the stem is a login form. Online guessing against /login is brute-force, also listed on 4.5, but ' OR 1=1-- in the username field is injection, not guessing. Trap three: calling 4.3 LDAP injection a 4.5 SQL finding. Filter metacharacters against a directory are 4.3.

Command injection: the shell is the interpreter

Command injection concatenates untrusted input into an operating-system command line. Shell metacharacters such as ;, |, and backticks append or substitute extra commands. Identification: a ping, lookup, image-convert, or backup feature that takes a host name or file name and whose output looks like shell output. Impact is ACE on the web server under the application-pool identity — often more severe than dumping one SQL table.

Command injection is not SQLi. Semicolons terminate shell lists; they are not automatically SQL. It is also not SSTI: template engines evaluate expressions in-process and do not need a shell. Remediation: do not invoke a shell. Call APIs with argument arrays, and allowlist values. Parameterizing SQL does not fix a system() call. Burp or ZAP still intercepts the HTTP parameter; sqlmap is the wrong logo unless a SQL error also appeared.

XSS: the browser is the interpreter

Cross-site scripting injects script or markup that the victim's browser executes in the application's origin. Three exam flavors:

• Reflected XSS: the payload rides in the request (query string, header, or form) and is echoed in that response. A crafted link is the usual delivery.
• Stored (persistent) XSS: the payload is saved — comment, profile, ticket — and executes later in other users' browsers, including admins.
• DOM-based XSS: server HTML may look clean; client-side JavaScript reads untrusted data (location, postMessage, a URL fragment) and writes it into the DOM unsafely.

Impact: session-cookie theft (which becomes session hijacking in section 14.3), fake login forms, and any action the victim is allowed to perform. Stored XSS in an admin panel is a privilege path, not a defacement footnote. Remediation: output encode for the context (HTML body, attribute, JavaScript). A Content Security Policy is defense in depth. Parameterized SQL does not fix XSS.

Exam trap: calling every reflected string XSS. If the page shows 49 after you submit a template expression, that is SSTI evaluation, not a script tag. Trap two: calling XSS "SQL in the browser." Trap three: treating DOM XSS as "not XSS" because the server HTML never contained a tag.

SSTI: the template engine is the interpreter

Server-side template injection happens when user input is embedded into a template and the engine evaluates expressions. Template engines (Jinja2, Twig, FreeMarker, and similar families) are designed to execute logic. If an attacker controls an expression, the engine may read objects or call functions the developer never intended. Identification: submitted template syntax is evaluated — a harmless arithmetic expression becomes a number — rather than encoded as text. Impact is often ACE or secret disclosure inside the application process, closer to command injection in severity than to reflected XSS.

SSTI is not XSS. XSS executes in the browser. SSTI executes on the server during render. Remediation: never concatenate untrusted strings into templates; pass data as template variables, and disable dangerous engine features. Output encoding still matters for XSS on the same page, but it is not the SSTI fix. sqlmap will not classify SSTI.

Intercept first, automate second

Burp Suite and ZAP are the 4.5 intercept proxies. They sit between your browser and the application so you can see parameters, replay requests, and confirm whether a change altered query, shell, HTML, or template behavior. sqlmap consumes a request those proxies captured when the attack under test is SQLi. Gobuster, DirBuster, and Wfuzz discover paths; they do not classify injection. WPScan is WordPress-specific. Postman is for APIs. TruffleHog finds secrets in repositories, not injectable columns.

Worked matching

An in-scope shop has four parameters. Username admin' OR 1=1-- logs the tester in without a password: SQLi — prove it through Burp or ZAP, automate only with sqlmap if the rules of engagement allow. A "resolve hostname" field that treats | as a pipe: command injection, ACE impact, not a UNION SELECT. A search box that echoes a script in the results page for that request: reflected XSS; the same script stored in a product review is stored XSS; a client-only innerHTML sink is DOM XSS. A profile field that evaluates a template arithmetic expression to a number: SSTI. If the stem is instead ten thousand password guesses against /login with no SQL metacharacters, that is brute-force, not injection. Name the interpreter first. Then pick the logo.