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