POST requests are bypassing PHP checks

Question

I have a website with a contact form on PHP and a mail server. Email are sent with the help of PHP mail function like so

$name = cleanInput($_POST["name"]);
$e = $_POST["email"];
$email = filter_var(cleanInput($e), FILTER_SANITIZE_EMAIL);
if (strpos($name, "@") !== false) {
    $msg = 'Invalid name!';
    exit();
}
else if (strcmp($e, $email) !== 0 ||
    filter_var($email, FILTER_VALIDATE_EMAIL) === false ||
    !checkdnsrr(substr(strrchr($email, "@"), 1))) {
    $msg = 'Invalid email address!';
    exit();
}
else
{
    $message = nl2br(cleanInput($_POST['message']));

    $subject = 'Support request';
    $to = 'support@domain.com';
    $sender = 'webmaster@domain.com';
    $headers = array(
        'From' => $name . '<' . $email . '>',
        'MIME-Version' => '1.0',
        'Content-type' => 'text/html; charset=iso-8859-1'
    );
    $result = mail($to, $subject, $message, $headers, '-r' . $sender);
}

function cleanInput($data) {
    $data = trim($data);
    $data = stripslashes($data);
    $data = htmlspecialchars($data);
    return $data;
}

Recently I've been attacked by a spammer who is posting emails with From field value like this

check@mydomain.com, this@mydomain.com, link@mydomain.com, 
"US:http"@mydomain.com://www.somedomain.com/page <somename@mail.com>

So I prohibited the @ character in the name field like so

if (strpos($_POST["name"], "@") !== false)
    exit()

I've tried sending a POST request with a name like name@ from Postman and it was rejected successfully but am still getting the same spam emails.

Any ideas please how the spammer is bypassing the validation check?

Update

Here is an example of a spam email with error_log of the raw input fields https://pastebin.com/29ppLGuX

Update2

Thanks to @mti2935 it was figured out that there is no injection peformed. The spammer is just putting a simple line of text with a link into the name field and the MTA (Postfix) to some reason is appending the domain name to all words in that text. I've tried playing with the data and found out that it is the colon which causes all this trouble.

If $name="one two three" then the header of the received email looks good
From: one two three<name@mail.com>

If $name="one: two three" then
From: one@mydomain.com:two three <name@mail.com>

If $name="one: two: three" then
From: "one:two"@mydomain.com:three <name@mail.com>

I've tried converting the header array into a string prior to feeding it into the mail and got the same results.

Answer 1

The pastebin posts help a lot. First of all, we see from the unsanitized user inputs that you posted, that the spammer actually isn't entering inputs containing the @ character, after all, in 'name' field of your form. So that explains how it's getting past that check in your script.

It seems that what's happening is that your MTA is appending @yourdomain.com to these inputs, which is what MTA's default to doing when they encounter an email address without a domain.

So, that brings us to the question of why your MTA is treating these values, in the From: header, where you would normally have the sender's name, as email addresses instead of a name. I think it's related to the way that you are constructing the $headers array that you are passing as the fourth input to the mail() function. I think you need "\r\n" after each line in the headers, and the array needs to be converted to a string. There may be other things to look out for as well. See https://stackoverflow.com/questions/27478307/having-issue-on-setting-array-of-headers-in-php-mail-function for more info on how to get this right.

Update: It turns out that in addition to the issues described above, problems were being caused if the user included a colon in the sender's name field when filling out the form, as this character later manifested itself in the From: header of the message. See comments below by yaugenka for more info and for the solution.

Answer 2

You're combining both $name and $email in the from header, but according to your post you only filter $name. The attacker (automated spam bot) is probably injecting into the $email variable.

Answer 3

Out of the box, PHP provides direct access to various interfaces without a framework of checks. Sometimes its good to restrict people to operating within a strictly controlled sandbox with strict rules about what goes in and comes out. PHP is not such an environment.

Based on the code you have shown us, it would be trivial to exploit this. If you allow any user contributed text within email headers then an attacker can control the recipient, and several of the sender addresses. Restricting field length to 70 characters and disallowing '<', '>', ',', \r and \n from any field which might end up in an SMTP header would help, but still fall a long way short of a robust solution.

That you don't know how they did this also highlights that your code has insufficient logging.