用户等于不可信。永远不要信任不可信用户的输入。我明白了。但是，我想知道何时清理输入的最佳时间。例如，我们是盲目存储用户输入，然后在每次访问/使用它时对其进行清理，还是我们立即对输入进行清理，然后存储此"已清理"版本？也许除了这些之外，我还没有其他一些方法。我更倾向于第一种方法，因为必须谨慎处理来自用户输入的任何数据，在这种情况下，"清除"的数据可能仍然在不知不觉中或者意外地危险。无论哪种方式，人们认为哪种方法是最好的，出于什么原因？

解决方案

回答

我发现立即清洁它有两个优点。第一，我们可以针对它进行验证并向用户提供反馈。第二，我们不必担心在其他地方使用数据。

回答

我喜欢尽早进行清理，这意味着清理过程是在用户尝试输入无效数据时发生的。如果他们的年龄有一个TextBox，并且他们输入的数字不是数字，那么我不会让该字母的按键通过。

然后，无论正在读取数据(通常是服务器)，我在读取数据时都会进行完整性检查，以确保不会因确定的用户(例如手动编辑文件或者修改数据包)而漏入！)

编辑：总体而言，尽早进行清理，并在我们甚至一秒钟都看不到数据时进行清理(例如，文件保存->文件打开)

回答

在将用户输入放到应用程序的较低层之前，应始终将其视为恶意输入。在检查恶意意图之前，请始终尽快处理清理输入，并且不应出于任何原因将其存储在数据库中。

回答

在存储数据之前，请先对其进行清理。通常，如果不先清理输入内容，就不应该执行任何SQL操作。我们不想让自己遭受SQL注入攻击。

我有点遵循这些基本规则。

• 仅通过POST修改SQL操作，例如INSERT，UPDATE，DELETE。永不获取。
• 逃避一切。
• 如果期望用户输入是某种东西，请确保检查它是否是某种东西。例如，我们要一个数字，然后确保它是一个数字。使用验证。
• 使用过滤器。清理不需要的字符。

回答

用户是邪恶的！

也许并非总是如此，但是我的方法是始终立即进行清理，以确保在我的后端附近没有任何风险。

额外的好处是，如果在输入点进行消毒，则可以向用户提供反馈。

回答

假设所有用户都是恶意的。
尽快清理所有输入。
句号

回答

在对数据进行任何处理之前，我会先对数据进行消毒。我可能需要将"姓氏"和"姓氏"字段连接起来，并将它们连接到要插入数据库的第三个字段中。在进行连接之前，我将清理输入，因此不会出现任何处理或者插入错误。越早越好。甚至在前端(在Web设置中)使用Javascript也是理想的，因为这会在没有任何数据进入服务器的情况下发生。

可怕的是，我们甚至可能还希望开始对数据库中的数据进行清理。最近发生的ASPRox SQL Injection攻击激增，具有双重致命性，因为它将感染给定数据库中的所有数据库表。如果数据库托管在同一数据库中托管多个帐户的某个地方，则由于其他人的错误，数据将被破坏，但是由于我们自己没有最初的过错，现在我们已经加入了将恶意软件托管给访问者的行列。

当然，这需要大量的工作，但是如果数据很关键，那么这是值得的投资。

回答

尽早进行比较好，绝对是在尝试解析它之前。我们以后要输出的任何东西，或者特别是传递给其他组件(例如，shell，SQL等)的东西都必须经过清理。

但是，例如，不要太过分，在存储密码之前，密码会被散列(对吗？)。哈希函数可以接受任意二进制数据。而且我们将永远不会打印出密码(对吗？)。因此，不要解析密码，也不要清理密码。

另外，请确保我们正在从受信任的进程中进行清理JavaScript /客户端方面的安全性要比无用的安全性/完整性方面的恶意行为更糟糕。 (尽管这两个地方都可以做到，但它可能会提供更好的用户体验，让他们尽早失败。)

回答

Perl有一个taint选项，该选项将所有用户输入都视为"污染"，直到使用正则表达式对其进行检查为止。受污染的数据可以使用和传递，但是会污染与之接触的所有数据，直到被污染为止。例如，如果用户输入添加到另一个字符串，则新字符串也会被污染。基本上，任何包含污点值的表达式都将输出污点结果。

污染的数据可以随意抛出(污染数据)，但是一旦对外部世界有影响的命令使用污染的数据，perl脚本就会失败。因此，如果我使用受污染的数据来创建文件，构造shell命令，更改工作目录等，Perl将失败，并出现安全错误。

我不知道另一种语言有"污点"之类的东西，但是使用它已经让我大开眼界。如果我们不立即取消污染数据的传播速度，那将是多么令人惊讶。对于程序员而言，自然而正常的事情(例如基于用户数据设置变量或者打开文件)在打开污点时似乎是危险且危险的。因此，完成工作的最佳策略是一旦我们从外部获得一些数据就取消污染。

而且我怀疑这也是其他语言中最好的方法：立即验证用户数据，以使错误和安全漏洞不会传播得太远。同样，如果潜在漏洞位于一个位置，则应该更容易审核安全漏洞的代码。而且我们永远无法预测以后将使用哪些数据来实现什么目的。

回答

最重要的是在逃跑时始终保持一致。偶然的双重消毒是la脚的，不消毒是危险的。

对于SQL，只需确保数据库访问库支持绑定变量即可自动转义值。手动将用户输入连接到SQL字符串的任何人都应该了解更多。

