散列能阻止SQL注入吗？

Question

出于一时兴起，我最近决定将我创建的第一个合适的网站放到我用于开发的本地web服务器上。我认为这将是一个很好的环境，抛出一些SQL的注入，因为我知道有缺陷，该网站实际上只是为了我自己的个人发展。

无论如何，要说到重点，经过几次尝试，我能得到的最远结果是让页面返回语句中的一个错误。我试图进入我设置的一个特定的测试帐户(如果结果返回多个帐户，抛出错误，所以我不希望选择1=1工作的每个用户名)，但是每次我得到一个响应，就好像输入了一个正常的、不正确的密码一样。我看了一下PHP代码，结果发现我在查询之前对密码进行了散列，所以攻击在可能造成任何伤害之前就被散列了。

对于整个web安全来说，我都是新手，并且对web开发很感兴趣，我想知道这种SQL注入预防方法是否存在漏洞，因为我希望还没有想清楚。澄清一下，这并不意味着“我发现了一些新东西”，因为在信息安全方面有很多比我自己更亮的火花，他们可能已经弄清楚了，但我想知道为什么这个可能不适合作为安全机制。

Answer 1

因此，在将用户密码输入查询之前对其进行散列是一种巧合的安全特性，以防止SQL注入，但您不一定能够在所有用户输入中做到这一点。如果我查到一个顾客的名字，我有一个查询，比如

Select * from Customer Where Name like '%userInput%'

如果我将userInput设置为输入内容的散列版本，即使在数据库中也对名称进行了散列，它也不能正常工作，它只适用于精确的搜索查询。因此，如果我有一个名叫"sue“的客户，我输入了搜索"Sue”的内容，那就行不通了。我也不知道客户的名字，除非在我的搜索中有一个确切的匹配，这是不切实际的。

防止SQL注入的方法是不像上面那样进行查询，您需要处理输入并将其参数化到查询中，去掉诸如=s等在输入上下文中没有意义的符号。这里为防止SQL注入提供了一个很好的指南。

Answer 2

基本上是的，如果您在将哈希输入(以十六进制或Base64格式表示)传递给SQL之前，它将不再是有效的SQLi攻击向量。如果输入是parseInt的话，情况也是一样。它们根本不支持有用的SQLi所需的字符。(即中断引用的字符串)

这一技术在实践中的应用有限。也就是说，它将不兼容一些著名的SQL特性，例如LIKE、<、>，

或索引相等搜索(使用索引的=和<> )

作为附带说明，我要指出密码散列真该加盐。如果在您的示例中满足了这个条件，那么我认为您将不再在SQL WHERE子句中包含一个散列。

Answer 3

您所做的(无意中)是所谓的“清理您的输入”的一部分，每个应用程序都应该采取这些步骤来减少缺陷(因此也是漏洞)。

应用程序应该首先确保输入不能溢出应用程序接受数据的能力。这可能意味着长度-检查输入，或以其他方式拒绝超大的数据。

接下来，应用程序应该检查输入与白名单，如果可能的话，以确保没有不必要的输入可以进入逻辑。在某些情况下，这可能意味着确保输入只包含有效的字母数字字符。但是有时白名单对这个特定的输入字段没有意义，但是开发人员仍然需要防止注入，所以他们合并了一个黑名单。黑名单验证输入不包含已知的使注入成为可能的符号。黑名单的缺点是，它们只对开发者知道要阻止的东西进行保护。一个例子可能是一个黑名单，它停止一个引号以防止SQL注入；但是开发人员可能不知道当输入通过经过URL编码的URL时，一个%27将成为一个引号。

在内部，应用程序应该是防御性的，以防止各种形式的注射。使用参数化SQL (而不是使用串联构造SQL查询)有助于防止SQL注入。但是，许多其他地方的用户输入土地可能容易受到不同类型的注入。如果攻击者输入类似"..\..\..\..\..\..\windows\cmd.exe" XPath查询的内容以篡改未经授权的数据，目录路径可能会受到影响。JavaScript可以通过数据库对受害者的浏览器进行篡改。其他防御形式包括在输出中不显示内部诊断错误消息，以及记录以帮助识别潜在攻击者。

您的应用程序所做的是首先将输入传递给一个散列例程，它具有净化数据和限制数据长度的双重效果，然后才到达SQL步骤。请注意，哈希例程的输入可能仍然容易受到缓冲区溢出的攻击。当攻击者输入"aaaa[...repeated 1000 times...]aaaa_Evil_Injection_Here"密码时会发生什么？你的应用程序还需要处理这个问题。