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.
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.