是否可以通过 MailAddress 类进行 XSS？

Posted 2023-02-19

【中文标题】是否可以通过 MailAddress 类进行 XSS？

【英文标题】：Is XSS possible through the MailAddress class?

【发布时间】：2013-04-09 01:33:18

【问题描述】：

考虑到我将用户输入（应该是电子邮件地址）解析到 MailAdress 类中：

var mailString = Request.QueryString["mail"];
var mail = new MailAddress(mailString);

如果我稍后以任何方式输出 MailAddress 对象，是否还有可能发生跨站点脚本攻击？例如通过 WebForms 中的 Literal 控件：

litMessage.Text = "Your mail address is " + mail.Address;

即使我通过解析字符串确保地址是有效的电子邮件地址，是否有必要清理输出？

据我所知，邮件地址的 RFC 非常复杂，所以我不确定跨站点脚本是否可以隐藏在 .NET 认为有效的邮件地址中。

编辑：MSDN 表示电子邮件地址中允许使用 > 和 < 括号：

如果您将地址括在尖括号中，地址参数可以包含显示名称和关联的电子邮件地址。例如：“汤姆·史密斯 ”

所以问题仍然存在，这是否足以应对 XSS 攻击和/或 MailMessage 类是否会采取任何措施来逃避危险部分。

【参考方案1】：

是否有必要对输出进行消毒

您不会“清理”输出，而是对其进行编码。您输出到 html 文档中的每个字符串都需要进行 HTML 编码，因此如果邮件地址中有 < 字符，这无关紧要 - 结果，您会在 HTML 源中得到 <，并且这将在页面上正确显示为文字 <。

许多 ASP.NET 控件会自动为您处理 HTML 转义，但 Literal 默认情况下不会，因为它可用于显示标记。但是，如果您将Literal 控件的Mode 属性设置为Encode，那么像您正在做的那样设置Text 是非常好的。

您应该确保每次将内容放入 HTML 页面时始终使用安全的 HTML 编码输出，无论您是否认为您使用的值将能够包含 < 字符。这是一个关注点分离的问题：HTML 输出代码知道所有关于 HTML 格式的信息，但它不应该知道关于电子邮件地址或其他应用程序字段中哪些字符是正确的。

因为您认为该值是“安全”而忽略转义会在输出级和输入级之间引入隐式且脆弱的耦合，从而难以验证代码是否安全，并且在您制作时很容易使其不安全变化。

【参考方案2】：

一般来说，您以后不需要验证输出。但是，我始终建议您这样做，原因如下：

您的应用程序中的某处可能存在无法正确验证输入的漏洞。这可能会被攻击者发现并用于 XSS。当许多不同的开发人员都在开发该应用时，这一点尤其可能。 在实施/更新输入过滤器之前存储的数据库中可能存在旧数据。这可能包含可用于 XSS 的恶意代码。 攻击者非常聪明，通常可以想出办法来击败过滤器。微软非常重视防止这种情况发生，但它永远不会完美。如果攻击者面对和输出过滤器以及输入过滤器，这会使攻击者的工作变得更加困难。

我知道不断过滤很痛苦，但这样做有很多价值。在当今世界，纵深防御战略是必要的。

编辑：

抱歉，我没有真正回答您问题的第二部分。根据文档，我没有得到这样的印象，即 API 专注于清理和验证有效格式一样多。因此，我不知道出于安全目的依赖它是否安全。

但是，编写自己的消毒剂并不难，如果发现缺陷，可以立即更新。首先通过一个良好的 RegEx 过滤器运行地址（请参阅：Regex Email validation），然后递归删除电子邮件地址中的每个无效字符（此时不应通过，但这样做是为了全面和如果您想在其他地方重用该类），然后用 HTML 含义转义每个字符。我强调过滤器的递归应用，因为攻击者可以利用这样的东西来利用非递归过滤器：

<scr<script>ipt>

请注意，非递归过滤器将删除 <script> 的中间出现并保留外部出现的完整。

【讨论】：

如果 MailAddress 类已经确保只接受有效字符串，那么使用额外的正则表达式过滤器有什么意义？我的问题是有效的电子邮件地址是否可以包含 XSS 攻击，这些攻击可能会以这种方式通过验证。当然，当您说在创建输出时转义 html 字符绝不是一个坏主意时，您是对的。但是我想知道如果使用MailMessage 对象，这种攻击是否可能发生。了解可能的攻击者可能有哪些选择绝不是一个坏主意。

您是正确的，在使用 MailAddress 类时不需要添加正则表达式过滤器。我把它包括在这里是为了开发消毒剂的完整性。话虽如此，但在高安全性环境中，我们不喜欢信任专有/封闭源代码，因为我们无法审查它的漏洞。出于这个原因，我们编写自己的。至于通过MailMessage 进行攻击，我不知道那里有任何攻击，但这并不意味着这是不可能的，尤其是如果您以作者没有预料到的方式使用该类。

如果有人发起了针对MailAddress 的攻击，他们很可能不会放弃，因为它在地下值得很多钱。我刚刚听说一个 Java 7 hack 以 50,000 美元的价格出售。一旦被披露，它们将一文不值。