1. Понятно, что нагрузка выполняется во время вызова метода readObject(). А что случится при попытке приведения внедренного злоумышленником объекта к классу MyClass?
MyСlass obj = oin.readObject();
Получается, здесь может вылететь Exception, если десериализованный объект не удастся привести к типу MyСlass?
2. Все равно не могу осознать часть про подпись.
Объект проходит сериализацию/десериализацию только на сервере
Мне все время казалось, что в данном случае главный смысл сериализации — это преобразование объектов в форму, удобную для передачи по сети клиенту. То есть клиент проводит какие-то расчеты/операции, записывает результаты в экземпляр класса и отправляет сгенерированный/модифицированный объект на сервер.
Если подписать объект на сервере, а потом переслать клиенту, то мы гарантируем подлинность объекта, но лишаем при этом клиента возможности как-то модифицировать объект (меняется объект => меняется подпись). А в чем смысл передавать на клиент неизменяемые объекты?
3. Также непонятно, почему хранение объектов в сессии обезопасит схему. Клиент же должен иметь возможность модифицировать объект для отправки данных на сервер!
Единственный вариант, который позволяет мне объяснить происходящее, такой: в серверном приложении PayPal есть класс, который используется этим приложением (и только им). Для каждой пользовательской сессии генерируется свой экземпляр такого класса, но клиент не изменяет этот объект напрямую — всю обработку ведет серверное приложение. И несмотря на то, что клиенту абсолютно не нужен доступ к этому экземпляру класса, разработчики PayPal решили хранить этот объект в качестве одного из параметров запроса.
Такой вариант вроде бы объясняет происходящее, но…
Мало с этим работал, каюсь. Но все равно не очень понятно, почему так.
Я все время себе представлял сериализацию/десереализацию как простое преобразование в формат, удобный для хранения. Я допускаю, что в Java реализован механизм, при котором каждый класс может определить свой метод сериализации/десериализации, который будет наиболее удобен для хранения данных экземпляра этого класса. Понятно, что этот метод будет вызываться при десериализации.
Но не понимаю, как получается на базе этого провести атаку. Сервер не проверяет подпись => мы можем загрузить экземпляр класса любого типа => мы загружаем экземпляр класса заданного типа, который позволяет выполнить произвольную команду при вызове метода readObject — так, что ли?
Еще более непонятно, в чем отличие варианта, когда сервер проверяет подпись. Если файл динамически генерируется и подписывается клиентом, то что помешает злоумышленнику точно так же подписать свой класс с вредоносной нагрузкой и отправить его на сервер?
Насколько я помню, получить имя файла можно не всегда. Например, RAR-архив с установленной опцией «Шифровать имена файлов» нельзя просмотреть, не зная пароль. ZIP-архив, вложенный в запароленный ZIP-архив, также открыть не получится (по крайней мере Проводником).
А можете рассказать, почему именно ремантадин?
Коллега на позапрошлой работе мне тоже его рекомендовал, а в аптеке недавно ингаверин советовали… Что выбрать?
И еще хотел спросить:
накатить ремантадин сразу, лучше от начала возможного контакта
Мы же в городе живем, тут каждый день кто-нибудь рядом кашляет… Каждый день пить, что ли?)
Подскажите, а сам DGA не разбирали? Есть в нем привязка к каким-то дням, времени, еще чему-то?
:-(
1. Понятно, что нагрузка выполняется во время вызова метода
readObject(). А что случится при попытке приведения внедренного злоумышленником объекта к классу MyClass? Получается, здесь может вылететь Exception, если десериализованный объект не удастся привести к типу MyСlass?2. Все равно не могу осознать часть про подпись.Мне все время казалось, что в данном случае главный смысл сериализации — это преобразование объектов в форму, удобную для передачи по сети клиенту. То есть клиент проводит какие-то расчеты/операции, записывает результаты в экземпляр класса и отправляет сгенерированный/модифицированный объект на сервер.
Если подписать объект на сервере, а потом переслать клиенту, то мы гарантируем подлинность объекта, но лишаем при этом клиента возможности как-то модифицировать объект (меняется объект => меняется подпись). А в чем смысл передавать на клиент неизменяемые объекты?
3. Также непонятно, почему хранение объектов в сессии обезопасит схему. Клиент же должен иметь возможность модифицировать объект для отправки данных на сервер!
Единственный вариант, который позволяет мне объяснить происходящее, такой: в серверном приложении PayPal есть класс, который используется этим приложением (и только им). Для каждой пользовательской сессии генерируется свой экземпляр такого класса, но клиент не изменяет этот объект напрямую — всю обработку ведет серверное приложение. И несмотря на то, что клиенту абсолютно не нужен доступ к этому экземпляру класса, разработчики PayPal решили хранить этот объект в качестве одного из параметров запроса.
Такой вариант вроде бы объясняет происходящее, но…
Я все время себе представлял сериализацию/десереализацию как простое преобразование в формат, удобный для хранения. Я допускаю, что в Java реализован механизм, при котором каждый класс может определить свой метод сериализации/десериализации, который будет наиболее удобен для хранения данных экземпляра этого класса. Понятно, что этот метод будет вызываться при десериализации.
Но не понимаю, как получается на базе этого провести атаку. Сервер не проверяет подпись => мы можем загрузить экземпляр класса любого типа => мы загружаем экземпляр класса заданного типа, который позволяет выполнить произвольную команду при вызове метода
readObject— так, что ли?Еще более непонятно, в чем отличие варианта, когда сервер проверяет подпись. Если файл динамически генерируется и подписывается клиентом, то что помешает злоумышленнику точно так же подписать свой класс с вредоносной нагрузкой и отправить его на сервер?
Что-то я не врубаюсь.)
Коллега на позапрошлой работе мне тоже его рекомендовал, а в аптеке недавно ингаверин советовали… Что выбрать?
И еще хотел спросить:
Мы же в городе живем, тут каждый день кто-нибудь рядом кашляет… Каждый день пить, что ли?)
Скриншот надежнее.)