SQL injection in practice, step by step in a legal lab

Theory becomes real when you can watch it happen. In this lesson you will follow the reasoning of a tester on an SQL injection test, in a deliberately vulnerable training application. Pay attention to the method: observe, form a hypothesis, test, confirm, record, stop.

The training scenario

We will use the “SQL Injection” page of DVWA at the low level as our example. It offers a field where you enter a user ID and shows the matching first name and surname. This is typical of the input pattern we saw in the previous lesson. If you use Juice Shop or the Academy, the same method applies to the search field or to the lab’s documented injection point.

Start Burp, set your scope to your lab, and make sure intercept is off, so that all requests are recorded in the history.

Step 1: observe normal behaviour

Before breaking anything, understand what normal looks like. Enter a valid identifier such as 1 and submit. Note in your notebook:

• The request: method, path, parameter name (for instance id).
• The response: what is displayed, the HTTP status and approximate size.

Then try another valid value, such as 2, and one that does not exist, such as 9999. Now you know the three “reference” behaviours: a result, a different result and an empty result. Without these references you cannot interpret anything later.

Step 2: form a hypothesis

Ask yourself: where does this value go? The page looks up a record by identifier, so very probably into a query like SELECT first_name, last_name FROM users WHERE user_id = '…'. If it is inserted in a quoted string without protection, a quote character in the input could unbalance the query.

A hypothesis is a sentence you can verify: “The id parameter is concatenated into an SQL query, inside quotes.”

Step 3: the detection test

The simplest, least harmful test is to send a single apostrophe character as the value. Send the request from Repeater so you can see the full response. There are three possible outcomes:

Observation	Interpretation
A database error message mentioning an SQL syntax problem	Strong sign that the input reaches the query and breaks its structure
A generic server error (500) or a blank page	Possible; the application may hide details. Needs another test
The page behaves exactly as for any invalid value	Inconclusive: the input may be validated, or the injection may be blind

On the low level of DVWA, you will get the first outcome. That error is gold for a tester: it tells you the database engine and often shows part of the query. Record the error message in the notebook, as evidence.

Observation: with a single apostrophe as the id,
the page displays a database syntax error that quotes
the end of the query. With id=1 it returns one record.
Hypothesis supported.

Step 4: confirm with a controlled logical test

An error alone shows the structure was disturbed. To confirm that input is interpreted as part of the query, testers use pairs of inputs that modify the logic of the query in opposite ways: one that leaves the condition true, the other one making it false, while the query remains syntactically valid. If the application’s answer changes in line with that logic, the input is demonstrably being interpreted by the database.

The PortSwigger Web Security Academy and the DVWA help pages explain the exact syntax for these paired tests, for their engines and contexts. We deliberately do not reproduce a ready-to-paste string here: the point is to understand the reasoning, and to follow the lab’s guided material for the details. In your notebook, write the result as a pair:

Test A (condition kept true):   same result as the original value
Test B (condition made false):  empty result
Conclusion: the application evaluates my input as SQL

This is the confirmation. For a professional report, this is already enough to classify the finding as a confirmed SQL injection.

Step 5: understand the context, then stop

In a training lab, the guided exercises continue by showing how the visible output can be used to learn about the database structure. This is valuable for understanding the impact in a safe setting, and you are encouraged to work through the lab’s official walkthrough once you have confirmed the flaw yourself.

In a real, authorised engagement, however, you stop sooner. You document the minimum evidence, you tell the client straight away if the flaw gives access to sensitive data (many rules of engagement require immediate notice for critical findings), and you let their team fix it. You do not browse customer tables to see how far you can go.

What about automated tools?

Open source tools exist that automate SQL injection testing. They are widely used in the profession, and you may meet them in training. Treat them as accelerators, not as a replacement for understanding: they are noisy, can modify or overload data if misconfigured, and require explicit permission to be used on real targets. Learn the manual reasoning first.

Blind injection: the same reasoning, with less feedback

If the application never shows errors or data, the same pairs of true and false tests can still work: the visible difference may be subtle, such as the presence or absence of a “Welcome back” message, or a response that takes noticeably longer. The method is identical: build references, vary one thing at a time, compare. The Academy has a dedicated progression for these cases, with labs that guide you from the principle to realistic situations.

Raising the difficulty

Switch DVWA to the medium level and repeat steps 1 to 4. You will see that the input field has become a drop-down list, and that the application escapes some characters. Use your proxy to see that the request still carries a value you can change. This demonstrates a core lesson: client-side restrictions are not security controls. Then read the impossible level’s source code, which uses a parameterised query, and observe that the same tests no longer disturb the query at all.

Writing the finding

As soon as you confirm the flaw, record it in a structured way. This is the beginning of your final report in chapter 7.

Finding: SQL injection in the "User ID" parameter
Location: /vulnerabilities/sqli/ (training application, low level)
Parameter: id (GET)
Evidence: a single apostrophe triggers a database syntax error;
          a paired true/false test changes the result as expected
Impact: potential read and modification of database content
Recommendation: use parameterised queries; least-privilege database account

Your turn: run the method yourself

Run steps 1 to 4 on your chosen lab: the DVWA “SQL Injection” page at low level, the equivalent Academy lab, or a Juice Shop search feature. Complete your notebook with the three reference behaviours, the detection test, the paired confirmation, and a finding sheet in the format above.

See a solution

Your notebook should contain, in this order: (1) three references (valid id, other valid id, non-existing id) with status and size; (2) the hypothesis sentence; (3) the result of the single-apostrophe test, with the error message copied; (4) the two logical tests and their results, each described in words; (5) the finding sheet.

If you do not get an error message, do not conclude that the application is safe. Try the same method on another parameter, or look at the Academy’s blind injection material, and note “inconclusive” rather than “not vulnerable” in your notebook. Honest notes are a professional habit.

SQL is not the only language an application can be tricked into running. Next, a tour of the other injections.