Как определить проблемы десериализации java?

Question

Я хотел бы иметь возможность определить проблемы с десериализацией в Java-коде. Что я должен искать? Например, как определить, пытается ли какой-либо Java-код использовать «java calendar bug»? Обратите внимание, что я не программист на Java, но я понимаю концепции сериализации и ООП. Я пытаюсь выполнить некоторые проверки безопасности (что-то вроде средства предупреждения компилятора).

EDIT: на основе замечаний я хотел бы изменить вопрос немного: я считаю весь код проанализирован «ненадежным», есть способ, как оценить потенциальную опасность? Я имею в виду, могу ли я сказать, что код А более опасен, чем B, в отношении ошибки десериализации? Что я должен искать?

Answer 1

Во-первых, вам нужно понять свой контекст, чтобы определить угрозы безопасности. (Когда я говорю о «доверии», я немного сокращаюсь. Я говорю намеренно злонамеренно.)

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

Если по какой-либо причине сериализованные данные недоверены, то есть еще немного, чтобы рассмотреть. Внутренняя структура воссозданных объектов может быть «необычной». Данные могут быть несовместимыми. У вас могут быть общие изменчивые объекты, которые должны быть отдельными. Дезериализация может вызвать бесконечный цикл или бесконечный цикл, который просто не может быть завершен до жары смерти Вселенной. И, конечно, данные могут быть ложью.

Если вы пишете код библиотеки, который используется менее доверенным кодом, то все становится более интересным:

В случае «календаря ошибка» (и подобные), то есть о deserialising произвольный поток с вредоносными данных и вредоносного кода. В Руководстве по безопасному кодированию Java предлагается выполнить проверки безопасности (используя «Модель безопасности Java2») в пользовательских методах readObject, что подразумевает, что вы не должны вызывать десериализацию с большим доверием, чем код и данные.

Со стороны десериализуемых объектов вещи сложнее. Объекты, предоставленные ObjectInputStream по readObject, readUnshared, defaultReadObject, readFields или просто десериализация по умолчанию может иметь ссылки, захваченные вредоносным кодом, или для не-конечных классов подклассифицироваться злонамеренно. Объект может также использоваться во время десериализации, когда он частично инициализируется. Deserialisation не вызывает «реального» конструктора десериализованного класса (readObject/readObjectNoData - это своего рода псевэ-конструктор, который не может установить final). Это всего лишь кошмар, поэтому вы, вероятно, не хотите, чтобы ваши чувствительные классы были сериализованы.

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

Answer 2

Хм ... ваш вопрос немного общий. Вы взглянули на статью this? Речь идет о алгоритме сериализации Java, но из кеша Google, потому что на данный момент главная страница недоступна.

Answer 3

Я бы подумал, что лучший способ победить код, который использует известные дыры в безопасности на Java, - это обновление до версии Java, которая исправляет ошибку. И следующий лучший способ (чтобы справиться с ошибками, связанными с сериализацией), рассматривает все сериализованные данные из неизвестных/непроверенных/небезопасных источников как подозрительные.

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

(Если были легкие способы, чтобы найти неизвестные дыры в безопасности Java, вы можете поспорить, что ВС и другие исследователи в области безопасности было бы уже использовали их.)

Answer 4

Если вы сериализовать объект Java, чтобы передать его обособленное приложение, почему бы не рассмотреть возможность подписания объекта с ключом, разделяемым между приложениями? Этого должно быть достаточно, чтобы защитить себя от атаки «человек-в-середине».

Возвращаясь к сути проблемы проверки, проверка чрезвычайно сложна для языков общего назначения. Вы должны искать научные публикации по этой теме. Я думаю, что наиболее часто применяемая техника - sandboxing. Второй подход заключается в том, чтобы ограничить язык и запретить выполнение опасных команд, например, Yahoo Caja library использует эту технику.