Is there a field length that is too short to allow harmful SQL injection?

Question

I was reading about SQL injection and saw this, which got me thinking:

input fields as small as possible to reduce the likelihood of a hacker being able to squeeze SQL code into the field without it being truncated (which usually leads to a T-SQL syntax error).

Source: Microsoft SQL Server 2008 R2 Unleashed

What is the is the shortest field size where SQL injection can cause harm?

With harm being database modification or returning results not intended by design. Including an end comment marker (--) in a two character field would not cause harm, it would just cause a failed query. The potential hacker, might learn the field is susceptible to injection, but they are unable to leverage it.

Answer 1

Without context, I'm going to presume that the author is referring to input fields in a client application. The easiest example to use would be a form in an HTML page in a web application, though what I'm about to describe is effective for virtually any type of client application.

Given this context, the answer is no, there is no maximum input field length short enough to protect you from SQL injection, because you don't control the maximum input field length. The attacker does. When the form containing the input field lives on the client (like in a browser window on the attacker's machine) it is outside of the trust boundary, and out of your control. It can be manipulated in any way the attacker wants or needs, or avoided completely. Remember, for a web app, all you get is an HTTP request. You have no idea how it was created, and no reason to believe that anything you asked the browser to do actually happened, that any client-side security controls were actually run, that anything in the request is as you intended or in any way safe.

So no, input field length is not a valid SQL injection prevention mechanism, and never, never trust input that crosses a security boundary without validating it.

Answer 2

No, there is no length that is too short to be exploitable (at least in some situations).

A length-filter is not a valid protection against SQL injection, and prepared statements really are the only proper defense.

A length filter is however a good measure as defense in depth (as are integer filters, alphanum filters, etc). There are many situations where e.g. valid input could never be above say 30 characters, but where meaningful exploitation requires more. It should (but probably doesn't) go without saying that any filtering as defense in depth must be taking place server-side as anything client-side can simply be bypassed.

Restriction Bypass

Restriction clauses (e.g. AND/OR) can be bypassed by two characters, which can cause real harm, not just a failed query. The most simple example is a login (other examples would be the unauthorized deletion of additional data):

SELECT * FROM users WHERE userid = [id] AND password = [password]

Injection:

id = 1#
password = wrong_password

Payload: 2 chars

DoS

DoS attacks require very few characters. In a MySQL example, it takes 7 for the actual call + x for the given seconds + whatever is needed to be able to call the function and fix the query.

Example:

SELECT * FROM users WHERE userid = [id]

Injection (this is a valid injection, a longer form would be 1 AND sleep(99)):

sleep(99)

Payload: 9 chars

Reading Data

If the data is displayed, the length depends mainly on the table and column name. I'll assume equal column count for all tables (it may happen, and it saves characters).

Example:

SELECT * FROM comments WHERE commentid = [id]

Injection:

1 union select * from users

Payload: 27 chars.

Editing Data

Unauthorized database modifications can also be achieved with few characters.

Example:

UPDATE users SET password = '[password]' WHERE id = [id]

Injection (into password):

',isadmin='1

Payload: 12 chars

A restriction bypass would also work (the result is that all passwords are now empty*):

'#

Payload: 2 chars

_{* The password example is used for simplicity; passwords should be hashed making the example impossible. The example still applies in all similar situations (updating a username, updating permissions, and so on)}

Answer 3

input fields as small as possible to reduce the likelihood of a hacker being able to squeeze SQL code into the field without it being truncated (which usually leads to a T-SQL syntax error).

IMHO, this is just shit. Using the length of input fields to protect from SQL injection is terrible advice:

• The only correct way to protect from SQL injection is the use of a prepared statement. The input data is a parameter of the query and will never be used as SQL text.
• The size of a field must be controlled server side because you can never trust what comes in a request - it might be a forged one - and should be used to sanitize data before usage in the business layer or database storage.
• Advice to use anything other than the best practices is confusing for novice developers.

Answer 4

No.

Consider the query:

select * from tweets
WHERE RowNum >= [offset]
AND RowNum < [offset] + [limit]

If you could inject a single non-integer (for example, the letter "a") for offset, the query would result in a syntax error and no posts would show up yielding your "results not intended by design" requirement for causing damage. If you can inject an empty string you get the same effect with a zero length payload. Injecting an end comment would be a waste of two characters ;)

An attacker can leverage this in a denial of service attack (differently from a network flooding generally associated with DoS, yet still a DoS). Depending on the service being denied, this could be catastrophic.

As other answers suggest field length has no bearing on the SQL injection impact. Prepared, parameterized statements are the way to go as mentioned in the OWASP SQL Injection Prevention Cheat Sheet.

Answer 5

No.

Simple example of a one-character SQL injection:

`

It would throw an error which would be an example of "returning results not intended by design". Many times errors can be used to gain information that will help later in an exploit.

Answer 6

Yes.

The maximum length is zero. The only way to make untrusted input safe via maximum length, with no other validation or checks, is to completely disregard the input starting at index 0.

There are many other (better) answers here, but this one serves to answer the theoretical question of how to stay safe when field length is the only tool at your disposal.

Answer 7

The length of a field won't have anything to do with SQL injection, because such an attack works by simply commenting out previous code and starting the attack code, so the length of any field won't effect this strategy.

Answer 8

There is a lot of theory here but no actual examples. When I found a real-world sql injection vulnerability (now patched) I tried using input fields that were around 30 characters long. This was very frustrating as it took me a while to figure out that everything after 30 characters was dropped, and 30 characters did not leave me room for much.

(a lot of sql injection examples have simple sql "like select * from table where id = @id", real world sql will usually be much more complicated)

You can get fancy with your input, and a sql expert could probably use some tricks to reduce the payload count. But no matter how tricky you are if you want to select some long table name you're going to need a lot of characters for that.

Anyways, when I switched to using a input field with over 1k characters I found that plenty for sql injection.

That being said, like many commenters above me said, The best defense against sql injection is prepared statements