There aren't any security holes in e-mailing a print_r of a POST, are there?

Question

This may be a bit of a noob question, sorry.

There aren't any security holes in this kind of code are there? I've been using it everywhere but wanted to make sure I'm not leaving vulnerabilities around.

$body = print_r($_POST, true);
mail($to, $subject, $body, $headers, "-f $from_address");

Answer 1

No, it's not safe.

But you'll probably get away with it as you need other badly set up systems to let a hack through.

Details

The "normal" security issues with email are well known: always vet anything going into the header to prevent header injection; most simply by removing new line characters (or rejecting if any are sent: means someone's hacking/testing). This isn't a concern you've raised.

However there have been hacks in the past with SMTP injection: you can terminate the SMTP message and start a new one with judicious use of a full stop (periods) and %0D %0A (CRLF) and MAIL TO: commands. An SMTP message ends with a full stop on its own: rather simple to add. Look here: http://projects.webappsec.org/w/page/13246948/Mail%20Command%20Injection and https://www.owasp.org/index.php/Testing_for_IMAP/SMTP_Injection_(OTG-INPVAL-012)

There are defenses against this: e.g. SMTP servers can be configured to not allow chaining and will treat all as one. So HOPEFULLY you are safe. But to be sure, see if you can strip out . on its own line, and convert %0D %0A (CRLF) into %0A to help remove the risk (but check that last one: your results may vary and it may not be suitable).

For completeness, there are also XSS injection possibilities (i.e. including links) but that's harmless unless you follow a link. Web clients may automatically convert plain text links into clickable links: I can't think how this can be exploited but there's always a way: so vet for links if you're concerned.

Adding an attachment to the existing email (as suggested in one answer) is only possible if you are sending a multi-part email and the user/hacker knows the border separator; so randomly generate border separators or send plain text (not multi-part) to avoid this.

There's potentially the ability to run Javascript if you have exactly the right circumstances. As with attachments, if you're sending a multi-part message, you can create an HTML part with the border separators; so randomly change your border separator and vet for HTML tags. If you're using a web client that allows javascript sent as plain text to run, then you need a new web client (I really doubt there is one).

Those are what I can think of quickly.

Simplest solution: use a library. Well known libraries are designed to avoid these issues. You might also get more advice by checking the source code and how they cope. Swiftmailer is my current library of choice.

Answer 2

You should take good care of $headers and $from_address as those can easily be exploited for Email Injection attacks.

Furthermore, if you print_r a variable that contains HTML, you'll send a string with HTML via email. Although the email may be sent as plain text, it's still up to the email client how those strings are interpreted and displayed. As such, you cannot simply assume that there is no security hole.

Answer 3

As already shown in the comments, you can never trust any user input. Some possibilities of exploits could be:

• Embed a link to a phishing site
• Add an attachment to the e-mail with a Trojan
• Create a 1GB large e-mail