Как проверить объект перед десериализацией

Question

В моем коде я вызываю метод getObject() из объекта ObjectMessage, полученного из очереди JMS. Отчет Fortify жалуется на этот метод getObject() с таким именем ошибки Dynamic Code Evaluation: Unsafe Deserialization. В основном это говорит о том, что я не должен десериализовать ненадежные данные без проверки содержимого потока объектов. Ниже приведен код. Как и какие методы я должен использовать, чтобы избавиться от этой ошибки отчета Fortify.

if (message instanceof ObjectMessage) { 
    ObjectMessage objMessage = (ObjectMessage) message; 
    Object objReportMessage = objMessage.getObject(); 
.... 

Вот приведенная проблема с подтверждением с рекомендациями. Затем он указывает эту ошибку на код выше в строке objMessage.getObject();

Динамического код Оценка: Опасная десериализация (1 выпуск)

Аннотация десериализация контролируемого пользователем объекта потоки во время выполнения может позволить злоумышленнику выполнить произвольный код на сервера, логике приложения злоупотребления или привести к отказу в оказание услуг.

Объяснение Java-сериализации превращает объект графики в потоки байтов, содержащих объекты себя и необходимые метаданные, чтобы восстановить их из потока байтов. Разработчики могут создавать собственный код, чтобы помочь в процессе десериализации объектов Java, где они могут даже заменить десериализованные объекты разными объектами или прокси. Индивидуальный процесс десериализации происходит во время объектов реконструкции до того, как объекты будут возвращены в приложение и применены к ожидаемым типам. К моменту разработчики пытаются обеспечить соблюдение ожидаемого типа, возможно, код уже выполнен. Индивидуальные процедуры десериализации определены в сериализуемых классах, которые должны присутствовать в пути к классам времени выполнения и не могут быть введены злоумышленником, поэтому их использование зависит от классов, доступных в прикладной среде. К сожалению, обычные классы сторонних разработчиков или даже классы JDK могут использоваться для извлечения ресурсов JVM, разворачивания вредоносных файлов или запуска произвольного кода. Некоторые протоколы используют сериализацию Java за кулисами в транспортном уровне. RMI и JMX являются примерами этих протоколов.

Пример 1: Ниже приведен пример интерфейса RMI, который может публиковаться публично, содержащий методы с одним или несколькими параметрами . При удалении этих методов удаленно аргументы будут десериализованы на сервере , что позволяет злоумышленникам вводить графики вредоносных объектов.

public interface MyService extends java.rmi.Remote { 
public Object doSomething (Object arg0) throws RemoteException; 
public Object doSomethingElse (Object arg0, Object arg1) throws 
RemoteException; 
... 
} 

Пример 2: JMX MBeans также используют Java сериализации для передачи аргументов вызова. В приведенном ниже примере методы класса MyManagedBean будут доступны клиентам.

MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); 
ObjectName name = new ObjectName("com.example:type=MyManagedBean"); 
MyManagedBean mbean = new MyManagedBean(); 
mbs.registerMBean(mbean, name); 

Рекомендация Если возможно, не десериализации ненадежных данных без проверки содержимого потока объекта. Для того, чтобы проверить десериализацию классов, следует использовать шаблон десериализации. В потоке объектов сначала будут содержаться метаданные описания класса, а затем сериализованные байты их полей полей . Процесс сериализации Java позволяет разработчикам прочитать описание класса и принять решение о том, следует ли продолжать десериализацию объекта или прервать его. Чтобы сделать это, необходимо, чтобы подкласс java.io.ObjectInputStream и обеспечить пользовательскую реализацию метода decall-решения (ObjectStreamClass desc), где проверка и проверка класса должны быть 29 сентября 2016 года, 17:09 Copyright 2015 Hewlett Packard Разработка предприятия LP 13 . Существуют существующие реализации шаблона поиска, который можно легко использовать, например Apache Commons IO (org.apache.commons.io.serialization.ValidatingObjectInputStream). Всегда используйте строгий белый список, чтобы использовать только десериализованные ожидаемые типы. Подход черного списка не рекомендуется , так как злоумышленники могут использовать многие доступные гаджеты для обхода черного списка. Кроме того, имейте в виду , что, хотя некоторые классы для выполнения кода являются общеизвестными, могут быть и другие, которые являются неизвестными или нераскрытыми, поэтому всегда будет предпочтительным использование белого списка. Любой класс, разрешенный в белом списке , должен быть проверен, чтобы убедиться, что он безопасен для десериализации. Чтобы избежать атак типа «отказ в обслуживании», рекомендуется переопределить метод objectObject (Object obj), чтобы подсчитать, сколько объектов десериализуется и прервать десериализацию, когда предел превышен. Когда десериализация происходит в библиотеке или каркасе (например, при использовании JMX, RMI, JMS, HTTP Invokers) вышеприведенная рекомендация не полезна, так как она находится за пределами контроля разработчика. В этих случаях вы можете: хотите убедиться, что эти протоколы отвечают следующим требованиям: - Публикация не публиковалась. - Использовать аутентификацию. - Используйте проверки целостности. - Используйте шифрование. Кроме того, HPE Security Fortify Runtime обеспечивает элементы управления безопасностью, которые будут применяться каждый раз, когда приложение выполняет десериализацию из ObjectInputStream, защищая как код приложения, так и , а также код библиотеки и фреймворка от этого типа атаки.

Answer 1

Посмотрите на ValidatingObjectInputStream. В основном вы белеете классы, которые вы позволите быть десериализованными (вы должны знать их на основе информации, которую вы втягиваете). Затем валидатор проверяет метаданные на сериализованные данные и отклоняет любые классы, которые не входят в белый список.

Answer 2

Если вы посмотрите часть советов из рекомендаций, в нем говорится, что проблема будет сообщена, даже если реализован объектный ObjectInputStream. Поэтому, даже если бы вы смогли исправить проблему, вы не избавитесь от поиска.

Однако, похоже, что ваш код использует JMS и с JMS, вы не контролируете десериализацию. Это признается рекомендациями скопированных и вставленных:

Когда десериализации происходит в библиотеке, или рамки (например, при использовании JMX, RMI, JMS, HTTP Invokers) выше рекомендации не является полезной, поскольку она находится за пределами контроль разработчика. В таких случаях вы можете убедиться, что эти протоколы отвечают следующим требованиям:

• Публикация не публиковалась.
• Использовать аутентификацию.
• Используйте проверки целостности.
• Использовать шифрование.

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