This attack could help by grabbing the first item from a list and return it, based on how it is being handled. This scanner could be targeting a certain implementation that returns a list, and most of the examples with SQLi state that the first item is an
sa for example.
some_var=' -> breaks the parser early on, no condition is gonna be applied, grab all objects.
 -> give me the first entry in that list you got, even if there are duplicates (if a condition is being applied).
- the scanner could now be checking for
admin in that response, and if yes, proceeds with the attack.
This is purely analytical. I have never seen a similar exploit or attack as this is appears to be targeted.
If you want to properly protect yourself from this, review specifically what's handling that input, then threat model every point it goes through.
Taking the example of SQLi, where this input is only going into an SQL parser, the below is a way of thinking:
- We are receiving this weird input, we handle it by rejecting it from the start because it's not an int.
- If this bypasses the application layer check in point 1, we are using prepared statements to let the database protect the data.
- If for any case the database is returning a bigger object than what is expected (3MB instead of 200KB), we block the response from going through.
- This requires granular knowledge of your application and your queries or it could break your application.
I'd advise for a similar approach when an exploit is not known and can't be traced to a specific vulnerability.