what are the security issues about mail.body? i want to know when i want to send an email with a form using php, except the email address that we have to validate that, is there any other security issue about sending emails?
for example, which characters can't be used in the body? what about the header or subject? is there any problem with using new line in the body? is a black list applicable here? also, is it possible that with using some tags like <script> in the body, sending email be failed?
all papers that i have read, only say about validating email address and not more!
im researching about security and i want to know all issues about email security in PHP.
Plain text is basically safe. HTML or (shudder) Flash or PDF has the inherent security problems of those formats. In theory, all mail should be 7bit, but MIME changed that so that internaltional information can be handled. The Wikipedia MIME article is probably a good place to start. http://en.wikipedia.org/wiki/MIME
Related
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");
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.
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.
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
I have a form on a website where the user types a name into the input field and a message into textarea. This message will be sent to the backend and via php mail() - mailed to a specific recipient from my database. Now I'm not sure what sort of sanitisation I should perform before the message is sent. What's the best practice with plain PHP or something like PHPPurifier?
I googled and googled but all I get is how to sanitise email addresses, nothing about the message content and if it's necessary at all.
EDIT: I'm not familiar with what damage can be possibly done with some sort of malicious email body. Stripping all the HTML seems most obvious but anything else? I just really need line breaks mostly I think. What's the common practice here?
I'm not after sanitizing the email address itself, this will come from database.
if(filter_var($email, FILTER_VALIDATE_EMAIL)){
//all good
}
ref: Validate filters
its not fool proof, but probably good enough for most
I understand there are php IMAP functions to extract certain elements from an email stored in a mailbox. What I am trying to discover is whether this can translate to emails piped to a script.
The scripts that I have looked at for extracting the body and attachments are fairly inflexible and bulky. I sent my pipe script a variety of different email formats and it saved them in vastly different ways which makes me wary of starting to write a script myself.
Also as some of the emails sent from my work address attach a signature. Does anyone have any ideas how to combat this. I have a bunch of rather daft people who won't even understand the term 'don't add a signature when sending this email', or 'send in plain text only'.
AFAIK, the format for storing messages is not defined by any RFC however deliver, procmail and .forward all rely on the the headers being seperated from the body by a blank line.
I am displaying the email addresses stored in the database on a page using PHP.
The email address on a page is displayed as below:
Email: test#example.com
Now the email address shown on a page should use JS spam protection to hide it from spam bots.
Try an email encoder, or implement one in your script.
you can try to use image (with php-gd lib) write on a image then show this. (like facebook)
Here are some good resources to look at:
Hiding Email from Spam Bots
Displaying Emails for Users, But not Spambots.
Making Email Addresses Safe from Bots
You could probably find more using a Google Search of StackOverflow.com
Oh, and there are ones asking if you 'should' do it:
Does Hiding Emails really make it harder?
Do You Hide Email from Spam Bots on Websites
I'd argue that you're better off not bothering; client-side spam filters are pretty good these days, and by jumping through hoops youjust make thing harder for humans.
That said, the best way is to convert it to whatever kind of format you want, whether it's an image or a simple string substitution:
joe#domain.com -> joeATdomainDOTcom
and then write the address out marked up with some kind of class identifier:
<a href="mailto:joeATdomainDOTcom" class="Email">
<!-- image or link text here -->
</a>
Then use Javascript to decode all the email links and re-write the href attribute to the real address. Most spiders crawling for email addresses won't execute Javascript, so the encoded semi-useless address is all they'll see.
Users with JS enabled will get more or less expected functionality (clickable mailto links) while users without JS will at least get human-readable addresses.
The worst thing you can do is write the unencoded addresses out, and trust some Javascript to hide them.
PHPEnkoder (a port of Hivelogic's The Enkoder)
"Enkoder, which works by randomly encoding a piece of text and sending to the browser self-evaluating Javascript that will generate the original text. This works in two ways: first, a bot must first have a fairly complete Javascript implementation; second, the decoding process can be made arbitrarily computationally intensive."
It's BSD-licensed.
Try http://recaptcha.net/learnmore.html It can protect email addresses with a captcha..never tried it though, but i uses reCaptcha for a login form and it was easy to work with.
Displaying them as pictures is one option. Also requiring the user to pass CAPTCHA test before seeing the e-mail address works too. Combine those two and spam bots will likely never get the e-mail addresses.
I am looking for a solution that will enable me to connect to a mailbox, obtain an email, apply specific modifications to the email body (for example, change the content), and then forward the newly modified email to a new email address.
The trick is that such modification must not destroy the format and headers of the original email and I must not lose any attachments that were in the original email.
The sort of manipulation that will be performed will need to be done by an external process that knows the logic of my application.
The solution I am looking for can be an external software that can invoke some API for processing the content of the emails, or even API by itself that my code will invoke.
Our solution is currently based on PHP, but any other solution is also acceptable.
I started working with the Zend Mail library but I am running into problem having to understand the inner-workings of email formats. I wouldn't want to start messing around with the mime objects in the email format. I only want to alter the textual content of the message and keep the rest untouched.
http://php.net/manual/en/book.imap.php - functions that let you manipulate email systems.
What mail server are you using? In qmail its easy to process any incomming email. You can put any script in any language to process the lines of the email.
If you have IMAP access to your server you can use the php IMAP lib. http://www.php.net/manual/en/book.imap.php
I wrote a library as part of a larger open source app that may help you a bit. Its an object orientated wrapper around the PHP imap functions and can be found at google code.
Unfortunately this doesn't do exactly what you want. What in the message are you trying to change? I may be possible to just grab a raw version and specifically search out what you want to change, ignoring the whole mimetype processing altogether, and then just send the whole message along again.
Resending the email is simple enough, and this (small tutorial)* on sending email with attachments can refresh you on the basics (although most of what is in there you can skip as the attachments and mimetypes will already be built).
* I can't post the link because my reputation isn't high enough for two links in a single post, so I'll add it in a comment.