如何克服对用户输入的恐惧（网络开发）

Question

我正在编写一个供公众使用的网络应用程序...您如何克服/处理对用户输入的恐惧？作为一名 Web 开发人员，您知道存在的技巧和漏洞，尤其是在 Web 上可以利用的技巧和漏洞，通过 Firebug 等附加组件变得更加容易。

有时，它是如此令人难以承受，您只想忘记整个交易（确实使不过，您很欣赏 Intranet 开发！）

抱歉，如果这不是一个可以简单回答的问题，但也许想法或策略会有所帮助......谢谢！

Answer 1

一个词：服务器端验证（好吧，这可能是三个词）。

Answer 2

其他答案中有很多合理的建议，但我将添加一个不那么“编程”的答案：

制定处理计划。

为恶意用户确实设法偷偷过去的意外情况做好准备你。制定计划来减轻损害、恢复干净和完整的数据，并与用户（以及潜在的其他相关方，例如您持有的任何信用卡详细信息的发卡行）进行沟通，告诉他们发生了什么。了解如何检测漏洞并关闭它。要知道关键的运营和开发人员是可以联系到的，这样，在公共假期前的周五下午 5:01 发动攻击的坏人在您下线之前不会有 72 个以上的空闲时间，更不用说开始修复问题了。

制定适当的计划并不能帮助您阻止不良的用户输入，但它应该有助于克服您的恐惧。

Answer 3

如果您需要解决与“安全”相关的问题，那么安全和漏洞利用是软件中不可避免的事实，并且需要在开发过程中正面解决它们。

以下是一些建议：

• 正确看待 - 任何流行或有用的应用程序都会发生安全性、漏洞利用和妥协，为它们做好准备并期望它们发生
• 测试它，然后再次测试它 - 质量保证、验收测试和即使您是一家单人商店，签核也应该是您设计和生产过程中的一流部分。招募用户作为专门的（和有声的）用户进行测试将是您发现问题的最有用的工具。
• 了解您的平台 - 确保您了解您正在部署的技术和硬件。确保相关补丁和安全更新经过应用
• 研究 - 查看与您自己的应用程序类似的应用程序，看看他们遇到了什么问题，浏览他们的论坛，阅读他们的错误日志等。
• 现实点 - 您将无法修复每个错误并且关闭每个孔。选择最有影响力的，并
• 吸引尽可能多的人来审查您的设计和代码。这应该是您的 QA 资源的补充

Answer 4

• 你无法克服它。
• 检查服务器端的所有内容 - 再次验证输入、检查权限等。
• 清理所有数据。

用粗体字写起来很容易，但在实践中却有点困难。

Answer 5

我经常做的事情是将所有用户字符串包装在一个对象中，例如 StringWrapper ，它强制您调用编码方法来获取字符串。换句话说，只需提供对 s.htmlEncode() s.urlEncode().htmlEncode() 等的访问即可。当然，您需要获取原始字符串，这样您就可以有一个 s.rawString() 方法，但现在您可以使用 grep 来查看原始字符串的所有使用。

因此，当您遇到“echo userString”时，您将收到类型错误，然后系统会提醒您通过公共方法对字符串进行编码/转义。

其他一些一般性的事情：

• 优先使用白名单而不是黑名单
• 不要过度剔除不良输入。我希望能够使用 <帖子/评论/等中的角色！只需确保正确编码数据
• 即可使用参数化 SQL 查询。如果您自己使用 SQL 转义用户输入，那么您就做错了。

Answer 6

首先，我会试图安慰你一点，指出偏执是件好事。正如开车时有点害怕是好事一样，害怕用户输入也是好事。尽可能做最坏的打算，你不会失望的。

其次，防御性编程。假设您与外界的任何通信都完全受到损害。仅接受用户应该能够控制的参数。仅公开用户应该能够看到的数据。

净化输入。消毒消毒消毒。如果它的输入将显示在网站上（排行榜的昵称、论坛上的消息等），请对其进行适当的清理。如果输入可能会发送到 SQL，也请对其进行清理。事实上，甚至不要直接编写 SQL，而是使用某种中介。

如果您使用 HTTP，实际上只有一件事是您无法防御的。如果您使用 cookie 来识别某人的身份，则您无法阻止咖啡馆中的其他人嗅探该咖啡馆中其他人的 cookie（如果他们都使用相同的无线连接）。只要他们不使用安全连接，就没有什么可以帮助您避免这种情况。即使 Gmail 也无法免受这种攻击。您唯一能做的就是确保授权 cookie 不会永远持续下去，并考虑让他们在做一些大事（例如更改密码或购买东西）之前重新登录。

但别担心。许多安全细节已经由您在其上构建的任何系统处理（您正在构建在某些东西之上，不是吗？Spring MVC？Rails？Struts？）。这真的没那么难。如果涉及大笔资金，您可以付费聘请安全审计公司来尝试破解它。如果没有，就试着想出一切合理的办法，并在发现漏洞时修复它们。

但不要停止偏执。他们总是出去找你。这只是受欢迎的一部分。

PS 还有一个提示。如果你有这样的 JavaScript：

if( document.forms["myForm"]["payment"].value < 0 ) {
  alert("You must enter a positive number!");
  return false;
}

那么你肯定在后端有这样的代码：

verify( input.payment >= 0 )

Answer 7

“引用”所有内容，使其在“目标”语言中没有任何含义：SQL、HTML、JavaScript 等。

这当然会造成妨碍，因此您必须小心确定何时需要特殊处理，就像通过管理权限来处理一些如果数据一样。

Answer 8

有多种类型的注入和跨站点脚本（请参阅这个早期的答案），但对所有这些都有防御措施。首先，您显然需要查看存储过程、白名单（例如，用于 HTML 输入）和验证。

除此之外，很难给出一般性建议。其他人给出了一些很好的建议，例如始终进行服务器端验证和研究过去的攻击。

保持警惕，但不要害怕。

Answer 9

• Web 应用程序层没有验证。
• 所有验证和安全检查应由领域层或业务层完成。
• 抛出带有有效错误消息的异常，并让这些异常在表示层或 Web 应用程序中被捕获和处理。

您可以使用验证框架
在帮助下自动验证
自定义验证属性。

http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=477

Answer 10

应该有一些关于您正在使用的语言/系统的已知漏洞的文档。我知道 Zend PHP 认证稍微涵盖了这个问题，您可以阅读学习指南。

为什么不聘请专家时常审核您的申请呢？考虑到您的关注程度，这是一项值得的投资。

Answer 11

我们的客户总是说：“与我的用户打交道，因为他们不区分日期和文本字段！！”

我用 Java 编写代码，我的代码充满了断言，我认为客户端的一切都是错误的，我在服务器上检查了一切。

Answer 12

对我来说，第一件事就是始终构建静态 SQL 查询并将数据作为参数传递。这极大地限制了您必须处理的报价问题。另请参阅 http://xkcd.com/327/

这也具有性能优势，因为您可以重新使用准备好的查询。

Answer 13

实际上，您只需要注意两件事：

1. 避免SQL 注入。使用参数化查询将用户控制的输入保存在数据库中。用 Java 术语来说：使用 PreparedStatement< /a>.用 PHP 术语来说：使用 mysql_real_escape_string() 或 PDO。

2. 避免XSS。在显示期间转义用户控制的输入。在 Java/JSP 术语中：使用 JSTL 。用 PHP 术语来说：使用 htmlspecialchars()。

就这样。您无需担心数据的格式。只是关于你如何处理它的方式。