10

你们都认为什么是正确的（阅读：最灵活、松散耦合、最健壮等）使来自 Web 的用户输入安全地用于 Web 应用程序的各个部分的方法？显然，我们可以为每个上下文（数据库、屏幕显示、磁盘保存等）使用各自的清理功能，但是是否有一些通用的“模式”来处理不安全的数据并使其安全？是否有一种既定的方法可以强制将其视为不安全，除非它被适当地安全化？

4

3 回答 3

4

就像已经说过的那样，当您担心网络安全时，有几件事情需要考虑。以下是一些需要考虑的基本原则：

  • 避免将用户的直接输入集成到查询和变量中。

所以这意味着没有类似的东西$variable = $_POST['user_input']。对于这样的任何情况，您都将过多的控制权交给了用户。如果输入影响某些数据库查询，请始终使用白名单来验证用户输入。如果查询是针对用户名的，请根据正确的用户名列表进行验证。不要简单地使用直接放入的用户输入进行查询。

一个（可能的）例外是搜索字符串。在这种情况下，您需要进行消毒，就这么简单。

  • 避免在不卫生的情况下存储用户输入。

如果用户正在为其他用户创建个人资料或上传信息，则您必须拥有可接受的数据类型的白名单，或者删除任何可能是恶意的数据。这不仅是为了您系统的安全，也是为了您的其他用户（请参阅下一点。）

  • 切勿在不剥离用户的情况下将任何内容从用户输出到浏览器。

这可能是安全顾问向我强调的最重要的事情。当用户收到输入时，您不能简单地依赖清理输入。<plaintext>如果您没有自己编写输出，请始终通过对任何 HTML 字符进行编码或将其包装在标签中来确保输出是无害的。如果用户 A 上传了一些 javascript，这会损害查看该页面的任何其他用户，这只是开发人员的疏忽。知道任何和所有用户输出只能在所有浏览器上显示为文本，您晚上会睡得更好。

  • 绝不允许除用户之外的任何人控制表单。

XSS 比它应该的要容易，并且在一个段落中涵盖一个真正的痛苦。简而言之，每当您创建表单时，您就可以让用户访问处理表单数据的脚本。如果我窃取了某人的会话或某人的 cookie，我现在可以像在表单页面上一样与脚本交谈。我知道它期望的数据类型和它要查找的变量名称。我可以简单地将这些变量传递给它，就好像我是用户一样，脚本无法区分。

以上不是卫生问题，而是用户验证问题。我的最后一点与这个想法直接相关。

  • 避免使用 cookie 进行用户验证或角色验证。

如果我可以窃取用户的 cookie，我可能会做的不仅仅是让那个用户度过糟糕的一天。如果我注意到 cookie 有一个名为“member”的值，我可以很容易地将该值更改为“admin”。也许它不起作用，但对于许多脚本，我可以即时访问任何管理员级别的信息。

简而言之，没有一种简单的方法可以保护 Web 表单，但是有一些基本原则可以简化您应该做的事情，从而减轻保护脚本的压力。

再次为好的衡量标准：

  • 清理所有输入
  • 编码所有输出
  • 根据严格的白名单验证用于执行的任何输入
  • 确保输入来自实际用户
  • 永远不要让任何用户或基于角色的验证浏览器端/用户可修改

永远不要假设任何人的清单是详尽的或完美的。

于 2009-08-16T07:27:59.947 回答
1

我有点怀疑这样一个通用框架是否可以存在并且比编程语言更简单。

不同层对“安全”的定义如此不同

  • 输入字段验证、数字、日期、列表、邮政编码、车辆登记
  • 跨领域验证
  • 域验证 - 这是一个有效的抄表吗？琼斯小姐这个月用了 3 亿英镑的电费？
  • 请求间验证 - 您真的在同一天为自己预订了两趟跨大西洋航班吗？
  • 数据库一致性、外键验证
  • SQL注入

还要考虑发现违规行为时的操作。

  • 在 UI 层，我们几乎肯定不会只是悄悄地从数字字段中删除非数字字符，我们会引发 UI 错误
  • 在 UI 中，我们可能想要验证所有字段并标记每个单独的错误
  • 在其他层中，我们可能会抛出异常或启动业务流程

也许我错过了你的愿景？你有没有看到任何接近你的想法的东西？

于 2009-08-16T06:12:21.033 回答
0

您不能使用单一方法来清理所有用途的数据，但一个好的开始是：

过滤器 Var 采用多种不同类型的数据并去除不良字符（例如您希望是数字的非数字），并确保其格式有效（IP 地址）。

注意：电子邮件地址比 Filter_Var 的实现要复杂得多，因此请谷歌搜索正确的功能。

在您即将将内容输入数据库之前，我不建议使用它，而且无论如何最好只使用准备好的 mysqli 语句。

于 2009-08-16T02:55:00.870 回答