Приложение
У нас есть небольшое Java-приложение, которое использует некоторые маршруты Camel для сбора загруженных файлов с веб-сервера, их обработки и отправки результатов по электронной почте.
Сервер, на котором работало это приложение, был выведен из эксплуатации. На данный момент мы должны запустить его на слабом оборудовании, потому что я не могу убедить администратора установить JRE на веб-сервере (который на самом деле является многоцелевым сервером).
Страх
Я сам Java Application Engineer, я пишу код JEE для жизни, обрабатывая транзакции B2B стоимостью в десятки тысяч евро в неделю. Но у меня есть проблемы с поиском надежных источников, которые опровергают миф о том, что Java сама по себе небезопасна.
Два основных аргумента администратора против установки JRE:
- Java-приложения поглощают всю мою оперативную память
- Java полна уязвимостей
Правда?
Когда дело доходит до приложений Java, съедающих оперативную память. Ну ... я бы сказал, что мы должны установить правильные значения для Xmx. Выполнено.
Сейчас есть много источников, говорящих о многих уязвимостях Java. Эти источники в основном предназначены для конечных пользователей, использующих определенную операционную систему от компании в Редмонде, США. Насколько нам известно, для непатентованных версий плагина Java-браузера, который настроен на автоматическое выполнение всех апплетов, существует большая вероятность того, что он станет жертвой заражения диска. Так же, как есть риск заразиться ЗППП при незащищенном сексе с кем-либо в вашем поезде во время поездок на работу.
Но я не смог найти никого на всемирной паутине, который бы говорил о серверных приложениях или JRE, работающих без головы. Это совсем другое.
Или я что-то здесь упускаю?
[править 2014-08-28] разъяснение: меня интересует только Java на серверах. Меня не волнуют проблемы с плагином Java и / или специальным программным обеспечением, разработанным в Java.
Ответы:
Дополнительная поверхность безопасности, которую Java создает в вашей среде, сложна, и важно не игнорировать ее и не пытаться упростить ее.
Во-первых, у JRE есть ужасная запись об ошибках безопасности. Трудно указать конкретный, и это страшная часть - ошибки - это в значительной степени неуказанные уязвимости с неопределенными векторами.
Когда я, как консультант по безопасности, читаю предложения типа «разрешает удаленному злоумышленнику» без дополнительной уточнения их значения, я вижу, что это вполне может означать, что определенные параметры, попадающие в определенную функцию, могут вызвать уязвимое состояние, даже если вы работают только код, который вы написали. И, поскольку они не определены, вы не узнаете, были ли они затронуты.
Более того, каноническая JRE, публикуемая Oracle, имеет заявленный ежеквартальный цикл обновлений для критических обновлений, включая почти все обновления безопасности. За последние четыре года они в общей сложности создали 11 патчей вне цикла. Это означает, что существует вероятность, что вы будете уязвимы для ошибки безопасности до трех месяцев после того, как о ней сообщат, прежде чем вы сможете исправить ее.
Есть и другие проблемы с Java, которые я не буду здесь затрагивать, но на самом деле кажется, что это оправданное беспокойство, особенно для многоцелевого сервера. Если вам нужно запускать такие вещи, вы должны, по крайней мере, создать для этого виртуальную машину специального назначения и изолировать ее от других вещей.
В частности, если в JRE есть пульт, который позволяет злоумышленнику получить RCE, и другой в PHP, который делает то же самое, и другой в Ruby, который делает то же самое снова, вы должны исправить все три. Все эти три варианта кажутся довольно вероятными, и злоумышленник выбирает тот, который наиболее удобен, а затем владеет всем сервером. Вот почему мы должны использовать виртуальные машины для разделения программного обеспечения, особенно программного обеспечения с ошибками, такого как платформы управляемых языков, и особенно тех, которые связывают исправления безопасности только четыре раза в год и являются собственностью поставщика, который утверждает перед лицом всех доказательств того, что они являются образцом безопасность.
Чтобы обновить, вот несколько CVE, которые я выбрал из поиска CVS, связанного с ChrisS, в качестве демонстрации.
И мой любимый, так как я был там:
Кстати, это всего лишь небольшая выборка.
источник
Альтернативой использованию ОЗУ является ее потеря. Вы не можете сохранить его на потом.
Это не имеет большого значения, потому что вы не собираетесь показывать JVM миру. Я предполагаю, что вы не собираетесь запускать какие-либо враждебные программы, и если да, то Java безопаснее, чем большинство других языков. Важно то, есть ли в ваших приложениях уязвимости.
источник
Наймите компанию, чтобы сделать статический анализ вашей программы. Например, Veracode - это компания, которую я использовал в прошлом для аудита безопасности кода программ Java, в частности.
Разумеется, выставьте счет за код вашей команды администратора.
источник
Объясните, что все другие языки (или виртуальные машины) могут быть небезопасными из-за кода, развернутого на них, как и в Java. Если он считает, что другие платформы по своей природе безопасны (или более безопасны, чем Java) без правильного решения проблемы безопасности, то он бредит.
Ваша компания, очевидно, инвестировала в наем Java-разработчика. Почему системный администратор отказывается поддерживать технологию, которую компания решила использовать?
Я бы перевернул вопрос и спросил его, какие альтернативы он предлагает и насколько они более безопасны, чем последняя доступная JRE для сервера, в очень конкретных терминах. В то же время постарайтесь показать, что вы понимаете свою технологию, возможную поверхность атаки и то, что вы работали, чтобы минимизировать ее (например, ненужные платформы, сторонний код и т. Д.). Проверьте свой код, найдите опубликованные уязвимости для фреймворков, на которые вы полагаетесь в последние X лет, сравните его с другими языками / фреймворками (не забудьте также включить markethare, неясные фреймворки без опубликованных уязвимостей ничего не значат).
Мы не можем знать, как произошло полное преобразование между вами, но если бы это были его два аргумента, я думаю, вы имеете дело с младшим системным администратором. Имеет ли он опыт работы с серверами приложений Java? Возможно, он не знаком с технологией и боится запускать что-то в производство, не разбираясь в этом (в таком случае, хорошее отношение сисадмина).
источник