我意识到在构建包含用户输入的查询时,参数化SQL查询是清理用户输入的最佳方法,但是我想知道使用用户输入并转义任何单引号并将整个字符串都用单引号引起来是怎么回事。这是代码:
sSanitizedInput = "'" & Replace(sInput, "'", "''") & "'"
用户输入的任何单引号都将替换为双单引号,这消除了用户结束字符串的能力,因此他们可能键入的其他任何内容(例如分号,百分号等)都将成为字符串的一部分,并且实际上并未作为命令的一部分执行。
我们使用的是Microsoft SQL Server 2000,我相信单引号是唯一的字符串定界符,也是避免字符串定界符的唯一方法,因此无法执行用户键入的任何内容。
我看不到有什么方法可以发起针对此的SQL注入攻击,但是我意识到,如果这在我看来像防弹一样,那么其他人可能已经想到了,并且这将是普遍的做法。
此代码有什么问题?有没有办法使SQL注入攻击超越这种清理技术?利用此技术的样本用户输入将非常有帮助。
更新:
我仍然不知道有什么方法可以有效地对此代码发起SQL注入攻击。一些人建议反斜杠可以转义一个单引号,而让另一个反斜杠结束该字符串,以便该字符串的其余部分将作为SQL命令的一部分执行,并且我意识到该方法可以将SQL注入到一个MySQL数据库,但是在SQL Server 2000中,唯一可以逃脱单引号的方法是使用另一个单引号;反斜杠不会这样做。
并且,除非有一种方法可以停止转义单引号,否则将不会执行其余的用户输入,因为所有输入都将被视为一个连续的字符串。
我知道有更好的方法可以清除输入,但是我真的更感兴趣于了解为什么我上面提供的方法行不通。如果有人知道针对此清理方法发起SQL注入攻击的任何特定方式,我很乐意看到它。
首先,这只是不好的做法。输入验证始终是必需的,但也总是很困难。 更糟糕的是,黑名单验证始终是有问题的,最好是明确定义并严格定义您接受的值/格式。诚然,这并非总是可能的-但一定程度上必须始终做到这一点。 关于此主题的一些研究论文:
重点是,您所做的任何黑名单(以及过于宽松的白名单)都可以绕开。我论文的最后一个链接显示了甚至可以绕过引号转义的情况。
即使这些情况不适用于您,这仍然不是一个好主意。而且,除非您的应用很小,否则您将不得不进行维护,也许还要进行一定量的管理:如何确保始终无处不在正确地执行它?
正确的方法是: