Overview
Hunting SQL injection starts with understanding how a parameter influences query behavior — recognizing where input reaches a database query. This lesson covers query behavior in SQLi hunting.
Learning objectives
- Explain how input influences query behavior.
- Recognize signs a parameter reaches a query.
- Frame safe SQLi hunting.
Core concept
SQL injection (from the web-security SQLi module) arises when untrusted input is incorporated into a database query such that it can alter the query's structure. Hunting begins by identifying parameters whose input appears to influence a database query — for example, parameters used for searching, filtering, sorting, or looking up records by ID. Recognizing query behavior means observing how the application's responses change with input in ways suggesting a database query is involved (different results for different values, behavior consistent with a lookup/filter). Testing is done safely in-scope, using minimal, non-destructive probes, per program rules.
How it works
The researcher identifies candidate parameters that likely reach a query (search terms, filters, IDs, sort fields) from the endpoint/parameter discovery. They observe query behavior: does changing the parameter change results in a way consistent with a database lookup/filter? This suggests the input reaches a query and is worth safely testing for injection. The key concept from the web-security module applies: the vulnerability exists if input can affect the query's structure (unsafe concatenation) rather than being confined to data (parameterized). Hunting uses safe, minimal probes to detect whether input influences the query unexpectedly — never destructive or data-exfiltrating actions.
Practical example
Hunting an in-scope application, the researcher notes a search parameter and an id parameter that clearly influence which records are returned — behavior consistent with database queries. These become SQLi candidates. The researcher plans safe, minimal tests to observe whether the parameters' input can affect query behavior in ways indicating injection (e.g. characteristic error or logic changes) — without destructive actions or data exfiltration, per program rules. Recognizing which parameters reach queries focused the hunt on genuine SQLi candidates.
Cybersecurity relevance
Recognizing query behavior focuses SQLi hunting on the parameters that actually reach database queries — the only ones where SQLi can exist. It builds on the web-security SQLi concept (input altering query structure via unsafe concatenation) and on parameter discovery. SQLi remains a high-impact vulnerability class (potential data exposure/modification), so identifying candidates and testing them safely (minimal, non-destructive, in-scope) is valuable in bug bounty. For defenders, the fix is parameterization. Understanding query behavior is the first step to systematic, safe SQLi hunting.
Common mistakes
- Testing parameters that don't reach a query, wasting effort.
- Using destructive or data-exfiltrating tests instead of minimal, safe probes.
- Ignoring the code/data concept — SQLi exists only where input can affect query structure.
Key takeaways
- SQL injection arises when input can alter a query's structure; hunting starts by identifying parameters whose input influences a database query (search, filter, id, sort).
- Recognize query behavior (results changing with input consistent with a lookup/filter) to focus on genuine SQLi candidates.
- Test safely (minimal, non-destructive, in-scope) per program rules; SQLi is high-impact, and the fix is parameterization (web-security SQLi module).
Check your understanding
- How do you recognize that a parameter likely reaches a database query?
- Why focus SQLi hunting only on parameters that influence query behavior?