The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Уязвимости в PHP и PHPMailer"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Уязвимости в PHP и PHPMailer"  +/
Сообщение от opennews (ok), 08-Дек-18, 11:09 
В опубликованных (http://php.net/archive/2018.php) на днях корректирующих обновлениях PHP  5.6.39, 7.0.33, 7.1.25 и 7.2.13 устранена (http://php.net/ChangeLog-7.php#7.0.33) неприятная уязвимость (http://bugs.php.net/77153) (CVE-2018-19518 (https://security-tracker.debian.org/tracker/CVE-2018-19518)) в штатном PHP-дополнении IMAP, выявленная (https://antichat.com/threads/463395/#post-4254681) ещё в октябре. Уязвимость позволяет атаковать web-приложения для работы с электронной почтой или обойти системные ограничения доступа к функциям, выставляемые через опцию disable_functions  в php.ini.

В случае запрета вызовов, подобных exec, system, shell_exec и passthru, уязвимость даёт возможность выполнить произвольный shell-код, в случае когда злоумышленники могут загрузить свой PHP-код на сервер (например, для продолжения атаки после эксплуатации уязвимостей (https://www.opennet.ru/opennews/art.shtml?num=49641) в плагинах для загрузки пользовательских файлов). Уязвимость также может применяться для атаки на webmail-клиенты, позволяющие установить произвольное имя imap-сервера и передающих его в вызов imap_open без дополительной проверки.


Суть проблемы в том, что функция imap_open, через которую осуществляется открытие соединения с IMAP-сервером, позволяет указать дополнительные параметры для обращения к почтовому ящику по сети. Возможно обращение к почтовому ящику на удалённом хосте не только с использованием протокола IMAP, но и по SSH (вызывается команда rsh, но в большинстве дистрибутивов она перенаправлена на ssh), которому можно передать дополнительные параметры, в том числе через указание опции "-oProxyCommand=" можно определить команду для запуска прокси. Вместо прокси можно указать любой код, который будет выполнен при вызове функции imap_open. Для блокирования уязвимости в новых выпусках по умолчанию отключено (https://github.com/php/php-src/commit/3a144d3f7f6bad308e2bf1...) обращение imap_open по rsh/ssh (imap.enable_insecure_rsh=false).


Концептуальный прототип эксплоита (https://github.com/Bo0oM/PHP_imap_open_exploit/blob/master/e...):


   $server = "x -oProxyCommand=echo\tZWNobyAnMTIzNDU2Nzg5MCc+L3RtcC90ZXN0MDAwMQo=|base64\t-d|sh}";
   imap_open('{'.$server.':143/imap}INBOX', '', '') or die("\n\nError: ".imap_last_error());


Кроме того, раскрыты сведения об уязвимости (https://www.debian.org/security/2018/dsa-4351) (CVE-2018-19296 (https://security-tracker.debian.org/tracker/CVE-2018-19296)) в PHPMailer (https://github.com/PHPMailer/PHPMailer/), популярной библиотеке для организации отправки электронный писем из приложений на языке PHP, число пользователей которой оценивается в 9 миллионов (используется в WordPress, Drupal, 1CRM, SugarCRM, Yii и Joomla). Уязвимость позволяет организовать выполнение кода через подстановку ссылки на phar-файл в составе пути, например, при отправке письма с вложением. Устраняющее проблему исправление (https://github.com/PHPMailer/PHPMailer/commit/f1231a9771505f...) включено в состав релиза PHPMailer 6.0.6.


Полученный путь проверяется при помощи функции file_exists(), которая автоматически выполняет десериализацию метаданных из файлов Phar (PHP Archive), что позволяет применить технику атаки "Phar deserialization (https://blog.ripstech.com/2018/new-php-exploitation-technique/)". Организовав загрузку специально оформленного Phar-файла под видом вложения, злоумышленник может добиться выполнения своего кода на сервере. Так как функция file_exists() определяет MIME-тип по содержимому, а не по расширению, возможна передача phar-файла под видом картинки (напирмер, phar-файл будет разобран, если его передать как  evil.jpg). Похожая уязвимость недавно была выявлена (https://www.opennet.ru/opennews/art.shtml?num=49641) в  phpBB.

URL: https://www.openwall.com/lists/oss-security/2018/12/05/2
Новость: https://www.opennet.ru/opennews/art.shtml?num=49746

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Уязвимости в PHP и PHPMailer"  +1 +/
Сообщение от Blind Vic (ok), 08-Дек-18, 11:09 
>  устранена неприятная уязвимость

Бывают приятные уязвимости?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Уязвимости в PHP и PHPMailer"  +16 +/
Сообщение от commiethebeastie (ok), 08-Дек-18, 11:31 
В айфонах которые.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 08-Дек-18, 11:11 
то-то я удивлялся, чего это php_imap после установки не включается автоматически, как это происходит с любым нормальным модулем. Видимо, кто-то когда-то заглядывал в его прекрасный код и сделал выводы...

что же, ждем новую серию ssh'ных червяков - теперь через PHPmailer и imap-через-ssh впридачу... время безумных гуанокодеров :-(

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Уязвимости в PHP и PHPMailer"  +1 +/
Сообщение от annual slayer (?), 08-Дек-18, 11:28 
зато можно сделать бложик с комментиками!
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

49. "Уязвимости в PHP и PHPMailer"  +2 +/
Сообщение от Онаним (?), 09-Дек-18, 11:26 
Ну согласись, передавать юзеринпут в параметры модуля имап (да и в любые другие вызовы) без предварительной валидации - это идиотизм. Так можно и в GD "уязвимость" найти, если туда параметры $widht / $height для скейлинга без проверок передавать. Пара десятков запросов на 19200 x 10800 - и сервер счастлив.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

55. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 13:15 
> Пара десятков запросов на 19200 x 10800 - и сервер счастлив.

воркер просто обломится об out of memory, и ничего интересного не произойдет.

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

А у тебя в коде невидимый и нерегулируемый лимит непонятно для чего.

А вот запуск ssh вместо imap - это как-то, на мой взгляд, за гранью добра и зла. Но вполне в духе авторов пехепе.

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

61. "Уязвимости в PHP и PHPMailer"  +2 +/
Сообщение от Онаним (?), 09-Дек-18, 13:36 
1. Зависит от контекста. Окей, подбираем значения под размер памяти, и дальше уже обламывается в OOM весь контекст. Плюс ещё ресурсы CPU на обсчёт этого дела нужны.

Согласись, допустим в генераторе thumbnails логично проверить размерчик, который хочет пользователь, не?

2. Что значит невидимый и нерегулируемый? Добавляем tunables в конфигурацию, дальше желающие пострелять себе в ногу thumbnail'ами на 19200x10800 смогут легко это сделать. Но это будет их личная проблема.

3. Запуск ssh из imap - это к аффтарам libc-client, пхп тут не особо при чём.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

65. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 16:59 
> Согласись, допустим в генераторе thumbnails логично проверить размерчик, который хочет
> пользователь, не?

ну хз - вот были генераторы во времена дисплеев 800x600 - генерили превьюшки с почтовую марку. Сейчас их приходится стирать к хренам, и генерить новые, потому что 800x600 это уже размер превьюшки, а не картинки.
А в эпоху 5" дисплеев 4k  я вот хз какого размера должны быть тамбнейлы - очень может быть что и 4k много не будет.

> Добавляем tunables в конфигурацию

сколько tunables мы туда добавим и какого она в итоге будет размера, если на всяк чих наздравствоваться?
Я еще могу понять, если размер превьюшки выбирается слайдером - воткнуть проверку соответствия диапазону слайдера присылаемых значений (если нет - нас пытаются поломать).

но в целом это тоже достаточно бессмысленные телодвижения, когда нельзя четко определить, какой user input заведомо невалиден, а какой нет, и приходится на ровном месте рисовать новые и новые проверки.

пока программка простенькая - это будет прокатывать (если спрашивать отдельным диалогом для того же imap host/port/user/password - проверить просто. Если парсить урлы imap:// генеримые кем-то третьим - то, внезапно, все становится непонятно.)

и да, отдельный вопрос - сколько в мире настоящих серверов imap, реально требующих ssh для работы с ними и кто их странные пользователи?

по-моему, очевидно - overengineering - зло.

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

62. "Уязвимости в PHP и PHPMailer"  +3 +/
Сообщение от Онаним (?), 09-Дек-18, 13:39 
Суть в том, что пых, как и сишечка, кодера от выстрела себе в ногу не защищает никак. Совсем-совсем.

И списывать на язык собственно нежелание валидировать user input (что есть нарушение одного из основных правил безопасности при программировании, тащем-то) смысла нет.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

4. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (4), 08-Дек-18, 11:29 
Пора на WT?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Уязвимости в PHP и PHPMailer"  +1 +/
Сообщение от Аноним (7), 08-Дек-18, 12:29 
Дыра с phar так и осталась нерешенной. Suhosin вам не поможет, только смена языка разработки.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 08-Дек-18, 12:50 
фффпринципе, полагаю, там хватит однострочного патча в легко находимом месте кода.
Но вот сколько и чего при этом поломается...

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

32. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (32), 08-Дек-18, 19:28 
Нахрен он его вообще распаковывает? Чтобы проверить файлы "унутре"? file_exists должен проверять, а файл-то exists? При phar'е тупо ругаться на гавно. Но это не про php. У нас функция должна всё за всех и принимать параметры в любом порядке! Один url_fopen чего стоит.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

51. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 12:52 
> Нахрен он его вообще распаковывает? Чтобы проверить файлы "унутре"?

да.
во всяком случае семантика такая. А что это нахрен никому не надо - авторов не беспокоило.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

47. "Уязвимости в PHP и PHPMailer"  –1 +/
Сообщение от Онаним (?), 09-Дек-18, 11:22 
Вы передаёте поданное пользователем имя файла ("phar://...") в файловые операции над локальной ФС?
У меня для вас плохие новости.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

52. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 13:01 
да, передаем, потому что этот файл создан пользователем и имеет придуманное этим пользователем имя - идеи хранить в базе данных то, для чего изначально предназначена fs - засуньте себе туда, откуда у вас вывалилась прекрасная идея вместо файлов использовать всякую галиматью в любой функции, работающей с файлами, "зато как в винде!" (хотя винда хотя бы код не *исполняет* - это ваше уникальное достижение).

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

А теперь расскажите, зачем вы вообще интерпретируете как phar (то же касается умничек из проекта ghostscript) то что не оканчивается на .phar, вместо возврата ошибки, и в каком реальном случае может понадобиться такая е..нина, кроме писания эксплойтов?

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

56. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Онаним (?), 09-Дек-18, 13:18 
Не надо хранить в базе то, что надо хранить в ФС. Но вот 100% валидации пользовательских данных никто не отменял.

Если не хочется валидировать - значит не надо использовать: загруженному файлу присвоили внутренний ID, а оригинальное имя файла записали в БД или файл метаданных.

Если же валидировать - валидировать полностью. Передали что-то, отличное от валидного имени файла - в баню. А то вам так и ../../../config/database_password.php для чтения передадут, и вы это благополучно сжуёте.

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

70. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 18:15 
> Передали что-то, отличное от валидного имени файла

anon[1025] ~>  mkdir phar:
anon[1026] ~> touch phar:/test.jpg
anon[1027] ~> ls -la phar://test.jpg
-rw-r--r-- 1 anon users 0 Dec  9 18:07 phar://test.jpg
что невалидного в данном имени файла?

(сейчас начнется верчение ужом и классификация файлов на правильные и неправильные)

> А то вам так и ../../../config/database_password.php для чтения передадут, и вы это
> благополучно сжуёте.

мы это можем (в отличие от вышеприведенного) проверить, причем двумя разными способами - честно распарсить путь (возможно - валидный, потому что все это происходит в ../../../../user-uploads/ !) или просто решить что parent-ссылки у нас запрещены - правильнее, безусловно, первое.

ну, разумеется, правильнее - в языке, где проверка существования файла не ведет к выполнению кода, а не в php.

потому что я не уверен что и нормализация перед проверкой (которая теоретически лечит первый пример) достаточна сегодня и всегда останется достаточной в свете новых макачьих изобретений.

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

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

71. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Онаним (?), 09-Дек-18, 18:43 
В данном случае невалиден мозг, разрешивший передавать аж целые каталоги в юзеринпуте.
Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

74. "Уязвимости в PHP и PHPMailer"  +1 +/
Сообщение от пох (?), 09-Дек-18, 18:46 
понятно все с вашими мозгами, гражданин пхп-обезьян.

юзер не должен передавать какие-то каталоги, пусть валит все в кучку, зато мы, виликие, безопасТно можем вместо путей использовать исполняемый код в файловом апи.

в общем, если до истории с phar у меня были какие-то сомнения что php не виноват, дело в разработчиках, то теперь я убежден что наоборот, разработчики и их любимая среда идеально соответствуют друг-другу.

Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

57. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Онаним (?), 09-Дек-18, 13:21 
Это может понадобиться, когда ты используешь phar:// для доступа к собранным в один пакет данным приложения.  PHP, внезапно, это не только фронтендики для интернетико-магазинчиков.

То же, что кто-то вдруг в наличии символа / в переданном ЮЗЕРОМ _имени файла_ проблемы не видит - это строго его ментальные проблемы.

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

66. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 17:04 
> Это может понадобиться, когда ты используешь phar:// для доступа к собранным в один пакет
> данным приложения.

и зачем оно вдруг имеет расширение .jpg?
Отдельный вопрос - зачем вы используете апи для работы с файловой системой для работы с _исполняемым_кодом_? (ладно бы phar был просто архивом, это было бы относительно безобидной фичей языка)

> То же, что кто-то вдруг в наличии символа / в переданном ЮЗЕРОМ

юзер его не передает  - юзер выбирает путь, в удобной менюшечке интуитивно приятного интерфейса, чтобы не валить все в одну помойку. В ваш код, разумеется, приедет имя файла с путем.
Не вижу ничего неправильного в этом.

Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

72. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Онаним (?), 09-Дек-18, 18:44 
Будем проверять все конкретные расширения? Сегодня жпг, завтра гиф, послезавтра мп10?
Не проще сразу изолироваться от возможных ошибок, храня юзерские имена отдельно от контента? А то юзер может захотеть ../../../etc/passwd похранить нечаянно, тоже будем?
Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

76. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 18:49 
> Будем проверять все конкретные расширения?

да. Очевидно, что если файл имеет расширение .jpeg, а внутри postscript - это хуже чем ошибка, это преступление.

То есть это явная и недвусмысленная попытка взломать ваш чудо-сайтик с вероятностью 99%, и еще один оставим таки уникально-жопорукому юзеру, которуму лучше заблокировать акаунт до выяснения, чем подвергать риску остальных.

И тем более надо отказываться выполнять исполняемый код, не имеющий правильного оформления в виде имени файла.

Но нет, вы будете накручивать проверки на проверки, а потом опа, магия - .jpg исполняется тремя разными способами, спешите видеть чудо!

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

84. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 19:31 
> А то юзер может захотеть ../../../etc/passwd похранить нечаянно, тоже будем?

а, кстати, почему нет, может он бэкап своего контейнера выложил? Разумеется, ниже ../../../backup/

запретим пользоваться относительными путями?

или все же может перестанем десериализовывать .jpeg при проверке его существования?

с моей точки зрения выбор между этими двумя вариантами очевиден.

с точки зрения разработчиков языка - тоже, но почему-то это разные выборы.

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

98. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Онаним (?), 11-Дек-18, 09:27 
В имени файла, переданном пользователем типовому публичному web-приложению, вообще не может существовать никаких путей. Хочешь выкладывать бэкап контейнера - выкладывай в tar.

Если приложение не носит характер публичного web-приложения, там уже можно делать что угодно, понимая последствия.

Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

73. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Онаним (?), 09-Дек-18, 18:46 
> юзер его не передает  - юзер выбирает путь, в удобной менюшечке интуитивно приятного интерфейса

И вот тут ты очень правильно попал: в этом случае выбранное валидируется согласно этой самой менюшечке при любом доступе. Не просто берём переданный с потолка путь и открываем, а сравниваем на предмет присутствия в этой менюшечке. Не присутствует - в баню.

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

78. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 18:54 
> а сравниваем на предмет присутствия в этой менюшечке

функцией file_exists, да?

(менюшечка была в форме, сейчас нам POST пришел - с параметрами заполненными с этой менюшечки...или не этой...хехе. Зашифруем всю форму и отправим вместе с постом, на предмет детальной проверки (еще pgp подписать не забудьте), так мыслит типичный *хороший* php-кодер?)

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

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

88. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Онаним (?), 09-Дек-18, 20:15 
Менюшечка из libastral.so? Если нет, то описатель этой менюшечки есть сервер-сайд, не надо ничего лишнего отправлять.
Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

91. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 23:00 
> Если нет, то описатель этой менюшечки есть сервер-сайд, не надо ничего лишнего отправлять.

ну ок, храни ее вечно - пока пользователь то ли нажмет submit, то ли передумает, то ли пойдет пообедать.

в принципе, когда траффик был дорогой, мы так и делали.

но вообще-то опять же - хранить то что и так хранится в виде файловой системы только ради того чтоб ненароком не выполнить код при попытке проверить существование...

нет, ты правда считаешь ЭТО хорошим языком?
  

Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

92. "Уязвимости в PHP и PHPMailer"  +1 +/
Сообщение от Онаним (?), 10-Дек-18, 09:09 
Да, правда. PHP - очень удачная обёртка в виде небольшого рантайма с динамической сборкой поверх тонны сишных библиотек. Удачнее не получилось, не получалось и не получается ни у кого уже лет 30.
Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

8. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (8), 08-Дек-18, 12:35 
>However, the unserialize is triggered for the phar:// wrapper in any file operation.

Это - не уязвимость. Это - бекдор.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (8), 08-Дек-18, 12:47 
Извиняюсь, невнимательно прочитал. Это не уязвимость и не бэкдор. Это странный дизайн функций, задействующий фильтры через модификацию строк вместо ООП.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

41. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (41), 09-Дек-18, 04:43 
Функция может проверить содержится до файл в архиве или на фтп, что удобно
Несомненно эта возможность является бэкдором
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

14. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (7), 08-Дек-18, 13:08 
Там ведь можно еще заюзать udp:// tcp:// stream:// и tls:// верно?
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

48. "Уязвимости в PHP и PHPMailer"  –1 +/
Сообщение от Онаним (?), 09-Дек-18, 11:23 
Это не бэкдор, это очень удобный механизм. К сожалению, в кривых руках, привыкших делать file_exists($_GET['file']) или $db->query("SELECT * FROM xyz WHERE abc = '{$_GET['abc']}'") он становится уязвимостью...
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

86. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (86), 09-Дек-18, 20:08 
Ага. я сам язык ниучём неуноват.
Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

87. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Онаним (?), 09-Дек-18, 20:15 
А никто вам защиту от выстрела в ногу не гарантировал )
Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

89. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (86), 09-Дек-18, 22:15 
Слово "гарантировал" в разработке ПО не используется. Поэтому аргумент не засчитывается.

Разворачивать не стану, всё равно мой пост по политическим причинам сотрут и вы его не увидите.

Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

15. "Уязвимости в PHP и PHPMailer"  –3 +/
Сообщение от Аноним (15), 08-Дек-18, 14:05 
Интересно было бы узнать, где и с чем работают все эти немногочисленные хейтеры php и systemd.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (7), 08-Дек-18, 14:14 
ErlangVM, Rust, Python3, Golang, NodeJS, & Ruby.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

17. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Vitaliy Blatsemail (?), 08-Дек-18, 14:34 
> ErlangVM, Rust, Python3, Golang, NodeJS, & Ruby.

И шо, уже есть нормальные известные проекты на этом?)

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

20. "Уязвимости в PHP и PHPMailer"  –1 +/
Сообщение от Аноним (20), 08-Дек-18, 16:05 
Есть. Только никто не признаётся, на чём его проект, а то мамкины хацкеры, если узнают, перестанут бомбить их сайты типовыми эксплойтами для PHP, скачанными из сети. А это такой источник лулзов - вы даже не представляете!
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

22. "Уязвимости в PHP и PHPMailer"  +1 +/
Сообщение от пох (?), 08-Дек-18, 16:17 
> а то мамкины хацкеры, если узнают, перестанут бомбить их сайты типовыми эксплойтами для PHP,
> скачанными из сети

скачают типовой эксплойт для поделок на ror, node и что там у вас еще за хлам, а, ну да, свежие баги в жанге забыли, и лулзы кончатся, начнутся поиски "как убрать чорного властелина с сайта".

вот, например, не-такие-как-все приходили:
/CFIDE/cf_scripts/scripts/ajax/ckeditor/plugins/filemanager/filemanager.cfm" failed (2: No such file or directory)
(сорри, ребята, но нет у меня гармо... coldfusion'а - сюда вот идите, там есть: https://apps.wharton.upenn.edu/cf_scripts/scripts/ajax/ckedi.../)

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

24. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (24), 08-Дек-18, 16:48 
ROP Gadget в твою вордпреску, скомпилят как модуль ядра и подгрузят.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

31. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (31), 08-Дек-18, 18:58 
> ror, node ... в жанге

Это все варианты, которые вам известны?

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

34. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 08-Дек-18, 21:49 
не, это что я сходу у себя в логе нашел, помимо coldfusion'а и миллиона...чего это за зомбонет, я забыл, из хоменасов-то, весной появился? Судя по .cgi - на прекрасной сишечке ;-)

жабы вот не видно что-то - то ли с regex неугадал, то ли не сезон, пакованный лог лень шерстить

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

39. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Sw00p aka Jerom (?), 09-Дек-18, 01:10 
поищи че нить такое ))

%24%7B%28%23_memberAccess%5B%22allowStaticMethodAccess%22%5D%3Dtrue%2C%23a%3D@java.lang.Runtime@getRuntime%28%29.exec%28%27{0}%27%29.getInputStream%28%29%2C%23b%3Dnew%20java.io.InputStreamReader%28%23a%29%2C%23c%3Dnew%20%20java.io.BufferedReader%28%23b%29%2C%23d%3Dnew%20char%5B51020%5D%2C%23c.read%28%23d%29%2C%23sbtest%3D@org.apache.struts2.ServletActionContext@getResponse%28%29.getWriter%28%29%2C%23sbtest.println%28%23d%29%2C%23sbtest.close%28%29%29%7D

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

43. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 09:28 
а, точно, cpyt-c же ж. Не, такие продвинутые ко мне редко ходют, им проще подавай:

GET /struts2-rest-showcase/orders.xhtml
а вот вообще прекрасное:
GET /struts-cookbook/processSimple.do

;-)

кто там авторов безобидного js-аплоадера ругал за демо-скрипты без лишних проверок? Мощные жабисты, как видим, тоже не брезгуют. А админы ничерта не понимают в этой жабе, попросили их поставить, поставили.

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

23. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Vitaliy Blatsemail (?), 08-Дек-18, 16:39 
> Есть. Только никто не признаётся, на чём его проект, а то мамкины
> хацкеры, если узнают, перестанут бомбить их сайты типовыми эксплойтами для PHP,
> скачанными из сети. А это такой источник лулзов - вы даже
> не представляете!

Значит нету. Что в принципе и требовалось доказать.
Почти все фронтенды пишутся на PHP, потому что он одновременно отвечает сразу нескольким требованиям - легкости (а значит программисты на нем более дешевле), распространенности (а значит в сети много информации о нем), поддержке (а значит он может работать на чем угодно), относительной скорости работы (хотя для фронтенда она особо и не нужна), универсальности (а значит к нему написано много плагинов и фреймворков).

Почти все конторы где работает больше пяти анонимусов, выставляют требования к проекту чтоб он РАБОТАЛ, чтоб он обошелся ДЕШЕВЛЕ, опционально чтоб его потом могло поддерживать более чем три человека на всю страну. Требований "чтоб был написан только на Ruby" я еще не видел за 10 лет работы в этой сфере.

Разумеется ты конечно начнешь приводить аргументы типа "Ruby удобнее", "Python читабельнее", "Go секюрнее", но PHP не зря стал таким распространенным обогнав Perl, и чтобы ТВОЙ язык стали считать нормальным - он не должен быть удобнее, или читабельнее, или секюрнее. Он должен быть лучше одновременно во всем и сразу.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

29. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (31), 08-Дек-18, 18:51 
> чтоб он РАБОТАЛ

Угу. "Чтоб он РАБОТАЛ" так, как нужно заказчику не только на момент приёмки от "студии веб-дизайна", но и через месяц, и через год. А когда "проект" впихивает юзерам малварь, сливает налево базу пользователей, майнит крипту на оплаченных заказчиком мощностях и т.д. - это не называется "чтоб он РАБОТАЛ".

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

36. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 08-Дек-18, 21:54 
через год этот заказчик уже банкрот и сдает квартиру, благо ипотеку выплатил в жырном 2008м, когда деньги падали с неба даже в совершенно бестолковые руки.

так что пусть помайнит - домен и хостинг оплачены со скидкой за двухгодичную разовую оплату, все равно пропадают.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

42. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (41), 09-Дек-18, 08:26 
Так не бывает. Поддерживать и исправлять уязвимости нужно постоянно и на любом языке.
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

64. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (64), 09-Дек-18, 14:13 
Дык отож!
Только одно дело раз в день по диагонали просматривать письма от log analyser'а и почитывать рассылку от разрабов в ожидании сведений об уязвимостях (а она чуть более чем полностью состоит из вопросов нубов "как мне сделать"), а другое дело когда каждый месяц надо что-то править, обновлять,  накатывать, дампить-ресторить, и т.д.
Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

37. "Уязвимости в PHP и PHPMailer"  +2 +/
Сообщение от User (??), 08-Дек-18, 22:51 
>(а значит программисты на нем более дешевле),

"более дешевле", да... ПыХаПэ-культура в двух словах, ага. Портрет явления, тскзть.
За PHP Марьванна двойки не ставит - погнали, посоны!!!111

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

85. "Уязвимости в PHP и PHPMailer"  +1 +/
Сообщение от Sw00p aka Jerom (?), 09-Дек-18, 19:46 
>>Почти все фронтенды пишутся на PHP

фронтенды на пхп не пишут :)

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

27. "Уязвимости в PHP и PHPMailer"  +1 +/
Сообщение от Аноним84701 (ok), 08-Дек-18, 17:47 
>> ErlangVM, Rust, Python3, Golang, NodeJS, & Ruby.
> И шо, уже есть нормальные известные проекты на этом?)

Если вы ничего не слышали о CloudFlare, GitHub, dl.google и Netflix, то у меня для вас неприятные новости.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

44. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 09:38 
>>> ErlangVM, Rust, Python3, Golang, NodeJS, & Ruby.
>> И шо, уже есть нормальные известные проекты на этом?)
> Если вы ничего не слышали о CloudFlare, GitHub, dl.google и Netflix, то
> у меня для вас неприятные новости.

окей, любитель приятных новостей - ни в какой из этих я работать не хочу, они тупые, жадные, и даже 401k matching от этих не дождешься (ну, может, если предъявить справку что ты - Оно, будет оплата препаратов, но мне как-то без надобности). Еще есть варианты, или это все?

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

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

59. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним84701 (ok), 09-Дек-18, 13:28 
> окей, любитель приятных новостей - ни в какой из этих я работать  не хочу, они тупые, жадные, и даже 401k matching от этих не дождешься (ну, может, если предъявить справку что ты - Оно,

Держите нас в курсе! Нам ведь (почти) интересно!

> заметим, что тут еще и ловкая подмена темы - спрашивали о проектах,
> доступных для эксплуатации кем-то, а вы вывалили домашние поделки для работы

Заметим, что тут еще и ловкая подмена темы на тему о подмене темы.
Вся ветка, полностью:
>>>> где и с чем работают все эти немногочисленные хейтеры php и systemd.
>>>ErlangVM, Rust, Python3, Golang, NodeJS, & Ruby.
>> И шо, уже есть нормальные известные проекты на этом?)
> Если вы ничего не слышали о CloudFlare, GitHub, dl.google и Netflix, то у меня для вас неприятные новости.

"спрашивали о проектах, доступных для эксплуатации кем-то, а вы вывалили домашние поделки [...]"
Мне вот интересно, вы когда нибудь научитесь читать целиком, по возможности глазами (и заодно отвечать на написаное другими, а не придуманное вами)?

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

67. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 17:07 
ну ок, так и запишем - "в основном - нигде, основная ниша - внутренняя кухня аж трех громадных ентер-прайсов с сотными тысяч одних курьеров и вообще специфическими задачами и подходами к их решениям, то есть для обычных смертных == нигде"

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

40. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от НяшМяш (ok), 09-Дек-18, 02:45 
github.com ?
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (19), 08-Дек-18, 16:00 
Иными словами - в основном, нигде.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

25. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (24), 08-Дек-18, 16:50 
Пыхапистам виднее, ведь эти мамкины разработчики уже всему научены.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

26. "Уязвимости в PHP и PHPMailer"  –2 +/
Сообщение от Vitaliy Blatsemail (?), 08-Дек-18, 16:56 
> Пыхапистам виднее, ведь эти мамкины разработчики уже всему научены.

Если язык для своего понимания, требует какие-то особые скиллы и особую уличную магию, он УЖЕ НА СТАРТЕ не нужен.

Пока мамкины разработчики пишут продукты, хорошие или не очень, ты изучаешь достоинства языка. Хе.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

30. "Уязвимости в PHP и PHPMailer"  +1 +/
Сообщение от Аноним (31), 08-Дек-18, 18:53 
Если разработчик не имеет хотя бы минимальной подготовки и набора скиллов, он УЖЕ НА СТАРТЕ не нужет.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

33. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Анонн (?), 08-Дек-18, 19:31 
> Если разработчик не имеет хотя бы минимальной подготовки и набора скиллов, он УЖЕ НА СТАРТЕ не нужет.

Осторожнее, эта братия при сильном негодовании не только бананами закидать может!


Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

35. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 08-Дек-18, 21:52 
как это не нужен? А кто мне будет за пиццот рублев чинить сдохший битрикс? Мне что, самому мараться?

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

63. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (64), 09-Дек-18, 13:45 
> битрикс

ып... ып... ып... ыбуэээ....

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

80. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 18:57 
буэ свое можешь откладывать сколько влезет, только не на мой столик - мне чтоб завтра сайт заработал, сделаешь - 500 рублей получишь.

и ведь делают же ж :-(

Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

38. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от vedronim (?), 08-Дек-18, 23:06 
Это все, что ты смог нагуглить о языках?
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

50. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (7), 09-Дек-18, 12:15 
Erlang/Ruby -> +Elixir
+ Crystal
Nim
Elm
Dlang
Haskell
Scala
Kotlin
Swift
Ponylang
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

90. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (86), 09-Дек-18, 22:18 
> немногочисленные хейтеры php

Определение слова "хейтер" и статистику по многочисленности - в студию.

А то есть подозрение, молчек, что ты балабол.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

45. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Онаним (?), 09-Дек-18, 11:09 
Уязвимость выглядит как дерьмо, и реально дерьмо, но причина таковой - передача юзеринпута в различные вызовы без валидации.

Кодер, помни: если ты забираешь что угодно ($server) с юзеринпута и фигачишь в вызовы библиотек (imap_open) без проверки на соответствие формата и валидность (в данном случае - доменное имя и возможно :порт) - в программировании тебе не место, да и руки видимо надо экстренно выпрямлять.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

53. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 13:09 
> Кодер, помни: если ты забираешь что угодно ($server) с юзеринпута и фигачишь в вызовы
> библиотек (imap_open) без проверки на соответствие формата и валидность

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

Может все же где-то в консерватории поправить, а? Например, в $server принимать только и исключительно - server, а любые дополнительные параметры протокола передавать дополнительными аргументами? Не, не модно, не молодежно, мы любим прекрасные псевдо-uri ?

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

58. "Уязвимости в PHP и PHPMailer"  +1 +/
Сообщение от Онаним (?), 09-Дек-18, 13:23 
> проверку как производить будем

В данном конкретном случае - регэкспом. Валидный формат доменного имени вполне себе описан. Никаких посторонних символов типа / в переданном пользователем $server для imap_open быть не должно.

Попали опять не желающие проверять пользовательский ввод, впрочем, они попадают на любых языках, в любых ОС и всегда.

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

69. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 17:16 
ну и зачем, зачем тогда вы накрутили в imap_open какие-то другие операции с этим $server без явного указания ?

Кому оно надо, если от юзера мы такое не принимаем, спрашивается?

очередной ненужный и опасный оверинжиниринг, прикрываем регекспами, как всегда.

валидный формат доменного имени в эпоху юникодного мусора в dns - нечто уму непостижимое, если что. Я хз как его на валидность проверять (разьве что развернув сперва в punicode)

Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

75. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Онаним (?), 09-Дек-18, 18:48 
А затем, что у imap_open овердохера применений. И накрутили не совсем в пхп, а в либц-клиенте.

Ещё раз: не "прикрываем регекспами", а именно валидируем. Если может быть только хостнейм - валидируем регэкспом на соответствие. Если может быть только полтора сервера из менюшечки - проверяем присутствие. Передавать голый юзеринпут сторонней библиотеке без валидации опасно в любом языке и любом контексте.

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

81. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 19:03 
> А затем, что у imap_open овердохера применений.

честно говоря, применение в виде imap over rsh мне представляется требующим при сборке -DIWANNATHISSHITFULLMOUTH и еще пятнадцати рандомных чисел в правильной последовательности.

применение в виде imap over rsh replaced by ssh - ну, может быть, какому-то ретрограду (считающему еще и ssh достаточно безопасным и надежным способом доступа к удаленному серверу без всякого основания) и надо, но скорее всего он mutt через вручную сконфигуренный туннель запустит, а ЭТО вообще ни один нормальный человек не использует.

очередной типовой оверинжиниринг - ну ок, на сей раз не в php, видимо.

> Если может быть только хостнейм

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

Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

46. "Уязвимости в PHP и PHPMailer"  –1 +/
Сообщение от Онаним (?), 09-Дек-18, 11:17 
Что же до пыхмейлера - 250+ кб кода, чтобы банально сформировать и отправить MIME - пользующиеся этим счастьем ссзб и должны страдать :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

54. "Уязвимости в PHP и PHPMailer"  +1 +/
Сообщение от пох (?), 09-Дек-18, 13:10 
где посмотреть на твои 25 строк кода, делающих то же самое? (exec metamail не катит)
Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

60. "Уязвимости в PHP и PHPMailer"  –1 +/
Сообщение от Онаним (?), 09-Дек-18, 13:30 
Широкой публике - нигде.
Чекнул у себя Email.php - 344 строки кода, 13.5 кб. Умеет mail(), SMTP (со STARTTLS), автоматически создаёт text/plain вложение из HTML, умеет аттачменты. Из того, что умеет PHPMailer - не умеет инлайн изображения (возложено на приложение), не умеет DKIM-подпись, не умеет OAuth и POP3-before-SMTP. Но это не стоит 200 кб.
Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

68. "Уязвимости в PHP и PHPMailer"  +1 +/
Сообщение от пох (?), 09-Дек-18, 17:12 
ну молодец, возьми с полки пирожок. Судя по отсутствию у тебя желания публиковать этот код - в нем есть, хехе, ньюансы.

dkim и pop скорее всего реализуются банальными встроенными средствами (раз уж у нас imap внезапно сам без спросу лезет в ssh, то уж тут-то, поди, один лишний флажок поставить) так что, полагаю, дело все же не в этом.

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

77. "Уязвимости в PHP и PHPMailer"  –1 +/
Сообщение от Онаним (?), 09-Дек-18, 18:52 
Насчёт "скорее всего" по DKIM и POP - нет, в пхпмейлере там всё ногами, то есть руками. При этом им зачем-то приходится заголовки обратно разбирать при формировании, что добрую долю оверблоута добавляет.
Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

82. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 19:07 
так его писали десять лет назад, если не больше - там еще много чего руками, что в php5.2 было только руками и можно. Понятно что пора уже напрячься и почистить... ну я чо, я менеджеров пнул, кодеры уже в пятницу выбежали с лопатами, няхай шкрябают.

а в самопальном коде под 7.2+ скорее всего обойдется, но вряд ли это повод гордитьтся что уложился в одну переменную вместо тысяч строк кода. Просто это уже сделали за тебя (и не факт что хорошо ;-)


Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

79. "Уязвимости в PHP и PHPMailer"  –2 +/
Сообщение от Онаним (?), 09-Дек-18, 18:57 
Ну и да, никаких "нюансов", влияющих на функционирование, там нет.

Просто с поветрием современных оверблоутных PSR'ов с композерами, 100500 классами в 3 строчки, неймспейсами на каждый чих и прочими прелестями публиковать "чистые" олдскульные либы (1 либа/класс - 1 полностью реализованный функционал) бессмысленно.

PHPMailer кстати ещё в этом плане тоже пока держится, там всего пяток файлов, которые надо вгрузить.

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

83. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от пох (?), 09-Дек-18, 19:09 
ну фиг знает - если код хороший - есть смысл его выложить, один использовавший вместо пхпмэйлера - минус один (а может и десяток) источник спама и попыток хакнуть, тоже неплохо.

Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

94. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Gemorroj (ok), 10-Дек-18, 12:57 
да трендишь 100%, наверняка там вагон и телега багов будет с юникодом каким-нибудь и проч.
и еще у тебя так же наверняка будут уязвимости. ты же ничего не знал про уязвимости в imap_open и утащил к себе 100500 строк сишного кода в виде php интерпретатора, чтобы "сформировать и отправить MIME".
Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

95. "Уязвимости в PHP и PHPMailer"  –1 +/
Сообщение от ваш КО (?), 10-Дек-18, 14:55 
imap_open не имеет прямого отношения к отправке почты, которой занимается PHPMailer или его самодельная замена в 300 строк

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

97. "Уязвимости в PHP и PHPMailer"  –1 +/
Сообщение от Аноним (97), 10-Дек-18, 15:33 
Всё куда проще, я $_GET в вызовы не передаю, предварительно не обработав во все поля. Ни одна библиотека от криворукости не застрахует.
Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

93. "Уязвимости в PHP и PHPMailer"  –1 +/
Сообщение от Gemorroj (ok), 10-Дек-18, 12:51 
новость об уязвимостях написали, а об релизе пхп 7.3 нет. совпадение? не думаю)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

99. "Уязвимости в PHP и PHPMailer"  +/
Сообщение от Аноним (99), 11-Дек-18, 12:26 
> новость об уязвимостях написали, а об релизе пхп 7.3 нет. совпадение? не
> думаю)

Вы рандомом что-ли новости для чтения выбирайте? Новость про PHP 7.3 была за день до новости про уязвимости.
https://www.opennet.ru/opennews/art.shtml?num=49732

Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Ihor
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2019 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру