一时兴起，我最近决定将我创建的第一个合适的网站放到我用于开发的本地 Web 服务器上。我认为这将是一个很好的环境来注入一些 SQL，因为我知道存在缺陷，并且该站点仅用于我自己的个人开发。
无论如何，要直截了当地说，经过几次尝试后，我能得到的最远的结果就是让页面返回一个错误的语句。我试图进入我设置的特定测试帐户，（如果结果返回多个帐户，则会引发错误，所以我没想到选择 1=1 工作的每个用户名），但每次我得到一个就像我输入了一个正常的、不正确的密码一样。我查看了 PHP 代码，结果发现我在查询之前对密码进行了哈希处理，因此攻击在可能造成任何伤害之前就被哈希处理了。
作为一个整体的 web 安全新手，并且对 web 开发感兴趣，我想知道这种SQL 注入预防方法是否存在任何漏洞，因为我预计没有考虑过。澄清一下，这并不意味着“看，我发现了一些新东西”，因为在信息安全方面有比我自己更明亮的火花，我可能已经知道了这一点，但我想知道为什么这可能不适合作为安全机制。
因此，在将用户密码输入查询之前对其进行散列处理是一种防止 SQL 注入的巧合安全功能，但您不一定对所有用户输入都这样做。如果我正在按客户的姓名查找客户并且我有类似的查询
Select * from Customer Where Name like '%userInput%'
如果我将 userInput 设置为输入内容的哈希版本，即使 Name 也在数据库中进行了哈希处理，它也无法正常工作，它只适用于精确的搜索查询。因此，如果我有一个名为“Sue”的客户，并且我输入了“sue”的搜索字词，它就不会起作用。除非在我的搜索中有完全匹配，否则我也不知道客户的姓名，这是不切实际的。
您想要防止 SQL 注入的方法是不要像上面那样进行查询，您需要处理和参数化查询中的输入，去除 =s 和其他在输入上下文中没有意义的符号. 可以在此处找到防止 SQL 注入的良好指南。
基本上是的，如果您在将输入（以十六进制或 Base64 格式表示）传递给 SQL 之前对其进行哈希处理，则它不再是有效的 SQLi 攻击向量。如果您parseInt输入也是如此。那些根本不支持有用的 SQLi 所需的字符。（即跳出引用的字符串）
该技术在实践中仅具有有限的实用性。即它与一些著名的 SQL 特性不兼容，例如LIKE, <, >,
或索引相等搜索（=和<>使用索引）
作为旁注，我会指出密码哈希确实应该加盐。如果在您的示例中满足该标准，那么我认为您将不再在 SQLWHERE子句中包含哈希。
你正在做的（无意中）是所谓的“清理你的输入”的一部分，这是每个应用程序应该采取的步骤来减少缺陷（以及因此的漏洞）。
应用程序应首先确保输入不会超出应用程序接受数据的能力。这可能意味着对输入进行长度检查，或者以其他方式拒绝过大的数据。
接下来，如果可能，应用程序应该根据白名单检查输入，以确保没有不需要的输入可以进入逻辑。在某些情况下，这可能意味着确保输入仅包含有效的字母数字字符。但有时白名单对于该特定输入字段没有意义，但开发人员仍需要防止注入，因此他们合并了黑名单。黑名单验证输入不包含已知使注入成为可能的符号。黑名单的缺点是它们只能防止开发人员知道要阻止的内容。一个例子可能是一个停止引号以防止 SQL 注入的黑名单；但是当输入通过 URL 编码时，开发人员可能无法识别 %27 将成为引号。
在内部，应该防御性地编写应用程序以防止各种形式的注入。使用参数化 SQL（而不是使用连接构造 SQL 查询）有助于防止 SQL 注入。但是用户输入所在的许多其他地方可能容易受到不同类型的注入。如果攻击者输入诸如"..\..\..\..\..\..\windows\cmd.exe" XPath 查询之类的东西可以被注入以篡改未经授权的数据，则目录路径可能会受到影响。而 JavaScript 可以一路通过数据库来篡改受害者的浏览器。其他形式的防御包括不显示输出中的内部诊断错误消息，以及记录以帮助识别潜在的攻击者。
您的应用程序所做的是首先将输入传递给哈希例程，该例程具有在数据到达 SQL 步骤之前清理数据和限制其长度的双重效果。请注意，哈希例程的输入可能仍然容易受到缓冲区溢出的影响。当攻击者输入密码时会发生什么"aaaa[...repeated 1000 times...]aaaa_Evil_Injection_Here"？你的应用仍然需要处理这个问题。
像许多其他学习者一样，您混淆了存储和运输。而为了保护后者，你是在故意宠坏前者。
您必须了解 SQL 注入之所以不称为“数据库注入”是有原因的。您不必保护数据库和存储。您需要保护的只是传输 - SQL 查询。虽然您的存储应该能够按原样存储数据，否则它将毫无价值。如果您仍然需要该声明的任何证据，
因此，您可以看出，以任何方式改变存储数据的任何保护措施都是错误的。而且您的想法根本没有经过深思熟虑。