A retailer's web application firewall logs a login attempt where the username field holds ' OR 1=1--. Seconds later the same user reaches an admin page they never should have seen. Nobody stole a password. The attacker typed a few characters into a form and the application handed them a query it was never meant to run.
That is injection, and it is the first application attack listed on the CompTIA Security+ SY0-801 exam under objective 2.5, which asks you to analyze indicators of malicious activity. Injection happens whenever an application takes input from a user and mixes it into a command, a query, or a page without keeping the two apart. This lesson covers the families you need to recognize: SQL injection, command injection, LDAP and XML injection, and cross-site scripting. For each one you'll see what the attacker sends, what the defender finds in the logs, and the input handling that shuts it down.
Injection happens when input is treated as code
Every injection attack is the same mistake made against a different interpreter. The application builds a string by gluing together instructions it wrote and data a user supplied, then hands the whole string to an interpreter: a database engine, a shell, a directory service, an XML parser, or a browser. The interpreter has no way to know which part was trusted instruction and which part came from a stranger, so it executes all of it. The attacker's job is to supply input that the interpreter reads as new instructions rather than as data.
That single idea explains why the payloads look the way they do. The attacker sends characters that are special to the target interpreter: a single quote and comment marker for SQL, a semicolon for a shell, an angle bracket for HTML. On the exam, when a scenario shows input with syntax that belongs to a query, a command, or a markup language, the right answer is usually some form of injection.
The defender's view is the log. Injection attempts rarely arrive one at a time. A scanner or an attacker probing a parameter throws dozens of variants at the same field, so the indicator is often a burst of odd-looking values hitting one URL parameter or form field, frequently URL-encoded so the payload survives transport.
SQL injection turns input into part of the query
SQL injection targets the database. The application means to run a lookup like SELECT * FROM users WHERE name = 'input', and the attacker supplies input that closes the quote and adds their own clause. The textbook payload is ' OR 1=1--, which turns the condition into something always true and comments out the rest of the query, so a login check that should match one row matches every row.
In a raw access log the payload is usually URL-encoded, because the browser or tool escapes the special characters. You will see it as query-string noise:
203.0.113.9 - - [21/Oct/2026:14:02:11 +0000] "GET /items?id=5%27%20OR%201%3D1-- HTTP/1.1" 200 8122
203.0.113.9 - - [21/Oct/2026:14:02:14 +0000] "GET /items?id=5%27%20UNION%20SELECT%20username,password%20FROM%20users-- HTTP/1.1" 200 9330
Decoded, %27 is a single quote, %3D is an equals sign, and %20 is a space, so the first request is id=5' OR 1=1-- and the second is a UNION SELECT that appends attacker-chosen columns onto the result set. A UNION SELECT against a parameter is a strong indicator: the attacker is trying to pull data out of other tables through a query that was only meant to fetch one item.
Not every database tells the attacker what it found. When the application shows no query output and no error, attackers switch to blind SQL injection: they ask yes-or-no questions and read the answer from the application's behavior. A payload like ' AND 1=1-- versus ' AND 1=2-- returns a normal page in one case and an empty one in the other, letting the attacker extract data one bit at a time. Time-based blind injection uses a payload that tells the database to pause, such as a sleep function, and the attacker measures how long the response takes. In the logs, blind injection looks like many near-identical requests to one parameter, sometimes with response times that jump from milliseconds to several seconds.