Насколько безопасно использовать Maven?

Ответ 1

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

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

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

В качестве альтернативы практический подход может заключаться в создании прокси-сервера Maven (Artifactory или Nexus), обслуживаемого через HTTPS для внутренних клиентов. Это уменьшает поверхность атаки и означает, что вам просто нужно защитить линии связи от этого сервера до внешнего мира. Я периодически проверял, что JAR и хэши на прокси соответствуют тем, что есть в публичных зеркалах, используя полностью независимую, доверенную сеть.

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

Ну, безопасность в слоях, как они всегда говорят.

Ответ 2

Я могу думать о нескольких сценариях, хотя первый не является специфичным для Maven.

• Отравление кэша DNS

  Данные DNS, которые вы используете для доступа к стандартным репозиториям, могут быть отравлены, в результате чего Maven загружает артефакты из другого репозитория. См. статью wikipedia о отравлении кеша DNS.

• Нестандартные репозитории

  Любой репозиторий, который вы добавляете в конфигурацию Maven, может содержать артефакты, содержащие вредоносный код. Предотвратите это, используя только те сторонние репозитории, которым вы доверяете.

• Отравление репозитория

  Основываясь на Maven Руководство по загрузке артефактов в Центральный репозиторий, похоже, что центральный репозиторий Maven публикует артефакты из утвержденных хостов репозитория, поэтому безопасность артефактов зависит от хозяина. Я не знаю специфики процесса становления утвержденным хостом репозитория, но с таким количеством перечисленных в списке он, вероятно, обременителен.

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

• Артефактная модификация во время передачи (человек посередине)

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

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

Ответ 3

Если вы используете хорошо известные репозитории (центральный репозиторий maven, репозиторий jboss), очень низкая вероятность инъекции вредоносного кода. Компьютерный вирус, ваш интернет-провайдер или интернет-провайдер вашего интернет-провайдера должен работать с DNS-серверами или изменять пути маршрутизации для определенного набора адресатов. Я думаю, что это маловероятно - это касается не только maven repos, но и всех интернет-сервисов (электронная почта, http, voip и т.д.). Еще один риск заключается в загрузке JAR непосредственно с сайтов проекта.
В любом случае, если вы хотите иметь полный контроль, вы можете настроить свой собственный репозиторий maven (http://nexus.sonatype.org/)

Каждый файл, доступный в репозитории, должен иметь md5 или sha checksum generated - таким образом вы можете проверить, действительно ли то, что вы загрузили, именно то, что вы хотели. Но если злоумышленник (вирус) достаточно умен, чтобы перехватить вашу передачу данных и беспорядок в файлах JAR, он будет достаточно умен, чтобы перехватить контрольные суммы md5/sha. Защита от него заключается в том, чтобы предоставить подписи PGP как для контрольных сумм, так и для артефактов - выпустить артефакты, загруженные в центральный репо, вынуждены сделать это (файлы .asc)

Хорошей идеей является использование Nexus Professional - вы сможете настроить комплект поставки для проверки подписи PGP на сервере открытого ключа каждый раз при загрузке артефакта. Более подробную информацию о подписях PGP с maven можно найти здесь:

https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven

http://www.sonatype.com/people/2012/03/the-first-line-of-defense-checksums-and-pgp-signatures-in-repositories/