SQL 查询中的散列密码字段是否需要参数化调用/清理/转义字符？
为网站编写登录系统时，标准做法是使用参数化调用的某种组合、清理用户输入和/或转义特殊字符以防止 SQL 注入攻击。
然而，任何好的登录系统都应该在每个密码进入 SQL 查询之前对每个密码进行哈希处理（可能还加盐），因此仍然有必要担心密码中的 SQL 注入攻击吗？难道哈希本身不能完全消除 SQL 注入攻击的可能性吗？
编辑：我也很好奇当前的网站是否确实清理了密码字段，或者通常不担心。
When writing a login system for a website, it is standard to use some combination of parameterized calls, sanitizing the user input, and/or escaping special characters to prevent SQL injection attacks.
Any good login system, however, should also hash (and possibly salt) every password before it goes into an SQL query, so is it still necessary to worry about SQL injection attacks in passwords? Doesn't a hash completely eliminate any possibility of an SQL injection attack on its own?
EDIT: I'd also be curious if current websites do clean their password fields or if it is generally not worred about.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
最好始终假设对数据库的任何调用都可以携带查询注入。
就我个人而言，我非常怀疑使用 SHA1 哈希值的调用是否能够注入代码，但是您有什么理由不对其进行清理吗？
处理注射问题时，偏执是最好的方法；）
It is always best to assume any call to a database could carry query injection.
Personally, I highly doubt that a call with an SHA1 hash would ever be able to inject code, but is there any reason you wouldn't sanitize it anyways?
Paranoia is the best way to go when dealing with injection ;)
可能不会。
但是散列密码不是只是数据库调用的另一个参数吗？您的意思是您要对除使用字符串连接的密码之外的所有其他输入混合'n'匹配参数化吗？
Probably not.
But isn't a hashed password is just another parameter to a database call? Do you mean you'd mix'n'match parameterisation for all other input except passwords where you use string concatenation?
取决于您正在执行什么类型的查询。
如果您的查询如下所示，
那么在 md5 函数中不转义指定的密码将导致 sql 注入漏洞。
一直使用参数化查询，除非有一些令人难以置信的充分理由不能使用（提示：IN (...) 不能很好地配合它们）。
参数化查询比转义更容易正确执行，而且更安全。
Depends what kind of query you're doing.
If your query looks like
Then not escaping the specified password inside the md5 function will lead to a sql injection vulnerability.
Just use parameterised queries all the time unless there is some incredibly good reason you can't (Hint: IN (...) doesn't play well with them).
Parameterised queries are easier to do right than escaping, and more secure.