字符限制是否是防止代码注入的安全机制/是否比输入清除更好？

Question

许多服务仍然限制密码中允许的特殊字符，类似于防止注入攻击的论点。现在，有许多很好的理由反对这一点，例如避免不必要的障碍，字符选择增加所选密码的安全性等。在此，我只对以下论点感兴趣：

任何检查密码是否符合字符限制的系统本身都可能受到注入攻击。如果您不太了解您的系统以防止代码注入，这是一个潜在的安全漏洞。因此，您不能依靠限制特殊字符来完全防止注入攻击。(请充分注意:显然，在防止特殊字符过滤器后注入攻击。)

比较字符限制和输入散列的这个论点的一个变体是：

无论您对用户输入应用清理或字符限制，这都应该是您首先要做的事情。这两种机制都可能受制于代码注入本身，但如果您不太了解您的系统，使这些系统不受代码注入的影响，您也不能说哪个更好。因此，没有理由选择字符限制而不是消毒。(因为这是关于机制中的漏洞，而不是其结果的不完善，因此应用这两种方法都不会带来任何好处。)

这些论点有效吗?还是我遗漏了什么？

Answer 1

字符限制是防止代码注入的安全机制吗？

如果字符限制是足够安全的防止代码注入的保护，则取决于具体的实现以及它到底要防止什么。如果仍然允许任何适合注入的字符，那么限制显然是不够的。因此，哪些字符需要不允许，这显然取决于使用输入的上下文。

如果做得好，它就会足够安全，如果做得不好，就会不安全。然而，应用程序是复杂的，并且是不断发展的，因此，在对应用程序进行更改之后，曾经是适当限制的内容可能已经不足够了。因此，字符限制不应被看作是在实现后最终完成的，但是如果应用程序发生了变化，对输入的期望以及如何处理输入的期望应该在整个应用程序中清楚地传达，则应该重新评估它。

是性格限制..。比输入消毒好吗？

投入卫生有其自身的问题。就像字符限制一样，它依赖于关于输入的外观和执行这些假设的特定假设。这些假设基于应用程序内部的输入处理方式。与字符限制一样，假设从一开始就可能是错误的，如果应用程序发生更改，则可能会在稍后出现错误。错误的清理甚至可能会以一种引入以前不存在的安全问题的方式更改输入。

由于这是关于机制中的漏洞，而不是其结果的不完善，因此应用这两种方法都不会带来任何好处。

最好将输入验证(比如字符限制)和输入清除结合起来，特别是因为在实践中，不能依赖这些机制的完善。但是，应该按照正确的顺序进行，即首先对输入进行消毒，然后直接验证输入，以便防止出现错误的卫生问题。在使用之前根据代码各个部分中特定上下文的期望验证输入也是一个好主意，即不要太依赖于正确完成的第一次清理和验证。

此外，我们应该解决注入攻击的主要问题:数据和代码之间缺少分离。这种分离可以在HTML中强制执行，方法是使用拒绝内联脚本，也可以在SQL中使用参数化查询，而不是通过SQL语句与用户输入的字符串连接来构建查询。