Question

考虑我将用户输入（应该是电子邮件地址）解析为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表示电子邮件地址允许>和<括号：

如果将地址括在尖括号中，则address参数可以包含显示名称和关联的电子邮件地址。例如：“Tom Smith＆lt; tsmith@contoso.com>”

所以问题仍然存在，如果这对于XSS攻击是否足够和/或MailMessage类是否做了什么来逃避危险的部分。

Answer 1

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

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

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

编辑：

对不起，我没有真正回答你问题的第二部分。根据文档，我不会觉得API专注于消毒，就像验证有效格式一样。因此，我不知道出于安全目的而依赖它是安全的。

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

<scr<script>ipt>

请注意，非递归过滤器会删除<script>的中间出现并使外部事件保持原状。

Answer 2

是否有必要对出水口进行消毒

你没有'清理'输出，你编码它。您输出到HTML文档的每个字符串都需要进行HTML编码，因此如果邮件地址中有<个字符，则无关紧要 - 您将在HTML源代码中获得<因此，它将在页面上正确显示为文字<。

许多ASP.NET控件会自动为您进行HTML转义，但默认情况下Literal不会，因为它可用于显示标记。但是，如果您将Mode控件的Literal属性设置为Encode，则设置Text就像您正在做的那样完全没问题。

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

因为你认为值是'安全'而导致逃逸，会在输出阶段和输入阶段之间引入隐含且脆弱的耦合，这使得难以验证代码是否安全并且在制作时很容易使其不安全变化。

XSS是否可以通过MailAddress类？

2 个答案: