Find the SQLi Probe: Reading Injection Payloads in Web Logs
The challenge
Your search endpoint is getting hammered with weird queries. Buried in normal searches, one IP is sending classic SQL injection payloads - things like ' OR '1'='1 and UNION SELECT - probing whether the search box talks straight to the database. Filter the suspicious requests, find the single attacker, and submit its IP.
What you'll learn
- Read the query string of a request, not just the IP and status
- Recognise classic SQL injection payloads in access logs
- Distinguish injection probes from ordinary searches
- Use error status codes as a secondary signal of a malformed-query attack
- Attribute a web attack to a single source IP
Skills tested
Prerequisites
- Basic understanding of SQL queries and the WHERE clause
- Familiarity with URL query parameters
- Awareness of HTTP status codes (200, 500, 504)
How it works
SQL injection happens when an application drops user input straight into a database query without separating code from data. An attacker probes for it by sending input that, if reflected into the SQL, changes the query's meaning. In an access log this is visible directly: the malicious intent is written into the URL query string for anyone reading the path column.
Here the attacker, 203.0.113.200, walks through the standard playbook against /search. A bare quote (q=laptop') tests for a syntax break and triggers a 500. Then a boolean bypass (' OR '1'='1), a column-count probe (UNION SELECT null,null), a data-theft attempt (UNION SELECT username,password FROM users), a schema dump (information_schema.tables), a time-based test (AND SLEEP(5) producing a 504), and a destructive payload (;DROP TABLE users). Every legitimate user is just typing product names, so the injection strings stand out the instant you read the query value instead of skimming IPs.
The errors are a useful but secondary tell. Filtering status:500 surfaces the rows where the malformed SQL broke the query, and they all belong to the same IP - but the successful 200 injection rows matter just as much, because a returned result means the bypass may have worked. The decisive evidence is the payload content plus its single source.
Common mistakes
- Only filtering on status. Many of the worst payloads return
200; filtering onlystatus:500misses the injections that succeeded. - Skimming IPs and ignoring the query string. The attack is in the
q=value - you have to read it. - Treating odd searches as user typos. A stray quote could be a typo;
UNION SELECT password FROM usersis not. - Submitting the path or payload instead of the IP. The question asks who - the single source sending the injections.
How to defend against it
SQL injection is prevented in code, not by hoping no one tries it. The same payloads you spotted in the log are exactly what a WAF and detection rules should catch.
- Use parameterized queries or prepared statements so user input is always data, never SQL code.
- Validate and constrain input (a search term does not need quotes, semicolons, or the word UNION).
- Alert on requests whose query strings contain injection markers like
UNION SELECT,OR 1=1, orinformation_schema, especially repeated from one source. - Run the database with least privilege so a successful injection cannot drop tables or read unrelated data.