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

verfaa

Профессор
Регистрация
29 Янв 2007
Сообщения
417
Реакции
49
Здравствуйте!
Просматривал код формы обратной связи на своём сайте и задался вопросом, а нужно ли обрабатывать данные пришедшие от пользователя, если они не пишутся в БД?

Вот например есть форма обратной связи, юзер пишет в неё свои данные, а 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 - в результате такой обработки сообщение вообще приходит пустым (письмо приходит, но без сообщения). А если её убрать, то сообщение доходит нормально. Почему так?
 
Ну наверное потому что БД не используется, зачем использовать mysql_real_escape_string ?
Есть же спец функции для проверки данных помню intval
 
пользовательские данные нужно обрабатывать всегда, для строк смотри в сторону addslashes и htmlentities
 
Надо обязательно почистить от html-тэгов тему и сообщение через Для просмотра ссылки Войди или Зарегистрируйся и Для просмотра ссылки Войди или Зарегистрируйся, иначе можно получить xss в свой личный ящик. Больше ничего делать с мессаджами не надо.
 
Выдрал из боевого скрипта.
Также, я использую прямую вставку значений из $_POST в mysql, поэтому защитился и от xss via mysql.
Переменная $db - это хэндлер соединения полученного в результате работы функции mysql_connect().
Далее также обращаешься к $_POST как и до вставки предложенных ниже строчек кода.
PHP:
        /* [!] Stop XSS */
        foreach ($_POST as $i => $val)
            $_POST[$i] = mysql_real_escape_string(htmlspecialchars($val), $db);
Для работы без БД хватило бы такого. Ни одна xss не пройдет!:
PHP:
        /* [!] Stop XSS */
        foreach ($_POST as $i => $val)
            $_POST[$i] = htmlspecialchars($val);
 
Ну еще бывают Для просмотра ссылки Войди или Зарегистрируйся и Для просмотра ссылки Войди или Зарегистрируйся, так что нелишним будет Для просмотра ссылки Войди или Зарегистрируйся и перед Htmlspecialchars делать Для просмотра ссылки Войди или Зарегистрируйся, потому как urldecode автоматически накладывается лишь на $_GET и $_REQUEST-запросы, $_POST надо обрабатывать самостоятельно.
 
mysql_real_escape_string очевидно из названия используется для работы с сервером mysql. для других целей - другие ф-ции. в вашем случае вполне подойдет htmlspecialchars
 
ИМХО, фильтровать цифровые данные из формы вообще смысла нет через функции достаточно умножить на один и всё. Например: $_POST["val"] = 123.5; $a = $_POST["val"]*1. И теперь переменную $a можно отравлять хоть в бд хоть на почту. А вообще отправляемые по почте данные не обязательно фильтровать по одной простой причине. Они в любом случае сохраняются в базу данных сервера почтовика, а там, естественно, стоит собственная фильтрация. Так что, любая обработка данных с целью защиты будет лишь дополнительной нагрузкой на собственный хостинг из-за применения лишних функций.
 
ИМХО, фильтровать цифровые данные из формы вообще смысла нет через функции достаточно умножить на один и всё. Например: $_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)"
 
В итоге поставил на сайт такую фильтрацию:
В самом начале файла 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
 
Назад
Сверху