2

我正在为一家本地托管公司开发票务系统，其中一个要求是用户能够提交带有实际 html 的票证。这将是一个有效的输入。

<html>
  <head>
    <script>alert('hello!');</script>
  </head>
</html>

该输入可以通过在线提交或进入系统的电子邮件放入系统。

此外，业务需求之一是查看票证的人能够看到 html 版本为 html，因此以某种方式将其呈现给浏览器是业务需求。

现在，我明白了，我绝对没有办法保护这个系统。在我能够做到的地方，我做了很多工作来保护它，但是鉴于当前的业务需求，这个特殊的安全漏洞是无法修复的。

我什至无法想象将这些东西列入白名单，因为用户可能正在描述一个嵌入了脚本标签的 html 页面，一个 web.config 文件，一个 XML 文件，一个 odf 文件，你可以命名它，他们可能有一个用户发送了一个中的例子。

我不习惯编写要求如此“开放”的软件，我不确定如何最好地解决这个问题。我目前的想法是风险管理而不是风险预防，我认为在这种情况下没有其他方法可以有效地限制恶意输入。但是，如果有人对我如何根据当前要求进行某种预防有任何建议，我会全力以赴。既然我确定有人会提出来，我也说我已经和我签约的公司的老板进行了坦率的交谈，要求不会很快改变:)

我想从处理过这种情况的人那里得到意见，以及根据这种经验你可以给出什么建议。我对理论不是很感兴趣，而是对实践感兴趣。我的部分目标是在所有者面前提出一个可靠的建议，看看我们可以做些什么来妥协整个安全与便利的权衡。

另请记住，该系统最终将出售给他们的客户，这意味着我根本无法做出许多假设。目前，该系统是为他们而构建的，但随着时间的推移，我们所做的许多假设最终将被删除或推广。

我的第一个想法是对传入电子邮件进行某种风险评估，如果电子邮件超过阈值，则会自动设置某些限制。诸如无法在浏览器中查看 html 版本，在文本编辑器而不是浏览器中打开它之类的事情。我担心这对用户来说可能是一种痛苦，并且我采取的任何解决方法（“批准电子邮件”）都将在没有任何实际想法的情况下使用，从而使这毫无价值。

我还考虑过“受信任区域”，我的意思是，来自新电子邮件地址的工单受到限制，直到来自该地址的 X 个工单，限制总是针对通过 Web 界面创建的工单/电子邮件设置，之类的东西。在许多方面，这与其他解决方案具有相同的问题。

另一个解决方案是顺其自然。这显然是最简单的解决方案，它可能是一个有效的解决方案，但我需要一个非常有力的论据才能接受它。

我并没有放弃 HTML 解析器并亲自查看电子邮件中的特定内容，但我不相信有任何自动化方法可以保护这个系统而不会出现误报，所有者已经明确表示这是完全不可接受的。据我所知，谁想通过电子邮件发送支持却永远不会收到他们的消息？

来自过去解决此问题的人的任何建议或见解将不胜感激。我使用的具体技术是 ASP.Net 4.5/IIS

4

2 回答 2

4

对我来说，第一个答案是显而易见的：不要那样做。不要让他们提交任意 HTML/JS，然后将其呈现给经过身份验证的客户端。我无法完全想象有必要这样做的场景。

第二个最明显的答案是 Guffa 的：如果你渲染它，那么计划是在它不能使用任何身份验证的环境中渲染它，窃取 cookie 或重定向到经过身份验证的操作等等. 即，进行渲染的页面未经过身份验证，并且不需要 cookie 即可查看（或类似方法）。但是，他们仍然有可能任意编写恶意 JavaScript，而这些 JavaScript 本身就可能会做坏事。例如，您可以获取他们的任何输入，将其呈现为纯 .HTML 文件，查看器必须在其浏览器中本地打开（即非托管）；这仍然很糟糕。

所以总的来说，这是一个非常糟糕的主意，我不会这样做。典型的出路是强制任何提交的数据结构非常好（比如在这个论坛上），这样您就可以以适当的方式处理特定的位。这可能是他们想要的——即他们只是不想限制输入；但也许您应该为某些类型的输入（代码示例，什么-不是）设置一个单独的区域。

总而言之：避免这种情况；您可以在某些方面使您的情况稍微好一些，但基本上仍然会很糟糕。

于 2013-01-03T00:38:42.550 回答
1

如果您真的需要允许任何代码，那么我唯一能想到的就是使用浏览器的跨站点限制。

如果您设置指向同一站点的不同域，并在加载动态内容时使用该域名，并将内容加载到 iframe 中，则 iframe 将与站点的其余部分隔离。

于 2013-01-03T00:29:40.223 回答