Есть ли какая-либо уязвимость в теле письма? - PullRequest
Новая
       0

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

15 голосов
/ 17 марта 2011

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

Я использую приведенную ниже функцию для очистки моих данных, однако у меня есть несколько полей 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;
    }

}

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

Ответы [ 4 ]

11 голосов
/ 17 марта 2011

Существует возможная инъекция в основной текст, если вы говорите собственный SMTP с почтовым сервером.

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

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

here's a new body

, и SMTP-сервер мог бы пропустить второе сообщение.

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

4 голосов
/ 17 марта 2011

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

3 голосов
/ 26 июля 2011

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

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

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

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

haxor@attack.com%0AContent-Type:multipart/mixed;%20boundary=frog;%0A--frog%0AContent-Type:text/html%0A%0AMy%20Message.%0A--frog--

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

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

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

preg_replace( '/\s+/', "", $text )
0 голосов
/ 16 сентября 2014

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

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

...