Как стать автором
Обновить

Комментарии 11

Если вы корректно валидируете email на этапе приёма его от пользователя, то эта уязвимость вас скорее всего и не коснётся.

Строго говоря, "attacker\" -oQ/tmp/ -X/var/www/cache/phpcode.php some"@email.com — это валидный e-mail по RFC 2822. В local-part разрешается quoted-string.

Да, это так. В реальной повседневной жизни этот RFC интерпретируется всеми по-своему, что приводит к разным реализациям валидаторов.


Учитывая, что пользователей с вычурным адресом по RFC ничтожно мало, нам проще пожертвовать ими в пользу безопасности.

Абсолютно согласен. Я к тому, что у тех, кто именно корректно (по rfc) валидирует, может из этого утверждения создаться ложное ощущение безопасности. Подозреваю, что с разработчиками phpmailer и swiftmailer именно так и произошло — там-то как раз по rfc валидация внутри (по крайнее мере в swiftmailer — точно).

А если следовать хорошему тону то правильней всё же будет не жертвовать пользователями, а правильно экранировать параметры командной строки.
А это уже перекладывается ответственность на нескольких разработчиков данного пакета, а не на десятки разработчиков разнокалиберных приложений.

Если у вас есть публичные проекты, в которых разрешены email'ы по всем канонам RFC — поделитесь, пожалуйста, количеством пользователей, адреса которых не проходят валидацию по регулярке из EmailValidator в Yii.

А есть почтовый сервис, где можно зарегистрировать такой email?
Symfony валидатор тоже спокойно пропускает конструкцию и считает ее валидной, спасает то что их валидатор емейлов довольно кривоват, поэтому так или иначе использую свой, который удаляет спецсимволы)

Суть уязвимости, кстати, намного интереснее.


Первой попыткой фикса в PhpMailer-е было добавление escapeshellarg(), а в SwiftMailer-е так уже и было сделано.


Нюанс в том, что mail() внутри выполняет escapeshellcmd(), в итоге "наложения" результатов этих функций можно получить возможность выполнить произвольный код — пример такго значения $from можно увидеть в добавленном в SwiftMailer юнит-тесте.


В таких условиях написать корректную реализацию экранирования для всевозможных шеллов довольно сложно, так что в SwiftMailer сдались и добавили проверку по белому списку символов (непонятно только, почему не регуляркой). Так что необычные, но валидные емейлы теперь тоже не пройдут.

Вот стандартные Yii 1 регулярки в CEmailValidator, который само-собой разумеется все используют для валидации email полей и я что-то не заметил чтоб они что-то пропускали лишнее:

pattern

fullPattern

Так в чем проблема тогда? Что-то вроде: Кто не валидирует поля у себя в проекте сам себе злобный буратино?

Типа того.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации