我正在为本地托管公司开发一个票务系统，其中一个要求是用户可以使用实际的html提交票证。这将是一个有效的输入。
<html>
<head>
<script>alert('hello!');</script>
</head>
</html>
此输入可以通过在线提交或进入系统的电子邮件发送到系统中。
此外，其中一项业务要求是查看故障单的人能够将html版本视为html ，因此以某种方式将其呈现给浏览器是业务需求。
现在，我知道我绝对没有办法保护这个系统。在我能够这样做的地方，我已经做了很多工作来保护它，但考虑到当前的业务需求，这个特殊的安全漏洞根本无法解决。
我甚至无法将这些东西列入白名单，因为用户可能正在描述一个嵌入了脚本标签的html页面，一个web.config文件，一个XML文件，一个odf文件，你给它命名，他们可能有一个用户已经发送了一个例子。
我不习惯编写具有如此“开放”要求的软件，而且我不确定如何最好地解决这个问题。我目前的想法是风险管理而不是风险预防，我认为在这种情况下没有其他方法可以有效地限制恶意输入。但是，如果有人对如何根据当前要求做某种预防有任何建议，我全都听见了。由于我确信有人会提出这个问题，我还要说我与我正在签约的公司的所有者进行了坦率的对话，而且要求不会很快改变：）
我希望得到处理此方案的人的意见以及根据这些经验可以给出的建议。我对理论并不感兴趣，而是练习。我的部分目标是在所有者面前提出一个可靠的提案，看看我们可以做些什么来妥协整个安全性与便利权衡。
另外请记住，这个系统最终将被出售给他们的客户，这意味着有许多我根本无法做出的假设。目前，该系统对他们来说是相当具体的，但随着时间的推移，我们所拥有的许多假设最终将被删除或推广。
我的第一个想法是对收到的电子邮件进行某种风险评估，如果电子邮件超过阈值，则会自动实施某些限制。像是无法在浏览器中查看html版本，在文本编辑器而不是浏览器中打开它等等。我担心的是，这对用户来说可能是一种痛苦，而且我所使用的任何解决方法（“批准电子邮件”）都会被使用而没有任何实际的想法，这使得它毫无价值。
我还考虑过“受信任的区域”，我的意思是，来自新电子邮件地址的门票有限制，直到来自该地址的X张票数，对通过该地址创建的门票/电子邮件的限制总是有限制网络界面，那种事情。在许多方面，这与其他解决方案的情况相同。
另一个解决方案是让它成为现实。这显然是最简单的解决方案，它可能是一个有效的解决方案，但在我接受之前我需要一个非常强大的论据。
我不是要拔出一个HTML解析器并自己查看特定内容的电子邮件，但我不相信有任何自动保护系统的方法而不会出现误报，业主已经明确表示完全是不能接受的。据我所知，谁想通过电子邮件发送支持只是为了从不听取他们的意见？
过去那些解决过这个问题的人的建议或见解将不胜感激。我使用的具体技术是ASP.Net 4.5 / IIS
答案 0 :(得分：4)
对我来说，第一个答案是显而易见的：不要那样做。不要让他们提交任意HTML / JS，然后将其呈现给经过身份验证的客户端。我无法想象这是必要的场景。
第二个最明显的答案是在Guffa之后：如果你做了渲染，那么计划就是将它呈现在一个环境中，它不能利用任何经过身份验证的程序，窃取cookie或重定向到经过身份验证的操作，什么，而不是。即进行渲染的页面未经过身份验证，无需查看cookie（或类似方法）。然而，他们仍然可以随意编写恶意JavaScript，这些JavaScript本身就可以做坏事。例如，您可以获取他们拥有的任何输入，将其渲染为纯.HTML文件，观众必须在浏览器中本地打开（即未托管）;这仍然坏。
所以总的来说，这是一个非常糟糕的主意，我不会这样做。典型的出路是强制任何数据提交结构良好（例如，论坛），这样您就可以以适当的方式处理特定的位。这可能是他们想要的 - 也就是说他们只是不想限制输入;但也许你应该为某些类型的输入设置一个单独的区域（代码样本，什么不是）。
总结：避免这种情况;你可以在某些方面使你的情况略微好转，但它仍然基本上是坏的。
答案 1 :(得分：1)
如果你真的需要允许任何代码，那么我唯一能想到的就是使用浏览器的跨站点限制。
如果您设置指向同一网站的其他域，并在加载动态内容时使用该域名，并在iframe中加载内容，那么iframe将与网站的其余部分隔离。