我正在为一家本地托管公司开发一个票务系统，其中一个要求是用户能够提交包含实际 html 的票证。这将是一个有效的输入。
<html>
<head>
<script>alert('hello!');</script>
</head>
</html>
此输入可以通过在线提交或进入系统的电子邮件放入系统中。
此外，业务需求之一是那些查看票证的人能够看到 html 版本作为 html，因此以某种方式将其呈现给浏览器是一项业务需求。
现在，我明白我绝对没有办法保护这个系统。我在力所能及的地方做了很多工作来保护它，但考虑到当前的业务需求，这个特定的安全漏洞是无法修复的。
我什至无法想象将这些东西列入白名单，因为用户可能会描述一个嵌入了脚本标签的 html 页面、一个 web.config 文件、一个 XML 文件、一个 odf 文件，凡是你能想到的，他们可能有一个用户已发送一个示例。
我不习惯编写具有如此“开放”要求的软件，并且我不确定如何最好地解决这个问题。我目前的想法是风险管理而不是风险预防，我认为没有其他方法可以有效限制这种情况下的恶意输入。但是，如果有人对我如何根据当前要求进行某种预防有任何建议，我会洗耳恭听。因为我确信有人会提出这个问题，所以我还要说，我已经与我签约的公司的所有者进行了坦诚的交谈，并且要求不会很快改变:)
我想了解处理过这种情况的人的意见，以及根据这些经验您可以提供哪些建议。我对理论并不感兴趣，而是对实践感兴趣。我的部分目标是向所有者提出一个可靠的建议，看看我们可以采取哪些措施来在整个安全性与便利性之间进行权衡。
另请记住，该系统最终将出售给他们的客户，这意味着我根本无法做出许多假设。目前，该系统是为他们构建的，但随着时间的推移，我们现有的许多假设最终将被删除或概括。
我的第一个想法是对传入电子邮件进行某种风险评估，如果电子邮件达到阈值，则会自动实现某些限制。比如无法在浏览器中查看 html 版本，在文本编辑器而不是浏览器中打开它之类的事情。我担心这可能会给用户带来痛苦，并且我采取的任何解决方法(“批准电子邮件”)都将在没有任何实际考虑的情况下使用，从而变得毫无值(value)。
我还考虑过“受信任区域”，我的意思是，来自新电子邮件地址的票证受到限制，直到来自该地址的 X 票证数量为止，始终对通过网络界面之类的东西。在许多方面，这与其他解决方案存在相同的问题。
另一个解决方案是顺其自然。这显然是最简单的解决方案，而且可能是一个有效的解决方案，但我需要一个非常有力的论据才能接受它。
我并不打算拿出一个 HTML 解析器并亲自查看电子邮件中的特定内容，但我不相信有任何自动化方法可以保护该系统而不会出现误报，所有者已经明确表示这是完全错误的 Not Acceptable 。据我了解，谁想给支持人员发电子邮件却永远得不到他们的回复？
如果来自过去解决过这个问题的人的任何建议或见解，我们将不胜感激。我使用的具体技术是 ASP.Net 4.5/IIS
最佳答案
对我来说，第一个答案是显而易见的:不要这样做。不要让他们提交任意 HTML/JS，然后将其呈现给经过身份验证的客户端。我无法想象有必要这样做的场景。
第二个最明显的答案是 Guffa 的:如果你确实渲染它，那么计划将在一个无法利用任何身份验证的环境中渲染它，以窃取 cookie 或重定向到经过身份验证的操作，并且不是什么。 IE。进行渲染的页面未经身份验证，并且不需要 cookie 来查看(或类似的方法)。然而，他们仍然有可能任意编写恶意 JavaScript，这些 JavaScript 本身就可以做坏事。例如，您可以获取他们拥有的任何输入，将其呈现为纯 .HTML 文件，查看者必须在其浏览器中本地打开该文件(即未托管)；这仍然很糟糕。
所以总的来说，这是一个非常糟糕的主意，我不会这样做。典型的解决方法是强制任何提交的数据都具有良好的结构(例如，在本论坛上)，以便您可以以适当的方式处理特定的位。无论如何，这可能是他们想要的——也就是说，他们只是不想限制输入；但也许您应该为某些类型的输入(代码示例，等等)设置一个单独的区域。
总而言之:避免这种情况；你可以通过某些方式让你的情况稍微好一点，但基本上仍然会很糟糕。
关于asp.net - 如何最大限度地降低 XSS 易受攻击的应用程序的风险？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14131365/