В плагине jQuery-File-Upload (https://github.com/blueimp/jQuery-File-Upload/) выявлена (https://blogs.akamai.com/sitr/2018/10/having-the-security-ru...) поучительная уязвимость CVE-2018-9206 (http://www.vapidlabs.com/advisory.php?v=204), показавшая удивительную беспечность web-разработчиков и web-администраторов. jQuery-плагин jQuery-File-Upload предоставляет функциональный web-виджет для организации загрузки файлов на сайты, поддерживающий групповую загрузку, индикатор прогресса и возобновление прерванных загрузок. Основная функциональность jQuery-File-Upload реализована на JavaScript и выполняется на стороне браузера, при этом в состав также входит набор примеров серверных обработчиков (https://github.com/blueimp/jQuery-File-Upload/tree/master/se...) для сохранения отправляемых файлов.
Суть уязвимости в том, что в предлагаемых серверных обработчиках полностью отсутствовали фильтры для блокирования загрузки потенциально опасных типов контента и загружаемые файлы сохранялись на сервере под исходными именами, которые определял пользователь на сайте. Данные загружались в каталог "./files", находящийся в рабочей иерархии каталогов web-сервера. Таким образом, при использовании предлагаемых сервреных обработчиков, пользователь мог сохранить любые типы файлов, например, "text.php", которые сохранялись в публично доступной директории и становились видимыми для внешних запросов (например, загруженный "text.php" можно было получить запросив "http://example.com/files/test.php").
В ситуации, если на сайте используется PHP и включено выполнение php-файлов во всей иерархии каталогов, подобный запрос без должного ограничения доступа к каталогу "./files" приведёт к выполнению кода сохранённого в файле test.php скрипта на стороне сервера, что позволяет полностью получить контроль за сайтом. Основной ошибкой разработчика jQuery-File-Upload стало то, что он не стал ограничивать допустимые для сохранения типы файлов, а попытался включить в поставку ".htaccess (https://github.com/blueimp/jQuery-File-Upload/blob/master/se...)", устанавливающий обработчик по умолчанию ("SetHandler default-handler", "ForceType application/octet-stream").
Разработчик jQuery-File-Upload почему-то полагал, что на всех web-серверах всегда включена обработка ".htaccess" и активен модуль mod_headers. В обсуждении разработчик дополнения попытался оправдаться (https://news.ycombinator.com/item?id=18267309), что на момент написания плагина по умолчанию в Apache httpd для всех каталогов выставлялась опция "AllowOverride All (https://httpd.apache.org/docs/2.2/en/mod/core.html#allowover...)", но начиная с выпуска 2.3.9 она была незаметно заменена на "AllowOverride None (https://httpd.apache.org/docs/2.4/en/mod/core.html#allowover...)".
Но данное объяснение не выдерживает критики, так как ветка 2.3.x являлась тестовой и сама по себе не использовалась на практике, а выступала основой для формирования следующего значительной ветки Apache httpd 2.4, в которой указанное поведение было документировано (http://httpd.apache.org/docs/2.4/upgrading.html) и преподносилось как одно из изменений для повышения безопасности и производительности. Кроме того, решение о включении или отключении по умолчанию ".htaccess" всегда лежало на операторах хостинга и мэйнтейнерах пактов в дистрибутивах, поэтому и во времена до появления Apache httpd 2.4 нельзя было с уверенностью утверждать, что .htaccess везде будет работать.
За время своего существования плагин jQuery-File-Upload был вошёл (https://www.theregister.co.uk/2018/10/22/jquery_file_flaw/) в состав сотен web-приложений и дополнений к системам управления web-контентом, и лишь единицы догадались ограничить список допустимых для загрузки файлов. В настоящее время на GitHub репозиторий jQuery-File-Upload насчитывает 7843 форков, проверка (https://github.com/lcashdol/Exploits/tree/master/CVE-2018-9206) 1000 из которых показала, что лишь 36 содержат должные исправления, блокирующие уязвимость.Судя по всему, проблема уже давно известна в кругах атакующих, так как в сети найдено несколько руководств, первое из которых датируется 2015 годом, с демонстрацией взломов тех или иных систем через загрузку php-файла и его последующего открытия из каталога "./files". Всем web-мастерам рекомендуется срочно проверить наличие блокировки доступа к каталогу "./files" для внешних запросов и при необходимости внести изменения, отключающие выполнение PHP-скриптов в данной директории, на уровне настроек web-сервера.
URL: https://blogs.akamai.com/sitr/2018/10/having-the-security-ru...
Новость: https://www.opennet.ru/opennews/art.shtml?num=49483
Удивительно одно - идиотизм людей, которые на полном серьёзе рассказывают эту школьную историю по всему интернету.
Удивительно одно - идиотизм людей, которые тянут js библиотеку на несколько мегабайт вместо того, чтобы написать одну строчку на html.
Давай, г-ній JS, покажи-ка нам эту самую заветную одну строчку на html, функционально торжественную плагины.
плагины в функционально-торжественном стиледоступны также повседневные плагины и плагины выходного дня
И как же одной строчкой на html сделать закрузчик множественных файлов с индикатором?
Множественные загрузки возможно, а «индикатором» будет браузер ¯\_(ツ)_/¯
действительно
https://caniuse.com/#search=multiple
> Удивительно одно - идиотизм людей, которые тянут js библиотеку на несколько мегабайтДыра в примерах на php, python и go, а не в JS. Ты, кстати, свое коронное "вспомнити leftpaf" еще забыл.
А при чем тут js-мирок, если виноваты во всём серверные обработчики?
Похапешники: Мы не виноваты! Это JS-ребята психологически манипулировали нами и подсунули нам уязвимый код в своей документации.Опеннет: Похапешники не виноваты! Вспомнити leftpad. ОЧЕВИДНО, что проблема в JS. Необдуманное использование именно JS-плагина к JS-фреймворку с психологическим давлением на похапешников!
Это не жс и не пхпшники, это просто идиоты, писавшие код на стороне сервера. В следующий раз они на чём-нибудь другом сохранят пользовательский файл, как исполняемый модуль, в ветке исполнения. Антрастед юзер-инпут - не, не слышали.
это чего это вот "файл"? Мы и круче умеем, учись, шкoльник:$strSql=
"SELECT ID, NAME, AGENT_INTERVAL, IS_PERIOD, MODULE_ID ".
"FROM b_agent ".
"WHERE ACTIVE='Y' ".
" AND NEXT_EXEC<=now() ".
" AND (DATE_CHECK IS NULL OR DATE_CHECK<=now()) ".
$str_crontab.
" ORDER BY SORT desc";$db_result_agents = $DB->Query($strSql);
[skip]
$eval_result = "";
eval("\$eval_result=".$arAgent["NAME"]);
(кто не понимает - весь прикол в том, что тут не должно лежать ничего, кроме заранее определенных функций, но парсить их имена и вызывать по ссылке, убедившись что вызываемое действительно существует - не, слишком сложно для обизяна - eval, даже без try, и всех делов! При попадании в таблицу мусора или троянского кода - сам понимаешь - и хрен его кто потом найдет)завтра точно так же сложим в таблицу все что юзер навводил или ему навводили, и eval его.
Поэтому надо пользоваться CMS, в которых URL не маппится напрямую в часть древа ФС, а парсится с помощью dispatch rules, или как они там у кого называются.
routes
Не CMS, а тупо файлы отдавать через Nginx как статику, без всяких php и т.п. обработчиков.
это слишком сложно для типового девляпсика, у него КПИ горят, git clone, ansible-playbook -f 10000 , ляп, ляп, ляп.И практически невозможно для обычного юзера с недосайтиком на шареном помойкохостинге - он уже заплатил 500 рублей мне, за сайтик, и совсем не собирается платить еще 1500 в месяц за хостинг с нормальными настройками (да и кто настраивать будет? Мы-то могем в php, nodejs и еще вот, пихон. nginx - не могем)
А с чего бы скрипту общего назначения что-то проверять по дефолту? Может ещё и сайт весь за разработчика написать?
В конечном счёте фильтрами всё и исправили:https://github.com/blueimp/jQuery-File-Upload/commit/ad4aefd...
+ 'accept_file_types' => '/\.(gif|jpe?g|png)$/i',
В добавок и замену точек в имени файлов добавили:
+ 'replace_dots_in_filenames' => '-',
+ // Replace dots in filenames to avoid security issues with servers
+ // that interpret multiple file extensions, e.g. "example.php.png":
Выпал в осадок. Править в этом случае надо серверсайд.
ну вот, а вы ругались, что проблема в пехепе - видите же, автор все признал, покаялся перед партией и товарищами по цеху, и исправ...изуродовал свой скрипт так, чтобы альтернативно-одаренным жить стало проще. Странно, действительно, что не переименовал его в "jquery-jpsosmth-png-and-gif-only-upload".то есть если даже и не во всем виноват js, то разработчики на нем - все равно *даки, как ни поверни.
Это не забота плагина что-то фильтровать и почему он должен запрещать к загрузке какие-то типы файлов? Может пользователь хочет передать скрипт через шару. То что скрипты выполняются в директории для загрузки - это диагноз админу хоста.
Проблема высосана
Точно. Считаю, что тот, кто ставит плагин к себе на сайт, и должен думать об этом. С другой стороны, разработчик плагина мог бы в документации указать на эту возможную опасность.
В молотке найдена поучительная уязвимость, показавшая беспечность изобретателя: можно ударить по пальцу или даже уронить его на ногу. По умолчанию молоток бьёт бойком по всему, что под него попадает, не различая гвоздь это или конечность идиота!
7843 форков? Кто все эти люди?
Вы исправление видели?
+ 'accept_file_types' => '/\.(gif|jpe?g|png)$/i',
Теперь всем тем, кому нужен будет pdf, придется делать форк. :)
Поясните, плиз, куда именно воткнули это «исправление»? В жс код, в пример жс кода или в пример серверного обработчика?
Бред какой, что «уязвимость», что новость.
в конфиг его воткнули, сюрпрайз.
SECURITY FIX: Only allow image file types by default.смешно, превратили в jQuery-Image-Upload
> смешно, превратили в jQuery-Image-Uploadна самом деле - нет, "что настроишь, то и upload" - причем оно там всегда было, просто по умолчанию принимало все подряд, а теперь, для упрощения жизни альтернативно-одаренным, фильтр изначально выставлен в дурацкие имена картинок.
Что говорит в пользу автора, #дак бы добавил антифильтр с .php, .php5, .php7, а потом "ой, а тут подсунули .py"
Но вот трансляцию надо было сделать нормально, а не . на - менять.
вообще-то хороший плагин, надо брать.
В статье 0 про nginx с fpm, который тоже напрочь не слушает .htacces и как то без этого отлично безопасно работает. Лучше бы написали, что держать аплоадер без авторизации это плохо и все.
files ? Хм. Ну так нужно специально сделать обработчик пути files для начала чтобы можно было так обратиться ...
это косяк не разработчика плагина. больше тянет на разработчиков apache и может админов
по результатам голосования среди админов и разработчиков было решено, что виноват только автор плагина.
автор apache же ... Он так злокозненно заменил умолчание в 2.4
> автор apache же ... Он так злокозненно заменил умолчание в 2.4ну что авторы нынешнего апача совсем плохие п-сы, никто и не сомневается. А вот зачем им люди все еще пользуются - понять не могу.
(там прикол что None, которое нынче ваш новый стандарт, вообще отключает чтение htaccess - то есть ошибку не выдает, а просто молча его игнорирует)
явная ошибка конфигурации веб-сервера, а крайним сделали разработчика плагина
ты еще скажи, что электрон это круто. ЖС должен умерет
> загружаемые файлы сохранялись на сервере под исходными именамиВоистину, неискоренима тупость... Какие фильтры? Какие ошибки конфигурации?
Сохранять пользовательские файлы под внутренним именем и делать связывание с пользовательским именем через БД или файл метаданных школоту так и не научили.
Шёл 21 век, ФС позволяла сохранять метаданные в себя…
Не надо метаданные в себя, ФС может оказаться разная.
> Не надо метаданные в себя, ФС может оказаться разная.давайте тогда и данные (вот все 48 мегапикселей фоточки салатика) сохранять в БД - "fs же может оказаться разная" (а не горе-девляпс, выбравший fs для хранения юзерских файлов, не умеющую хранить файлы, покидает нас в трех ботинках) - вдруг у нее размер файла три килобайта и ни байтом больше? А, и внутри файла могут быть только четные байты, а от нечетных она ломается.
>> загружаемые файлы сохранялись на сервере под исходными именами
> Воистину, неискоренима тупость... Какие фильтры? Какие ошибки конфигурации?
> Сохранять пользовательские файлы под внутренним именем и делать связывание с пользовательским
> именем через БД или файл метаданных школоту так и не научили.Да ;) Интересно как это работает на высоко нагруженных серверах? Что будет если два пользователя одновременно захотят сохранить файл "Noname.txt"?
А если пользователь "Аноним", то видимо необходимо "Сохранять пользовательские файлы под внутренним именем и делать связывание с пользовательским именем через БД или файл метаданных". Ну а если он вообще, среднестатистический "Аноним" без "печенек", то видимо можно по session_id (и что, по выходу времени сессии удалять это содержимое, а то как и главное кто сможет к этому содержимому позже обратится?).
> Да ;) Интересно как это работает на высоко нагруженных серверах? Что будет если два пользователя одновременно захотят сохранить файл "Noname.txt"?Будут два файла abcd0001.dat и abcd0002.dat, и две записи в БД.
Файл отдать можно например через mod_xsendfile, но с прослоечкой, которая подставит content-disposition с нужным файлнеймом.
> Будут два файла abcd0001.dat и abcd0002.dat, и две записи в БД.а если запись в бд по каким-то причинам пропала - мусор храним вечно, да?
> Файл отдать можно например через mod_xsendfile, но с прослоечкой, которая подставит content-
> disposition с нужным файлнеймом.вон сколько всего ненужно нужно сделать, чтобы подменить то, что файловая система изначально предназначена делать сама.
Количество интеллекта в мире- величина постоянная, а население растет... (с)Апач - не единственный веб-сервер на свете, и какая-то аргументация по поводу привязки плагина к .htaccess - просто абсурдна по сути. И со стороны автора и со стороны обвинителей.
Что же до описания механизма уязвимости - то это какой-то паноптикум некомпетентности.
Ждем продолжения :)
аффтар попытался подложить соломки, как умел, примерно предвидя уровень "админов", которые это будут настраивать.Но кунфу аффатаров апача оказалось круче, и они таки умудрились именно в тех местах, где гнездятся эти админы, поделить плохонькую защиту на ноль, безусловно, тоже ради заботы об альтернативно одаренных (всем остальным их поделка даром не нужна со времен убийства 1.3)
>это какой-то паноптикум некомпетентности.Полностью согласен, особенно глядя на предлагаемые воркараунды
По поводу идиотского ограничения загружать только image/*. Не удивлюсь если потом выяснится, что в php включен fileinfo c libmagic и оно, увидев в начале .jpg файла волшебные строчки "<?php", проигнорирует расширение и замечательно отработает как php.
Элементарное правило - отключение всех серверных хандлеров для каталогов, куда юзерам позволено загружать файло, не зависимо от расширения. Например, для Апача неужели сложно сделать
<Directory "/uploads">
php_flag engine off
AllowOverride None
Options None
Require all granted
</Directory>Либо в .htaccess
php_flag engine off
в тексте новости досадная ошибка: не «беспечность», а «…зм».
лихо говнокодеры всех дырявых пыхобэкендов попытались спрыгнуть, что фронтенд библиотека браузерная не проверяла тип файлов на опасность против их прелестного пыха