Во входящем в состав платформы Apache Airflow web-сервере выявлена уязвимость (CVE-2020-17526), вызванная некорректной проверкой сеансов в конфигурации по умолчанию. Уязвимость позволяет пользователю одного сайта получить доступ к другому сайту, используя идентификатор сеанса от первого сайта (для входа достаточно отредактировать сессионную Cookie). Проблема вызвана использованием в предлагаемом по умолчанию файле конфигурации airflow.cfg временного ключа, одинакового для всех установок. При данных настройках сессионная Cookie, заверенная на одном сервере Airflow, подходила для другого сервера...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54298
уязвимости — это хорошо, банальные — ещё лучше; без работы не останемся ;)
Болезни — это хорошо, банальные — ещё лучше; без работы не останемся ;)Уязвимости в головах, подобной вашей и тем кто ставит подобной ахинее лайки, также неплохо кормят психологов.
Рекомендую воспользоваться помощью квалифицированного специалиста.
ох, как у вас подгорело, сударь -- люди смотрят на вашу обитель и звонят 01 (не 03, к слову)
Упражняешся в генерации ахинеи?
"Подгорания" уже пошли и прочее подростковое.
Первая засветка была вполне убедительной, нет смысла демонстрировать многократно одно и тоже.
+1 Топик стартер мог быть более развит.
Жертвы посткапитализма не способны на это.
Поэтому и выдают подобные ментальные выделения.
Дохтар, памаги
Опять сишные дыры. На расте такой уязвимости бы не было.
Ни Раст, ни Си в новости не упоминается, а у сишника всё равно бомбит.
Тут у растоманов бомбит однако.
Вы таки что-то перепутали. Сишники сидят и пишут код, а у растовиков ничего не работает, поэтому они приходят сюда бомбить.
вот только большинство новостей про ошибки почемуто на си а на расте
Как мыможем здесь видеть - большинство ошибок по русскому языку.
Такие проблемы всегда были и будут. Разрабы никогда их не решат, потому что автогенерить ключ на лету в момент установки намного тяжелее чем просто взять шаблонный конфиг с захардкоженным. Поэтому ВСЕГДА после установки любого софта имеет смысл пробежаться по настройкам и конфигам и проставить всё в нужное значение.
Генерируется элементарно:
-----
if grep -q "^SECRET_KEY = 'invalid'" $CONFIG_PATH; then
sed -ri "s#(SECRET_KEY = ').+#\1$(openssl rand -base64 48)'#" $CONFIG_PATH
fi
-----
типичный код, взятый из скрипта инициализации в своих проектах.
Как можно меньше ожиданий от пользователя, потому что человеческий фактор будет всегда.
Grep && sed...
Зачем ещё ифы?
один sed, зачем grep?
"sed -i ...", даже ничего не сделавший, затрагивает время модификации файла - это фигня, если скрипт запускается один раз. но из-за скрипта, выполняющегося при запуске контейнера, это будет привлекать внимание к тому, что файл конфигурации будто бы кем-то изменён, хотя это не так.
Для читаемости.
> Grep && sed...
> Зачем ещё ифы?Т.к. иначе плохо работает в отладочном режиме для шелл скриптов. Написание с if меньше удивляет, но надёжнее работает, переносимо из кода в код легче. А остроумие в глопом смысле с && - лишнее упражнение.
многие проекты пишутся не для себя, и отдавать лучше в читаемом виде ("$()" - это известная подстановка, если что).
кроме того, если в оболочке ставится флаг "-e", то "&&" может заметно усложнить понимание потока выполнения даже для себя.
> Разрабы никогда их не решат
> автогенерить ключ на лету в момент установки намного тяжелее чем просто взять шаблонный конфиг с захардкоженнымЭта проблема лечится элементарно. В школе или родители.
Называется лень и бескултурье. В ИТ этого хлама по самые ноздри. Увы и ах. И дело всего-то только немного напрягаться в малом.
Ну, обыкновенное: в жизни нужно мучаться. Фокус в том, что мучаться немного, посильно, не уничтожая себя, а развивая.
Так что - есть решение проблемы.
И это, как ни странно, DevOps. Когда грамотные админы приходят к разрабам и учат как делать правильно.
Обычно происходит наоборот.
Ошибка, исправляемая одной строчкой в конфиге. Но комментаторам ЯП не сидится )
Это пиар системд, мол, с /etc/machine-id такого бы не было. Всем срочно встроить dbus в свои продукты!