SQL injection

Objective 4.4 in this course covers web application attacks — CompTIA describes it as performing SQL injection, cross-site scripting and directory traversal. This lesson takes SQL injection and is the applied lab for the objective. Runs against your own deliberately-weak application, in the lab from lesson 2.

Why this matters

SQL injection has been near the top of every list of serious web vulnerabilities for two decades, and it remains common because it is easy to introduce and easy to miss. It is examined by name, and it is the clearest example in the course of a whole class of flaw — untrusted input reaching an interpreter — so what you learn here transfers to command injection and the other injection families.

The lesson

Where untrusted input reaches a query

The flaw exists wherever data from the user becomes part of a database query's structure rather than staying data.

An application builds a query, and if it builds it by joining strings together with user input in the middle, the input can change what the query means — not just the value it searches for, but the logic. The database has no way to tell the developer's intended query from the attacker's altered one; it received one string and runs it.

The entry points are anywhere input reaches a query: form fields, URL parameters, headers, cookies, and — the ones people forget — data arriving from another system, and values stored earlier and used later. That last is second-order injection, where the payload is stored innocuously and triggers when some other code path uses it in a query.

In-band, blind and time-based, and telling them apart

How you confirm and exploit depends on what the application shows you back:

• In-band injection returns results directly — the data you asked for appears in the response, or an error message reveals the query. The easiest to confirm.
• Blind boolean injection returns no data, but the application behaves differently for a true condition than a false one — a different page, a different length. You extract data one yes/no question at a time.
• Time-based blind injection returns nothing and behaves identically either way, so you make the database pause on a true condition and measure the response time. Slow but reliable when nothing else is visible.

Recognising which you are dealing with is the exam-relevant skill, and it maps onto lesson 18's ladder: an in-band result is direct evidence; a timing difference is the condition observed without extracting anything, which is often all the proof a finding needs.

Proving it without destroying the data

This is where lesson 18's caution meets the most destructive vulnerability class in the domain.

• Confirm read access, not write. A query that returns a version string or a single harmless value proves the injection without touching data.
• Never demonstrate with a destructive statement. Deleting or modifying data to "prove" injection is exactly the destructive-proof-on-production mistake lesson 18 forbids, and it is unrecoverable.
• Prove impact on your replica. If the finding needs a dramatic demonstration, do it against your lab copy of the application, and report that the same injection point exists on the target.
• Stop at proof. Once you have confirmed the injection and characterised what it can reach, you have the finding. Extracting the entire database is rarely necessary and multiplies the data-handling burden of lesson 4.

The finding is "this parameter is injectable and can reach the user table", demonstrated with the minimum that shows it — not a dump of the user table.

Exploiting your own weak application

The applied lab for objective 4.4, on the deliberately-weak application you installed in lesson 2.

1. Find an injectable parameter by observing how the application responds to input that would change a query.
2. Determine the type — in-band, blind boolean, or time-based — from what the application gives back.
3. Confirm read access with a harmless query, and capture the evidence.
4. Map what it can reach, characterising the impact without extracting everything.
5. Capture the traffic (lesson 13) so you can see the payloads on the wire.
6. Read the application and database logs — the defender's half.

Then fix it in the application (below) and confirm the injection stops working. Demonstrating the fix turns the exercise into a finding with a recommendation.

Parameterised queries, and why escaping is not the fix

The remediation, at the level of the cause, and the reason the obvious answer is wrong:

• Parameterised queries (prepared statements) are the fix. They send the query structure and the data separately, so the data can never become part of the structure. This closes the flaw by construction rather than by trying to clean the input.
• Escaping and input filtering are not the fix. They try to neutralise dangerous characters, and they fail in the ways such approaches always fail: missed cases, encoding tricks, contexts the filter did not anticipate. Escaping can reduce exposure, but a finding whose remediation is "we added some filtering" is a finding that will recur.
• Least privilege on the database account limits the blast radius — the application's account should not be able to read tables it never needs — but it is defence in depth, not the fix.
• Do not rely on the framework by assumption. Modern frameworks parameterise by default, but developers reintroduce the flaw the moment they build a query by string concatenation for a case the framework made awkward.

The message to the client: fix the cause (parameterise), and the class of finding closes; patch the symptom (escape this one field), and it returns wherever the next query is built by hand.

What to take into the exam

• SQL injection is untrusted input becoming part of a query's structure; entry points include stored values used later (second-order).
• In-band returns data, blind boolean infers it from behaviour differences, time-based infers it from induced delays — recognise which you have.
• Prove with read access and minimum extraction; never demonstrate with a destructive statement, and prove dramatic impact on a replica.
• Parameterised queries are the fix because they separate structure from data; escaping and filtering are not, and least privilege is defence in depth.