Comments 7
Мало того что префикс поставщика защищает от самой возможности подмены пакета, так и еще позволяет сделать fork уже существующего пакета чтобы поддерживать его самостоятельно если оригинальный пакет заброшен или не принимает изменения которые нужны вам.
Когда начал пользоваться npm по началу дико раздражало отсутствие этого префикса.
Проблема сводится к тому, что компании ссылаются на внутренние пакеты по имени, например my-internal-package, а злоумышленник публикует в центральном реестре/репозитории пакетов языка (для PHP это packagist.org) пакет с таким же названием my-internal-package, имеющий более высокую версию. После этого компании устанавливали и выполняли эти зловредные пакеты вместо своих внутренних пакетов, потому что их диспетчер пакетов выбирал версию с более высоким номером из стандартного репозитория пакетов вместо внутреннего репозитория.
Что?!!! Я понимаю какой-нибудь пет-проект на локалхосте с настройками композера (или его аналогов) по-умолчанию такое чисто теоретически может прокатить. Но для более серьёзных контор это вряд ли.
Во-первых: ну хорошо, угадал он что в компании Pear Inc. используют префикс пакетов pear-ink/, а не pear/ и не pi/, а с остальной частью имени пакета он что будет делать, подбирать рандомом, или он сначала получил доступ к исходникам?
Во-вторых: мы вот ни разу не apple, но у нас почему-то изначально lock файл комитится и проект разворачивается только через composer install, и не потому что мы параноики, а чтоб иметь протестированное окружение, а не то что там composer update автоматом наподключает.
В-третьих, за пакетами мы ходим через кеширующий прокси, на котором политики: все что не разрешено — запрещено.
One such company is the Canadian e-commerce giant Shopify, whose build system automatically > installed a Ruby gem named shopify-cloud only a few hours after I had uploaded it, and then tried > to run the code inside it. The Shopify team had a fix ready within a day, and awarded a $30,000 > bug bounty for finding the issue.
Another $30,000 reward came from Apple, after the code in a Node package which I uploaded to > npm in August of 2020 was executed on multiple machines inside its network. The affected projects appeared to be related to Apple’s authentication system, externally known as Apple ID.
Я сам не идеален, но уже на многое насмотрелся.
Если разработчики могут(это ключевое слово) они обязательно накосячат.
Первый пример с головы, я у себя в компании заколебался всем объяснять что билдить под рутом опасно, но они копипастят не моё решение)
Если разработчики могут(это ключевое слово) они обязательно накосячат.
Первый пример с головы, я у себя в компании заколебался всем объяснять что билдить под рутом опасно, но они копипастят не моё решение)
Вы видимо не вникали в упомянутую статью про Dependency Confusion — схема как раз хорошо сработала для больших и серьезных компаний, для npm и rubygems. И там достаточно было всего лишь, что-бы кто-то невнимательный засветил названия внутренних пакетов (ничего угадывать не надо), и чтобы такой пакет не был еще опубликован в паблик-репозитории. Ну и конечно же, чтобы сам package-manager был подвержен этой уязвимости. Всё.
То, что Composer приучил всех комитить лок-файлы, использовать префиксы и то, что он по умолчанию ставит пакеты из локального репозитория — это заслуга разработчиков Composer. Но не всем так повезло.
То, что Composer приучил всех комитить лок-файлы, использовать префиксы и то, что он по умолчанию ставит пакеты из локального репозитория — это заслуга разработчиков Composer. Но не всем так повезло.
Буквально вчера, читал про Azure Key Vault
docs.microsoft.com/en-us/learn/modules/manage-secrets-with-azure-key-vault/1-introduction
И вот они приводят пример Синьйор Разработчика!!! (look no further than the story of Steve, the senior developer.):
Я думал что случай надуманный, и это перебор… но наверное это самы настоящий реальный кейс рукалицо.жпг
docs.microsoft.com/en-us/learn/modules/manage-secrets-with-azure-key-vault/1-introduction
И вот они приводят пример Синьйор Разработчика!!! (look no further than the story of Steve, the senior developer.):
Steve had been in his job at a pet food delivery company for a few weeks. He was exploring the details of the company's web app — a .NET Core web app that used an Azure SQL database for storing order information and third-party APIs for credit card billing and mapping customer addresses — when he accidentally pasted the connection string for the orders database into a public forum.
Days later, accounting noticed that the company was delivering a lot of pet food that nobody had paid for. Someone had used the connection string to access the database and created orders by updating the database directly.
After realizing his mistake, Steve hurriedly changed the database password to lock out the attacker. After changing the password, the website started returning errors to users: the app server needed an updated configuration with the new password. Steve logged directly into the app server and changed the app configuration instead of redeploying, but the server was still showing failed requests.
Steve had forgotten that multiple instances of the app ran on different servers, and he had only changed the configuration for one. A full redeployment was needed, causing another 30 minutes of downtime.
Fortunately for Steve, the accounting department was able to correct the errors quickly, and only one day's worth of orders were impacted. He might not be so lucky in the future, though, and needs to find a way to improve the security and maintainability of the app.
Я думал что случай надуманный, и это перебор… но наверное это самы настоящий реальный кейс рукалицо.жпг
Есть такое понятие, как SBOM. Говорят про него редко.
Во многих корпорациях есть security policy с требованием использования только внутренних репозиториев. Но не во всех.
Во многих корпорациях есть security policy с требованием использования только внутренних репозиториев. Но не во всех.
Sign up to leave a comment.
Защита от уязвимости Dependency Confusion в PHP с помощью Composer