Безопасность Java

Декабрь 07, 2023

Java входит в ТОП-3 рейтинга самых популярных языков, самых безопасных языков и языков с наибольшим количеством выявленных уязвимостей. Так насколько безопасна Java? Стоит ли перевести корпоративное приложение на этот или другой, более безопасный язык? И можно ли классифицировать языки программирования по безопасности их архитектуры? Ответы на эти вопросы — в нашей статье.

1. Можно ли считать Java безопасным языком?
   1. Архитектура
   2. Уязвимости
2. Как проверить Java-приложение на безопасность
3. Языки программирования и требования законодательства к информационной безопасности
4. Заключение

Можно ли считать Java безопасным языком?

Можно ли считать Java безопасным языком? Или точнее: насколько встроенные функции Java позволяют программистам следить за безопасностью кода и не допускать грубых ошибок?

Архитектура

С одной стороны, некоторые характеристики архитектуры Java помогают писать изначально более надежный код. Например, строгая статическая типизация не позволяет смешивать разные типы переменных в одной операции и не допускает автоматического неявного преобразования, и при этом проверяет соблюдение данных требований на этапе компиляции. Это позволяет избежать непредсказуемого поведения программы и появления уязвимостей, связанных с неверными операциями над переменными. Стоит отметить, что это не делает динамическую типизацию небезопасной: можно написать безопасный динамический код и допустить ошибку со статической типизацией. Статическая типизация просто ставит управление переменными в более жесткие рамки, снижая риск появления трудно улавливаемых ошибок.

Еще одна сильная сторона Java — автоматическое управление памятью посредством сборщика мусора (GC), которая позволяет избежать большинства уязвимостей, связанных с утечкой памяти. Кроме того, благодаря автоматической сборке мусора разработчику не нужно самостоятельно контролировать распределение и освобождение памяти, а в данном случае меньше кода — ниже риск ошибок.

С другой стороны, сериализация / десериализация в Java связана с высоким риском удаленного выполнения кода (remote code execution, RCE). Сериализация позволяет преобразовать объект в байтовый поток для дальнейшей передачи или хранения, а десериализация — конвертировать байтовый поток обратно в объект. Наибольшие риски связаны с десериализацией, поскольку методы десериализованных объектов могут быть вызваны до выполнения проверки восстановленных объектов, в результате чего поток неизвестных данных, потенциально содержащий вредоносный код, может стать Java-объектом.

Больше трети уязвимостей в Java связаны с сериализацией, что привело к разработке плана по постепенному удалению механизма сериализации из платформы в рамках проекта Amber. Но с точки зрения архитектуры сериализация реализована корректно, поэтому ее тоже нельзя считать небезопасной фичей по умолчанию. Проблема заключается в том, что она почти всегда вынуждает разработчиков писать уязвимый код.

Уязвимости

Java входит в топ языков программирования с наибольшим количеством обнаруженных уязвимостей (хотя безусловным лидером является язык C с 47% всех уязвимостей). Но значит ли это, что такие языки менее безопасны?

При оценке таких рейтингов важно учитывать возраст языка, объем написанного на нем кода и активную работу сообщества над выявлением проблем безопасности. Java — один из самых популярных языков программирования в мире с 28-летней историей. Логично предположить, что за 28 лет существования в Java идентифицировали больше уязвимостей, чем, например, в Go, вышедшем в 2009 году.

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

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

Соответственно, ответственность за проверку приложения на безопасность лежит на самих разработчиках, ИБ-экспертах и DevSecOps-специалистах.

Как проверить Java-приложение на безопасность

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

• Используйте статический анализ, фаззинг-тестирование и пентесты для всестороннего анализа кода на предмет уязвимостей и неожиданного поведения.
• Устанавливайте пакеты ПО только из проверенных источников и никогда не внедряйте в проект зависимости, если невозможно подтвердить их подлинность.
• Регулярно обновляйте Java-рантайм, фреймворк и зависимости, чтобы вовремя устранять обнаруженные уязвимости. Если вы используете контейнеры, их тоже необходимо обновлять (это касается и базового образа операционной системы).
• Используйте спецификацию программного обеспечения (Software Bill of Materials, SBOM). SBOM представляет собой перечень всех зависимостей, использованных при создании программного продукта. Поскольку Java-приложения строятся в основном на опенсорсных зависимостях, SBOM позволяет контролировать их версии и уязвимости, помогая команде оперативно идентифицировать и реагировать на проблемы безопасности.

Использование этих практик позволит поддерживать безопасность Java-приложений на оптимальном уровне и существенно снизить риск скрытых уязвимостей.

Но что если вы разрабатываете приложение для КИИ, ГИС или финтеха? Тогда этих мер будет недостаточно, и вам понадобятся дополнительные решения, которые мы рассмотрим в следующем разделе.

Языки программирования и требования законодательства к информационной безопасности

В соответствии с требованиями законодательства РФ все объекты критической информационной инфраструктуры, государственных информационных систем и финтех-системы должны быть переведены на российское ПО до 1 января 2025 года, при этом программное обеспечение должно

• Входить в Единый реестр российского ПО или Единый реестр евразийского ПО,
• Иметь подтвержденную совместимость минимум с двумя отечественными операционными системами,
• Поддерживаться отечественным поставщиком.

Эти требования также распространяются на языки программирования, потому что здесь речь идет уже о безопасности платформы и коммерческой поддержке для оперативного устранения проблем безопасности и критических багов. В этой ситуации у Java есть существенное преимущество в виде доверенного рантайма Axiom JDK Pro, который:

• Разрабатывается в соответствии с промышленным процессом безопасной разработки и поддерживается российской командой инженеров,
• Входит в реестр российского ПО,
• Совместим с российскими ОС, СУБД и облаками,
• В связке с сервером приложений Libercat, реализующим спецификации Java EE / Jakarta EE и также входящим в реестр, представляет собой комплексное решение для импортозамещения Java-стека,
• Имеет специальную версию Axiom JDK Certified, сертифицированную ФСТЭК по 4 уровню доверия (УД) — 3 ГБ верифицированного кода и 10 человеко-лет разработки. Версия включает в себя оптимизированный сборщик мусора, зануляющий память и тем самым уменьшающий поверхность атаки. «Лаборатория Касперского» выбрала Axiom JDK Certified в качестве доверенной среды функционирования своих продуктов.

В текущих условиях рынка использование доверенного Java-рантайма позволит не только повысить безопасность разработки благодаря регулярным обновлениям, поддержке 24/7 и экстренным патчам, но и выполнить нормативно-правовые требования. Даже если ваше приложение написано на другом языке, недавний кейс перехода крупного российского банка РФ с .NET на Java подтверждает, что миграция не только осуществима, но и оправдана.

Заключение

С точки зрения архитектуры Java, как и любой другой язык, нельзя назвать небезопасным. Но разработчикам важно понимать, какие фичи связаны с наибольшим риском написания уязвимого кода, а также регулярно обновлять пакеты, которые они используют в своем проекте для своевременного устранения известных проблем безопасности.

Однако самостоятельного контроля безопасности кода недостаточно в свете последних требований законодательства — ИТ-команды объектов КИИ, ГИС и финтеха должны использовать только программное обеспечение с подтвержденным отечественным происхождением и коммерческой поддержкой на территории РФ. В таком случае Java будет наиболее оптимальным выбором в качестве фундамента разработки благодаря наличию доверенного рантайма Axiom JDK Pro.

Свяжитесь с нами, и инженеры проведут технологический митап для вашей команды, предоставят демо-версию продуктов и помогут с миграцией!