Hacker News new | ask | show | jobs
by sour-taste 945 days ago
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
3 comments

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.