如果没有上下文，我将假定作者指的是客户端应用程序中的输入字段。最容易使用的示例是 Web 应用程序中 HTML 页面中的表单，尽管我将要描述的内容对几乎任何类型的客户端应用程序都有效。

鉴于这种情况，答案是否定的，没有足够短的最大输入字段长度来保护您免受 SQL 注入，因为您无法控制最大输入字段长度。攻击者确实如此。当包含输入字段的表单位于客户端（例如在攻击者机器上的浏览器窗口中）时，它超出了信任边界，并且不受您的控制。它可以以攻击者想要或需要的任何方式被操纵，或者完全避免。请记住，对于 Web 应用程序，您得到的只是一个 HTTP 请求。您不知道它是如何创建的，也没有理由相信您要求浏览器执行的任何操作实际上都发生了，任何客户端安全控制都已实际运行，请求中的任何内容都符合您的预期或以任何方式安全.

所以不，输入字段长度不是有效的 SQL 注入预防机制，并且永远，永远不要信任未经验证就跨越安全边界的输入。

不，没有长度太短而无法利用（至少在某些情况下）。

长度过滤器不是针对 SQL 注入的有效保护措施，而准备好的语句确实是唯一适当的防御措施。

然而，长度过滤器是一种很好的深度防御措施（整数过滤器、字母过滤器等也是如此）。在许多情况下，例如有效输入永远不会超过 30 个字符，但有意义的利用需要更多。它应该（但可能不会）不言而喻，任何作为深度防御的过滤都必须在服务器端进行，因为任何客户端都可以简单地被绕过。

限制绕过

限制子句（例如AND/ OR）可以被两个字符绕过，这可能会造成真正的伤害，而不仅仅是失败的查询。最简单的示例是登录（其他示例是未经授权删除其他数据）：

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

注射：

id = 1#
password = wrong_password

有效载荷：2个字符

拒绝服务

DoS 攻击只需要很少的字符。在 MySQL 示例中，实际调用需要 7 + x 给定秒 + 能够调用函数和修复查询所需的任何时间。

例子：

SELECT * FROM users WHERE userid = [id]

注入（这是一个有效的注入，更长的形式是1 AND sleep(99)）：

sleep(99)

有效载荷：9 个字符

读取数据

如果显示数据，长度主要取决于表和列名。我将假设所有表的列数相等（它可能会发生，它可以节省字符）。

例子：

SELECT * FROM comments WHERE commentid = [id]

注射：

1 union select * from users

有效载荷：27 个字符。

编辑数据

未经授权的数据库修改也可以用很少的字符来实现。

例子：

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

注入（进入密码）：

',isadmin='1

有效载荷：12 个字符

绕过限制也可以（结果是所有密码现在都是空的*）：

'#

有效载荷：2个字符

_{* 为了简单起见，使用密码示例；应该对密码进行哈希处理，从而使示例无法进行。该示例仍然适用于所有类似情况（更新用户名、更新权限等）}

输入字段尽可能小，以减少黑客能够将 SQL 代码挤入字段而不被截断的可能性（这通常会导致 T-SQL 语法错误）。

恕我直言，这只是狗屎。使用输入字段的长度来防止 SQL 注入是很糟糕的建议：

• 防止 SQL 注入的唯一正确方法是使用准备好的语句。输入数据是查询的参数，永远不会用作 SQL 文本。
• 字段的大小必须在服务器端进行控制，因为您永远无法相信请求中的内容——它可能是伪造的——并且应该在用于业务层或数据库存储之前对数据进行清理。
• 使用最佳实践以外的任何东西的建议对于新手开发人员来说都是令人困惑的。

不。

考虑以下查询：

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

如果您可以为 注入单个非整数（例如，字母“a”）offset，则查询将导致语法错误，并且不会显示任何帖子，从而产生“非设计意图的结果”要求以造成损害。如果您可以注入一个空字符串，您将获得与零长度有效负载相同的效果。注入结束评论会浪费两个字符；）

攻击者可以在拒绝服务攻击中利用这一点（不同于通常与 DoS 相关的网络泛滥，但仍然是DoS）。根据被拒绝的服务，这可能是灾难性的。

正如其他答案所暗示的，字段长度与 SQL 注入影响无关。准备好的参数化语句是OWASP SQL 注入预防备忘单中提到的方法。