对于HTML，我更愿意在可能的最后时刻转义。如果销毁用户输入，则永远无法取回它；如果他们输入有误，则可以稍后进行编辑和修复。如果我们销毁了他们的原始输入，那么它将永远消失。

回答

这取决于我们正在执行的消毒方式。

为了防止SQL注入，请不要对数据本身做任何事情。只需使用准备好的语句，那样，我们就不必担心会弄乱用户输入的数据，并且不会对逻辑产生负面影响。我们必须进行一点点消毒，以确保数字是数字，日期是日期，因为所有内容都是来自请求的字符串，但是请勿尝试进行任何检查来执行诸如block关键字之类的操作。

为了防止XSS攻击，在存储数据之前修复数据可能会更容易。但是，就像其他人提到的那样，有时最好还是获得用户输入内容的原始副本，因为一旦我们进行更改，它就会永远丢失。几乎没有一种万无一失的方法来确保应用程序仅使用经过处理的查询来确保应用程序仅释放经过清理的HTML，从而确保我们不会被SQL注入所捕获，这几乎是很糟糕的。

回答

我的观点是尽快在客户端和服务器端对用户输入进行处理，我这样做是

• (客户端)，允许用户在字段中仅输入特定键。
• (客户端)，当用户使用onblur转到下一个字段时，请针对正则表达式测试他输入的输入，并注意是否有问题。
• (服务器端)，再次测试输入，如果field应该进行INTEGER检查(在PHP中，我们可以使用is_numeric())，如果field具有众所周知的格式，则对照regexp对其进行检查，其他所有检查(例如文本注释)，逃脱吧。如果有任何可疑的情况，请停止执行脚本，并向用户发送通知，告知他所输入的数据无效。

如果确实有可能发生某种攻击，则脚本会向我发送邮件和短信，因此我可以在可能的情况下尽快进行检查并设法阻止它，我只需要检查我登录所有用户输入的日志，并且接受或者拒绝输入之前脚本执行的步骤。

回答

我像Radu一样清理用户数据...

• 客户端首先使用正则表达式，并使用与事件(例如onChange或者OnBlur)相关联的javascript或者jQuery来控制允许输入到给定表单字段中的字符，这些事件会在甚至提交之前删除所有不允许的输入。但是请意识到，这实际上仅具有让那些用户知道数据也将在服务器端进行检查的作用。这比任何实际的保护措施更重要的是警告。
• 其次，这些天来我很少再看到这样做了，服务器端进行的第一个检查是检查提交表单的位置。通过仅允许从我们指定为有效位置的页面提交表单，我们甚至可以在读取任何数据之前杀死脚本。当然，这本身是不够的，因为拥有自己服务器的优秀黑客可以"欺骗"域和IP地址，以使其在脚本中显示它来自有效表单位置。
• 接下来，我什至不必说这句话，但总是，而且我的意思是总是以污点模式运行脚本。这迫使我们不要偷懒，要勤于步骤4.
• 使用格式正确的正则表达式尽快清理用户数据，该正则表达式适合于表单上任何给定字段所期望的数据。不要采取臭名昭著的"独角兽的魔角"之类的捷径来吹过污点检查……否则，最好还是首先关闭污点检查，以确保安全。这就像给精神病患者一把锋利的刀，bearing住你的喉咙，说："那样做，你真的不会伤害我。"这就是我在第四步中与其他大多数人不同的地方，因为我只对用户数据进行了消毒如果我仅使用用户输入的数据进行比较，则我将以可能带来安全风险的方式实际使用，例如任何系统调用，对其他变量的分配或者对存储数据的任何写入。到我自己存储在系统上的数据(因此知道我自己的数据是安全的)，那么我就不用理会用户数据了，因为我永远不会向我们提出将其自身视为安全问题的方式例如，以用户名输入为例，我仅使用用户输入的用户名来检查它是否与数据库中的匹配项匹配，如果为true，之后我将使用数据库中的数据来执行所有其他功能知道它是安全的，可能会在脚本中调用它，此后再也不会使用用户数据了。
• 最后，是使用"验证码"等"人工身份验证"系统，过滤掉如今机器人尝试进行的所有自动提交操作。如今这很重要，我花了一些时间来编写自己的"人类认证"模式，该模式使用照片和"人类"的输入来输入他们在图片中看到的内容。之所以这样做，是因为我发现Captcha类型的系统确实使用户烦恼(我们可以通过斜视的眼睛看出尝试破译失真的字母……通常一遍又一遍)。这对于使用SendMail或者SMTP发送电子邮件的脚本尤为重要，因为这些脚本是我们饥饿的垃圾邮件机器人的最爱。

简而言之，我将向我的妻子解释一下...服务器就像一个受欢迎的夜总会，而我们拥有的保镖越多，麻烦就越少
在夜总会。我在门外有两个保镖(客户端验证和人工身份验证)，在门内有一个保镖(检查有效的表单提交位置..."这个ID上确实是我们吗")，还有几个保镖
靠近门(运行异味模式并使用良好的正则表达式来检查
用户数据)。

我知道这是一篇较旧的文章，但是对于任何在我访问这里后可能会读到它的人来说，我觉得它的重要性已经足够重要，因为他们认识到他们在安全性方面不是"魔术子弹"，而且所有这些工作相互配合确保用户提供的数据安全。仅使用这些方法中的一种或者两种方法实际上是毫无价值的，因为它们的力量只有在他们一起协作时才存在。

或者总而言之，就像我妈妈经常说的那样："安全胜于遗憾"。