Есть ли какая-либо инъекционная уязвимость в теле письма?

AFAIK существует только уязвимость в пределах HEADERS электронной почты при правильном использовании пользовательских данных?

Я использую следующую функцию для дезинфекции своих данных, однако у меня есть некоторые поля textarea на странице, и, следовательно, они могут содержать разрывы строк. Так было интересно, будут ли эти данные пользователя помещаться только в тело письма, может ли он не беспокоиться о том, чтобы быть подвергнутым санированию - за исключением того, что вы, конечно, лишаетесь html?

Вот функция:

function is_injected($str) {

    $injections = array('(\n+)',
    '(\r+)',
    '(\t+)',
    '(%0A+)',
    '(%0D+)',
    '(%08+)',
    '(%09+)'
    );

    $inject = join('|', $injections);
    $inject = "/$inject/i";

    if (preg_match($inject,$str)) {
        return true;
    } else {
        return false;
    }

}

В качестве побочного примечания, удивленный тем, что в настоящее время не существует метки для инъекций электронной почты/электронной почты.

Ответы

Ответ 1

Там возможно вложение в основной текст, если вы говорите собственный SMTP на почтовый сервер.

Один . сам по себе завершает текущее тело в SMTP, поэтому теоретически вы могли бы ввести пользовательский ввод следующим образом:

some body text
.
MAIL FROM: <...>
RCPT TO: <...>
DATA
Subject: here some spam

here a new body

и SMTP-сервер может разрешить второе сообщение.

Некоторые SMTP-серверы могут быть настроены таким образом, чтобы предотвратить это, не позволяя конвейерным командам SMTP (т.е. требовать, чтобы клиент прочитал ответ, прежде чем разрешить следующую команду).

Ответ 2

Если письмо электронной почты HTML, и особенно, если получатель будет просматривать его в веб-электронной почте (Hotmail, Gmail, Yahoo и т.д.) или почтовом клиенте, который поддерживает HTML-представления, тело, безусловно, вызывает беспокойство - XSS может произойти где угодно.

Ответ 3

Что-то, что может случиться, - это динамическое изменение MIME. Когда мы отправляем почту, мы обычно определяем Content-type в нашем script, например:

Content-type: text/html;charset=UTF-8

Улов - заголовок "Content-Type" может быть переопределен как multipart/mixed (или multipart/alternative или multipart/related), хотя он был ранее определен.

Пример. Представьте, что кто-то вводит это в поле тела электронной почты на своей странице контактов:

[email protected]%0AContent-Type:multipart/mixed;%20boundary=frog;%0A--frog%0AContent-Type:text/html%0A%0AMy%20Message.%0A--frog--

Что это будет делать - когда пользователь получит это сообщение, он увидит только спамерское сообщение (которое ограничено "--frog" ), в соответствии с mime multipart/mixed specification. Исходное сообщение "контакт", которое разработчик, возможно, жестко запрограммировано, также будет внутри письма, но не будет отображаться получателю.

Таким образом, спамеры могут отправлять спам из других доменов. Особенно если это что-то вроде: "отправьте его своему другу". форма.

Кроме того - при фильтрации заголовков я использую (немного короче, я думаю, чем то, что у вас есть):

preg_replace( '/\s+/', "", $text )

Ответ 4

Вы также можете вводить границу MIME в многостраничные сообщения, если граница не рандомизирована. Таким образом, вы можете вводить произвольный контент (например, приложения с вредоносным ПО).

Пример (не напрямую связанный с электронной почтой, но все еще): https://bugzilla.mozilla.org/show_bug.cgi?id=600464