单引号过滤是胡说八道吗？

#1 楼

您应该将输入验证实现为纵深防御方法。因此，输入验证不应成为防范SQL注入的主要手段，而应该是准备好的语句。作为额外的防御措施，应该限制允许的输入。

这永远都不应限制功能。如果有合法的用例在输入中包含撇号，则应允许使用。因此，您应该在名称字段，描述，密码中使用单引号，但在数字字段，用户名字段，车牌字段中不允许使用单引号。

在所有输入中均禁止使用单引号是很疯狂的。这破坏了应用程序的功能，甚至不是针对SQL注入的正确解决方案。

请考虑您误解了渗透测试公司的可能性。如果这是他们的严重建议，那么这对渗透测试公司会造成严重影响，我建议您寻找渗透测试合作伙伴，以帮助适当保护您的软件，而不是使其无法使用。

#2 楼

在注入攻击的上下文中，这显然是错误的-您的数据库层是否正确处理了字符串，或者没有正确处理。由于撇号在名称和自由文本中都是有效的，所以完全禁止使用撇号会破坏应用程序，而选择性地阻止使用它们不会解决注入问题。

但是严格的输入验证在一般原则上是好的做法，并且在撇号不是合法值的情况下，过度放任是没有意义的。您给出EUR 1'000'000的示例，它是一种特定于语言环境的格式（仅瑞士，AFAIK）-但是，将该格式作为值的一部分是没有意义的。如果用户输入1,500，您的应用程序应该按原样存储吗？您是否必须在每次处理时都决定将其解释为1.5还是1500？在客户端处理特定于区域设置的表示，并在内部以规范形式处理数字值会更有意义。

因此，此处的答案取决于审计是否在抱怨特定的设置有意义的字段，或建议全面禁止使用撇号。如果是前者，那是合理的观点。如果是后者，则它们是愚蠢的，并且可能会盲目地遵循清单。

#3 楼

步骤1）参数化SQL。

步骤2）确保使用SQL DB连接库设置参数值，而不仅仅是设置它们的内联。这是针对SQL注入的实际防御措施。

步骤3）不要在SQL中进行查询构建。

步骤4）添加一个配置开关，将错误一直传播到用户。在测试过程中将其打开。

步骤5）告诉渗透测试人员找到一种生成带有单引号奇数或关闭的SQL错误的方法。

#4 楼

准备好的语句（带参数的查询）非常有用，只需确保正确实现即可。我已经看到了“准备好的语句”实现，它们都一样脆弱。对于实现细节的讨论，我建议堆栈溢出。

纵深防御也没有错（在这种情况下为输入验证），但是做得很好...拒绝所有单引号可能不是最佳实践:)

#5 楼

我不是安全人员。我是一个必须维护安全代码的程序员。这就是我所谓的“脆性”练习。入口点分散在整个典型项目中。找到并清理所有这些问题仅是解决单个问题的大量工作，需要进行大量的精心维护和麻烦以确保其在代码更改时仍然有效，并且充满了使之无效的假设。

而是使用更易于维护，分层，关联和解决大量问题的实践。这样一来，您就不需要昂贵的，过于宽泛的过滤。

如果您不知道输入将如何使用，就无法保证输入的安全。

假设您通过从所有输入中去除所有单引号来“保护”您的系统。太好了，您可以抵御一种类型的SQL注入攻击。如果在...中使用该输入...


允许双引号的MySQL查询
文件系统操作
Shell命令
网络查询
>方法名称
类名称
eval

每个方法都有不同的特殊字符，转义序列，引用规则和安全性惯例。您可能无法预测输入内容将如何使用。试图删除所有特殊字符是疯狂的，只能“解决”一类攻击。

如果用户是允许输入页数限制。该限制在参数化查询中应有尽有；没有SQL注入，是的！用户输入9999999999，现在您就容易受到DOS攻击。

