What is this attack? id=1'[0]

Question

I'm frequently getting these weird URLs.

https://mywebsite.com/mymage.php?id=1'[0]

The weird part is '[0].

The webpage pass the id to the database and the database expect an integer so we are frequently getting errors.

Is it an attack? If yes, what is it targeting?

Note: It's similar to this question that doesn't have any answer. What type of attack is this? '[0]

Answer 1

It's a way of an attack, called "Blind SQL Injection". Official Documentation from OWASP: https://owasp.org/www-community/attacks/Blind_SQL_Injection

Blind SQL (Structured Query Language) injection is a type of SQL Injection attack that asks the database true or false questions and determines the answer based on the applications response. This attack is often used when the web application is configured to show generic error messages, but has not mitigated the code that is vulnerable to SQL injection.

Answer 2

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 admin user, sa for example.

• some_var=' -> breaks the parser early on, no condition is gonna be applied, grab all objects.
• [0] -> 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:

1. We are receiving this weird input, we handle it by rejecting it from the start because it's not an int.
2. If this bypasses the application layer check in point 1, we are using prepared statements to let the database protect the data.
3. 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.
4. etc.

I'd advise for a similar approach when an exploit is not known and can't be traced to a specific vulnerability.