Возможно ли XSS через класс MailAddress?

Question

Учитывая, я анализирую пользовательский ввод, который, как предполагается, адрес электронной почты, в MailAdress класс:

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

Есть ли возможность оставить на кросс-сайт-сценариев атаки, если I вывести объект MailAddress позже в любом случае? Например через буквальное управление в WebForms:

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

Нужно ли дезинфицировать outpout хотя я убедился, что адрес является действительным адресом электронной почты путем разбора строки?

Из чего я могу собрать RFC для почтовых адресов, довольно сложно, поэтому я не уверен, что скрипты межсайтового сайта могут быть скрыты в почтовом адресе, который считается действительным .NET.

EDIT:
MSDN говорит, что > и < скобки допускаются в адрес электронной почты:

Параметр адрес может содержать отображаемое имя и связанный с ним адрес электронной почты, если вы заключите адрес в угловых скобках. Например: «Том Смит <tsmith@contoso.com>»

Таким образом, вопрос остается, если этого достаточно для атаки XSS и/или если MailMessage класс ничего не делает, чтобы избежать опасных частей.

Answer 1

Вообще говоря, вам не нужно будет проверять вывод позже. Тем не менее, я всегда рекомендую вам сделать это по следующим причинам:

1. Возможно, в вашем приложении есть отверстие, которое не подтверждает правильность ввода. Это может быть обнаружено злоумышленником и использовано для XSS. Это особенно возможно, когда многие приложения работают над этим приложением.
2. В базе данных могут храниться старые данные, которые были сохранены до внедрения/обновления вашего фильтра на входе. Это может содержать вредоносный код, который можно использовать для XSS.
3. Атакующие очень умны и обычно могут найти способ бить фильтр. Microsoft уделяет большое внимание предотвращению этого, но он никогда не будет совершенным. Это делает работу злоумышленников намного сложнее, если они сталкиваются и исходящий фильтр, а также входящий фильтр.

Я знаю, что боль постоянно фильтруется, но при этом очень важно. Стратегия защиты в глубину необходима в современном мире.

Edit:

Жаль, что я на самом деле не ответить на вторую часть вашего вопроса. Основываясь на документации, я не вижу впечатления, что API сосредоточен на дезинфекции, насколько это возможно при проверке правильного форматирования. Поэтому я не знаю, что безопасно полагаться на него в целях безопасности.

Однако написание собственного дезинфицирующего средства не так уж сложно, и вы можете немедленно его обновить, если обнаружите недостатки.Сначала запустите адрес через хороший RegEx-фильтр (см.: Regex Email validation), затем рекурсивно удалите каждый неличный символ в адрес электронной почты (они не должны проходить через этот момент, но сделать это для полноты и в случае, если вы хотите повторно использовать класс в другом месте), затем избегайте каждого символа с помощью значения HTML. Подчеркиваю рекурсивное применение фильтра, так как злоумышленники могут воспользоваться рекурсивным фильтром с вещами, как это:

<scr<script>ipt>

Обратите внимание, что нерекурсивная фильтр будет удалить среднее вхождение <script> и оставить внешнее возникновение в такте.

Answer 2

Нужно ли дезинфицировать outpout

Вы не 'Sanitize' выход, вы закодировать его. Каждая строка, которую вы выводите в HTML-документ, должна быть закодирована в HTML, поэтому, если в почтовом адресе был символ <, это не имело бы значения - в результате вы получили бы < в источнике HTML и отобразили бы правильно как буква < на странице.

Многие элементы управления ASP.NET автоматически обрабатывают HTML-экранирование для вас, но Literal по умолчанию не используется, поскольку он может использоваться для отображения разметки. Но если вы установили свойство Mode элемента управления Literal на Encode, тогда установка Text, как и у вас, отлично.

Вы должны всегда использовать безопасный вывод HTML-кода каждый раз, когда вы помещаете контент в HTML-страницу, независимо от того, думаете ли вы, что значения, которые вы используете, когда-либо будут содержать символ <. Это проблема разделения проблем: код вывода HTML знает все о форматировании HTML, но он не должен знать ничего о том, какие символы в порядке, в адресе электронной почты или другом поле приложения.

Оставив побег, поскольку вы считаете, что значение «безопасно» вводит неявное и хрупкое соединение между выходным каскадом и входным каскадом, что затрудняет проверку того, что код является безопасным и легким, чтобы сделать его небезопасным, когда вы вносить изменения.