必须在执行可能不安全的操作时应用适当的安全措施。这考虑到了操作独特的许多因素。清理输入字符只是一个。

，只要您这样做，还可以参数化查询。这样一来，就不再需要做所有的工作和覆盖剥皮引号的损坏。

很难过滤所有输入。

在给定项目中有很多很多方法来获取和传递输入：


形式输入
urls
文件名
文件内容<数据库查询
网络读取
环境变量

这些通常是非常自由的形式，可以使用许多不同的库。我不知道有任何静态分析工具可以验证所有潜在的易受攻击的输入是否已通过过滤。某些语言具有taint系统，但很难有效使用。即使您过滤了所有输入，如果没有静态分析工具，未过滤的输入也会随着开发的进行而泄漏回来。要维护不完整，昂贵的结果会付出很多努力，这会妨碍功能。

相反，项目中通常只有一种执行SQL的方法。存在静态和运行时工具来自动检测潜在的SQL注入。您甚至可以完全禁止使用字符串，并要求所有查询均为SQL查询对象。这些良好的做法易于维护，并且越来越多地嵌入到工具和SQL库中。

“防火墙”导致宽松的安全性。

类似于某些办公网络的非常不安全的做法因为“我们有防火墙”，团队就有可能因为“输入安全”而懒于保护代码。输入的内容绝对是不安全的。

机会成本

有人可能会说“为什么不能同时使用？”您只有很多时间来从事一个项目。低效率，高维护实践是很麻烦的。实施和维护它会花费您有限的时间来避免更高效，更易于维护的实践。在最坏的情况下，您将花费大量时间使用输入打怪，以及过分过滤导致的后续问题，以致您将永远没有时间采取适当的安全措施。

简而言之，输入过滤昂贵，泄漏，难以维护，无法解决问题，并且可能使情况变得更糟。

#6 楼

就像您自己说的那样，如果您使用的是参数化查询，那么单引号就不成问题。在这种情况下，您可以拒绝他们的建议。如果这样做，请突出显示您正在使用参数化查询的事实，这也有助于提高可用性（使用先前的示例）。

#7 楼

如果您100％确保始终在所有地方都防止SQL注入，这确实是胡说八道。

但是，SQL注入是最常见的安全风险之一，即使您确定自己已经如果正确编写了应用程序以使用参数，那么草率的DBA可能会执行查询，该查询可能会受到二阶SQL注入的威胁。它甚至可能不会存储在任何地方，而可能只是复制表的查询。

二阶攻击更难以执行，但更难以防范。防范二阶攻击意味着需要检查在数据库上运行的具有写权限的每个动态SQL语句是否存在SQL注入的风险，不仅是处理来自不受信任来源的输入的SQL语句。

不允许到处都有引号是对二阶攻击的草率保护，但确实使它们不太可能。在理想的世界中，这不是必须的，但是不幸的是我们并不生活在一个世界中。

如果许多用户对数据库具有任何形式的写访问权限，并且能够编写自己的SQL语句，则这可能是明智的安全措施。如果您的应用程序是访问数据库的唯一方法，并且只有非常有知识的用户可以执行具有写访问权的自己的查询，则通常没有必要。

#8 楼

虽然我不知道您的应用程序的细节，但是我会遵循您的说法。

有些字段不需要包含某些字符。在这些字段中，您可以使用输入验证来过滤单引号（和双引号以及其他内容）。

如果转义不能正确运行，输入验证可能是一种缓解策略，但是可以（正确地）准备好的语句应该是减轻SQL注入风险的首选方法。

#9 楼

如果这是真正的渗透测试的结果，那么他们应该能够为您提供一个值得证明的价值，以证明这是一个可利用的问题。如果他们不能，那么我建议您进行适当的渗透测试，以证明它们可以被利用。

但是，如果这是通用漏洞扫描的结果，那么我希望这样的模糊通用响应，那只是标记能够插入单引号。在这种情况下，如果您对没有问题感到满意，那么您可以很高兴地忽略该结果。

#10 楼

从前Web开发人员到现在的笔测试人员，我都不希望限制用户的输入，但这可能是一个主要问题。我知道我自己就是使用这种技术来破坏Web应用程序和数据库的。

我的看法是检查您的数据库安装和Web语言（php）配置以处理转义字符，然后对模块进行编码）以迭代输入以确保其格式正确。

撇号可以是有效输入，但也可以避免传递数据库语句并引入攻击向量。 DB和Web语言具有可以处理这些类型实例的模块，但是编写自己的模块进行仔细检查仍然是一个好主意。

#11 楼

我认为这是一个观点问题。您的系统具有应首先满足的功能要求。这并不意味着不值得考虑输入验证的问题。顺便说一句，两者并不直接矛盾。我不建议这样做，但是可以在前端进行编码和解码，并让SQL存储和查询使用编码形式。没有提到的事情。您可以尝试让他们澄清。他们可能有很好的理由，但可能没有。

#12 楼

我会与大多数其他当前答案相矛盾。

您的渗透测试者几乎可以肯定100％正确。已发现您的应用程序在没有有效的撇号的情况下接受并回了撇号。

您的用户名，电话号码，域名和日期可能都应具有特定的格式和字符范围。所有人都应该没有撇号。但是，相反，对于所有这些字段，您只接受它们给您的任何旧字符串。

如果这个假设是正确的并且在输入中撇号将无效，那么：


是的，您应该拒绝无效的完全输入。

您不应该允许人们使用损坏的数据来污染数据库。
您不应尝试在显示时清理该数据，其数量应超出您的期望。尝试清理<script>，因为攻击者只会找到一种利用清理算法的方法，例如<script >或<scr<script>ipt>或+ADw-script+AD4-或其他。
您肯定有例外，但是应该将它们明确定义为特殊情况：
除非您的要求明确要求处理带有撇号的瑞士地区货币， “ 1'000'000”的整数不再是“ 1〜000〜000”或“ 1ba​​nana000apple000”的有效整数。拒绝它。不要尝试清除“ 1'000”，您不知道它们的意思是1,000还是1.000或14000还是一个英尺或一个度数或完全不同的东西。

查询参数化仅避免大多数类SQL注入：不是所有可能的滥用无效数据。

但是依赖于用户名符合公司标准的所有其他系统又如何呢？你刚刚把它们弄坏了。


用户是否有主目录？那会是个问题。
他们的名字会被记录在任何地方吗？
他们曾经被显示吗？
用户名是否曾经在系统调用的命令参数中使用？
他们曾经吗？发送AJAX或XML数据吗？
是否有对批处理用户名运行的批处理模式操作，例如名称从A到M的一天开始，从N到Z的第二天开始，第三天的0-9，然后重复？这些批次永远不会对您的用户不利。
在某些情况下冒充另一个用户对某人有害或有用，因此您希望他们所有人都具有唯一的名称吗？但是通过注册JohnͿο𝗁ո𝗁ոоհ𝗇或like之类的东西，他们可以冒充用户John。
所有使用该名称的系统都不能拒绝您提供的值。相反，它们将不得不处理无效的输入，尝试清除或转义它们，即使我们已经表明这是不安全的并且注定要失败。但是，由于该用户已经注销很长时间了，因此他们不会看到要求输入新电子邮件地址的任何错误。
您的DBA现在在他的数据库中有废话。这不仅使他在日常工作中，而且在他不得不迁移数据时，都会给他带来很多痛苦，因为目标系统中任何更严格的约束都会破坏旧数据。
您的同事和其他消费者您的数据现在必须验证他们从数据库读取的所有内容，因为他们甚至不相信您已执行了完全记录的标准。
您的用户现在使用的是安全性较低的系统。
您现在必须去做所有这些输入，以确保您不再将垃圾输入数据库。

查询参数化不是正确地清理输入的替代方法。