I'm frequently getting these weird URLs.


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]

  • Well from my point of view looks that somebody is trying to do something like an injection but he dont know what he is doing, another theory could be an automatic bot or tool with a bug on the URL, could be possible for you dump the full request?
    – camp0
    Commented Nov 20, 2020 at 16:00
  • 1
    What triggers me in your question is "The webpage pass the id to the database and the database expect an integer so we are frequently getting errors." Does that mean that you do not sanitize your input before passing it to the database? Ever heard of Bobby Tables? Commented Nov 20, 2020 at 17:34
  • @LjmDullaart Yes, we sanitize every inputs with Parameterized Queries. cheatsheetseries.owasp.org/cheatsheets/…
    – Gudradain
    Commented Nov 20, 2020 at 18:03
  • Um, you're expecting an integer and you're frequently getting errors? That implies that you are vulnerable to SQL injection and you need to lock it down quick and evaluate the possibility that you may have had all your data stolen... Commented Nov 20, 2020 at 18:06
  • @Gudradain So it is your web application that generates these errors, not the database. Commented Nov 20, 2020 at 18:07

2 Answers 2


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.

enter image description here

  • 3
    It's definitely an attempt at SQL injection, but what about this payload makes you think it is specifically blind SQL injection? Commented Nov 20, 2020 at 18:07
  • The ' character is usually used to close a string in SQL injection, then you can inject your payload. The weird part is [0] that follows it. In SQL Server, square brackets are used to enclose object name like table or columns.
    – Gudradain
    Commented Nov 20, 2020 at 18:28
  • This is not a blind sql injection payload.
    – yeah_well
    Commented Nov 20, 2020 at 18:41

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .