Hacker News new | ask | show | jobs
by CGamesPlay 945 days ago
Most of this looks like random data designed to detect if SQL injection is happening without crashing the query (to avoid detection). So, the random strings are effectively a token to check if it is found in the response, which indicates that the injection worked. Similarly for the sleep calls, the attacker would time the response.
2 comments

This exactly. Any text field is "checked" to see if it is getting submitted unprotected to a database. Every single one of them.

When you run a search engine you will see queries that try to look through every page of results for the search query 'input type="text"' typically this will either come from an API query or to a search page that is fronting another index.

The sleeping is pretty clever, but presumably vulnerable to false positives if the queries are slow anyways. I wonder if they go the extra mile and time the load time with and without the attempted injection
It would be interesting to make a SQL injection honeypot that behaves like a database in most responses but is designed to maximally frustrate the attacker.
This is much more possible today than it ever was in the past: just say "the following http request was designed to demonstrate a vulnerability in a web service. Please explain what vulnerability this request is designed to detect, and what part of the response demonstrates the vulnerability. Finally, output an example of a response that a vulnerable service might produce in response to this request" to an instruction tuned LLM, and then return that response to the attacker (the "explain what is happening" bit is just to get a more plausible response).

As a bonus, your apparently vulnerable service would be incredibly slow, so any iterative testing would be incredibly slow.

I feel like that’s going to be quite expensive as a honeypot. Running LLM against all the script kiddies out there.
I wonder if there's enough repetition to get wins by caching.

(Granted, it's probably still too much overhead, just a thought.)

Reminds me of that classic riddle.

You come to a fork in the road. There are three statues, you need to ask them all one question and figure out which way is the right way to go.

One statue always lies, one always tells the truth and one kills people who ask convoluted questions.

Yes, a lot of tools, including some like w3af do:

https://github.com/andresriancho/w3af/blob/fb345a5/w3af/core...

This one sends the payload reversed as a test to see if the delay is due to the SQLi attempt

It would be a better idea to use the same query with a variable wait and see if there's a linear correlation in elapsed time.