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