Is there any injection vulnerability in the body of an email?

Question

AFAIK there is only a vulnerability within the HEADERS of an email when using user data correct?

I am using the below function to sanitize my data, however I have some textarea fields on the page & hence these may contain linebreaks.. so was wondering if that user data is only going to be put in the body of the email, can it not bother with being sanitized - apart from stripping html of course?

Here is the function:

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;
    }

}

As a side note, surprised there wasn't currently a tag for mail-injection / email-injection.

Are you displaying data from the email on the page, or making a form allowing to send one? — Fluffy, Mar 17 '11 at 16:19
I think you can base64 encode the email body (via MIME) to avoid any sort of injection attack. — jchook, Jun 29 '18 at 22:29

Alnitak · Accepted Answer · 2016-08-04T16:35:14.197

11

There's a possible injection in the body text if you're speaking native SMTP to the mail server.

A single . on its own terminates the current body in SMTP, so in theory you could have user supplied input like this:

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

here's a new body

and the SMTP server might allow the second message through.

Some SMTP servers can be configured to prevent this by not allowing SMTP commands to be pipelined (i.e. requiring the client to read the response before permitting the next command).

edited Aug 04 '16 at 16:35

answered Mar 17 '11 at 16:33

Alnitak

334,560
70
407
495

So what should I be checking for? a line with a single "." on it? – Brett Mar 17 '11 at 16:47
1

@Brett - Yes. If found, ISTR that the convention is to replace it with two dots. – Alnitak Mar 17 '11 at 17:51
See also: http://software-security.sans.org/blog/2011/01/14/spot-vuln-sleep-smtp-command-injection or http://projects.webappsec.org/w/page/13246948/Mail%20Command%20Injection – Boy Baukema Oct 03 '13 at 15:16
What you alluded to is dot-stuffing and handling it seems to be the responsibility of the underlying smtp clients and servers (you did mention "if you are speaking native SMTP"). Is it typical to speak native SMTP though? – Kevin Lee Aug 04 '16 at 16:23
@kevinze I've seen plenty of libraries that do speak SMTP directly to a mail server. Even if you directly invoke /usr/sbin/sendmail and send it stuff on stdio you still need to be careful. – Alnitak Aug 04 '16 at 16:25
@Alnitak Oh I see. So if we are using a particular library that speaks SMTP directly, we have to check whether the underlying library is doing dot-stuffing. If it is not, then we should do it. – Kevin Lee Aug 04 '16 at 16:50
1

The simple way I can think of to check for the vulnerability is to craft the email with the termination sequence (single dot on a line) in the center of the email body and see if the recipient gets it as a whole or only half the email body. E.g. hello\r\n.\r\nworld – Kevin Lee Aug 04 '16 at 17:03

score 4 · Answer 2 · answered Mar 17 '11 at 16:28

4

If the email's an HTML mail, and particularly if the receiver's going to be viewing it in a web-based email (Hotmail, Gmail, Yahoo, etc...) or an email client that supports HTML views, then injection into the body is definitely a concern - XSS can happen anywhere.

answered Mar 17 '11 at 16:28

Marc B

356,200
43
426
500

Most clients will not allow things like javascript/flash/css to be included, so as far as displaying emails in remote clients is concerned, there is no threat. – Dunhamzzz Mar 17 '11 at 16:30
Most mail clients claim they won't allow it - but do you really want to depend on Hotmail/Yahoo/Gmail's group competence to catch every possible way of including hostile content? There's always another hole. – Marc B Mar 17 '11 at 16:32
So what do you suggest to counter this? – Brett Mar 17 '11 at 16:46
2

Doing the stripping before the mail's generated. sanitize any user-provided text/html as you would if you were putting it into a regular web page. Blindly inserting it into the body and assuming the remote mail server and/or client will filter it for you is a bad way to go. – Marc B Mar 17 '11 at 17:14

ThatGuy · Answer 3 · 2011-07-25T20:20:13.117

Something that might also happen is dynamic MIME change. When we send mail we usually define Content-type in our script, example:

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

The catch is - "Content-Type" header can be re-defined as multipart/mixed (or multipart/alternative or multipart/related), even though it was previosly defined.

Example - imagine that someone types this into email body field on your contact page:

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

What this will do - when user receives this message, he'll only see spammer's message ( the one delimited by "--frog"), as per mime multipart/mixed specification. Original "contact" message that developer perhaps hardcoded - will be inside of the email as well, but will not be displayed to the recipient.

This way spammers can send spam from other people's domains. Especially if it's some sort of: "send it to your friend." form.

Also - when filtering mail headers, I use (a bit shorter I guess than what you have there):

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

score 0 · Answer 4 · answered Sep 16 '14 at 16:57

You can also inject MIME boundary into multipart messages, if the boundary is not randomized. That way you can inject arbitrary content (e.g. attachements with malware).

Example (not directly email-related but still): https://bugzilla.mozilla.org/show_bug.cgi?id=600464

Is there any injection vulnerability in the body of an email?

4 Answers4

Linked