所以我一直在使用带有白名单的 html 敏捷性构建 C# html sanitizer。它工作正常，除了以下情况：
<img src="javascript:alert('BadStuff');" />
<img src="jav	ascript:alert('BadStuff');">
我确实想允许 src 属性，但显然不是恶意内容。我查找的所有内容都刚刚推荐了标签及其属性的白名单。你会如何处理这样的事情呢？我知道这在任何较新的浏览器中都不起作用，但我对安全性不是很熟悉，而且我确信攻击者可以做一些其他聪明的事情。
【问题讨论】：
标签： c# security xss html-agility-pack
只要您正确清理和处理输入，您就可以安全地允许 src 属性。为此，您应首先通过有效 URL 字符的白名单 canonicalize it 对其进行清理，然后验证它是否指向有效图像。
您提到的白名单是第一步（也是重要的一步）。要实施白名单，只需删除对 URL 无效的每个字符。还要验证 URL 的格式是否正确，这意味着它指向用户应该能够访问的有效资源。例如，用户不应该通过传入file://sensitive.txt 或其他东西来访问服务器上的本地文件。如果 http 或 https 是唯一应该使用的协议，请检查 URL 是否以这些协议开头。如果您特别偏执，您可能会完全拒绝该请求，因为很明显它已被篡改。白名单很重要，但单独的白名单不会保证功能的安全。
规范化很重要，因为许多攻击依赖于提交最终将您带到某个位置的 URL，但可能会滥用计算机与生俱来的缺乏推理能力来获取不应该执行的操作。这也将有助于消除相同资源的重复路径，这可能会提高性能（或者至少允许您通过不重新检查自上次检查以来未更改的已知文件来提高性能。但请注意这一点，因为可以欺骗最后修改日期，以便攻击者可以在您已经“检查并信任”它之后交换恶意文件）。
要验证您指向的图像是否有效，请打开文件并读取前几个字节。 不要简单地信任文件扩展名，尽管在打开文件之前先检查它（为了性能和安全）。每种图像格式都有特定的字节模式可供您检查。 look at first is JPEG 的好消息。恶意用户仍有可能将 shellcode 或其他攻击代码放在图像文件中， 包含正确的标题，但要做到这一点要困难得多。这将是一个性能瓶颈，因此如果您实施它，请进行适当的计划。
【讨论】：
类似“必须是有效的 Uri，无论是相对还是绝对的 http/https 方案”是很好的起点。
【讨论】：
Uri.Scheme 和 Uri.TryCreate 是我会使用的。我强烈怀疑您是在谈论使用string.StartsWith 而没有认真阅读和学习Uri - RFC 3986。