Марк Реинхольд (Mark Reinhold (https://mreinhold.org/)), главный архитектор платформы Java, считает (https://www.infoworld.com/article/3275924/java/oracle-plans-...), что добавление в 1997 году в язык Java поддержки сериализации объектов было ужасной ошибкой, которую приходится расхлёбывать в виде всё вновь и вновь всплывающих критических уязвимостей (https://www.opennet.dev/opennews/art.shtml?num=47139) в различных продуктах на Java. По мнению Реинхольда от трети до половины всех уязвимостей в Java-проектах связаны с сериализацией, которая в силу простоты применения для решения многих задач провоцирует разработчиков на необдуманное использование.
Из соображений безопасности в долгосрочной перспективе Oracle планирует прекратить встроенную поддержку сериализации (кодирование объектов в последовательность байт для их сохранения или передачи), предложив в качестве замены компактный фреймворк. Во фреймворке будет обеспечена возможность безопасной сериализации Java-версии классов данных и графов записей, с возможностью манипуляции сериализированными данными в форматах JSON и XML. План будет реализован в рамках проекта Amber (http://openjdk.java.net/projects/amber/), сфокусированного на продвижении новых возможностей языка.URL: https://www.infoworld.com/article/3275924/java/oracle-plans-...
Новость: https://www.opennet.dev/opennews/art.shtml?num=48666
Решились, наконец.
Нужны более радикальные меры:"Oracle планирует убрать из Java встроенную поддержку Java"
У них, кстати, серьезные конкуренты. Вон, гному целый миллион подогнать хотят. Уж сколько они повыпиливают за эти деньги...
Хорошей дорогой идём, товарищи.
Надеюсь, первыми они выпилят экстеншены, так, чтобы ни люди ни Canonical не смогли использовать гном.
> "Oracle планирует убрать из Java встроенную поддержку Java"я тоже сначала так и прочитал -- и ппц обрадовался же! :-)
а когда посмотрел повнимательнее увидил сирилизацию
>Oracle планирует прекратить встроенную поддержку сериализации, предложив в качестве замены защищённый компактный фреймворк.А что мешает встроенную реализацию сделать компактной и защищённой? Как по мне это просто перекладывание ответственности в стиле маркетологов: ошибки останутся, но теперь они формально будут не в Ява, а в каком-то там отдельном фреймворке.
У встроенной стандартизированные формат и поведение
Это не проблема: вводится новый формат, старый объявляется deprecated и через несколько версий выбрасывается. Стандартная практика.
Если чуточку внести изменения в этот план, то получится EEE - https://ru.wikipedia.org/wiki/Embrace,_Extend,_and_Extinguish
Оракл расширит и поглатит свою же джаву?
Диванным конспирологам настоятельно рекомендуется - покурить матчасть (если асилят):Тед Ньювард - "Пять вещей, которые вы не знали о... сериализации Java-объектов. Вы думали, что сериализованные данные в безопасности? Подумайте еще раз."
https://www.ibm.com/developerworks/ru/library/j-5things1/ind...Еще в 2011 написано.
Необходимость поддержки обратной совместимости.
А выбрасывание функциональности и перенос её во внешние фреймворки да ещё и с изменением формата не нарушает обратную совместимость?
Нарушает, но ты то предлогаешь изменить поведение стандартных классов и методов.
А как определять какой из них как работает? По System.getProperty("java.version") или как?
Обновили на компьютере ждаву, программа загружает уже сохраненные данные с диска, а там внезапно формат другой, и что будет?
implements SerializableNew
Мы разработаваем новый легковесный фреймворк для сериализации. Проект называется Amber, а маркерным интерфейсом для него будет SerializableNew
class MyClass implements Serializable2 {
static final long serialVersionUID2 = 1L;
}
Сохранить безопасный функционал, а опасный явно пометить как таковой, отключить по умолчанию, и предоставлять только для старого байткода или при установке флага.Можно подумать, что большинство фреймворков сериализации безопасны! Parcelable в Андроиде был создан чтобы повысить производительность сериализации, но в плане выполнения произвольного кода наступил на те же грабли. А загрузка левых классов по сети это вообще классическая проблема eval() — при чём здесь сериализация, если RMI, или что там ещё, написано через ж**у? Если создатели языка не в состоянии исправить свой функционал, пользователи будут использовать сторонние либы, которые в итоге наступят на те же грабли.
Скорее всего его не выкинут из jvm вообще. Для программ использующих старый api будет доступна сериализация, а новый нет.
Собственно вот и решение, пиши на Java 8-10 и не ной.
Так этож оракл, они сделают этот отдельный фреймворк платным и по подписке
Универсальная сериализация по определению не может быть защищенной.
Это еще почему?
Вы все Rest api на базе JSON уже взломали?
Без удаления не щмогли исправить....
Кто может гарантировать, что люди, написавшие ранее кривой код как часть жабы, теперь напишут ровный код уже как фреймворк?
В новости речь о кривом коде как части приложений. Он кривой, потому что неправильно использует определённую функциональность жабы, которую планируют убрать, чтобы больше не провоцировать разработчиков кривых приложений.
дух времени: хотим искоренить убийства - уничтожим все ножи!
> дух времени: хотим искоренить убийства - уничтожим все ножи!На майских праздниках двоих по пьянке забили насмерть табуреткой.
Табуретки искореним тоже?
> которая в силу простоты применения для решения многих задач провоцирует разработчиков на необдуманное использование.Т.е. новый фреймворк будет труден в использовании и разработчики вдруг начнут думать?
Так вся жаба об ограничении возможностей, так и создавалась
а чё сегодня 1-е апреля?
> которая в силу простоты применения для решения многих задач провоцирует разработчиков на необдуманное использование.иными словами, рукожопость _отдельных_ недопрограммистов компенсируют тем, что убирают важные фичи языка и инфраструктуры.
А как они собираются сериализовать графы с циклами в JSON и какая чудесная будет производительность - ещё предстоит посмеяться.
Нет в этой фиче нифига важного. Вопрос в том, насколько они поломают обратную совместимость. А насчет графов Serializable тоже нифига предложить не может (т.е. зацикливание будет).
С графами объектов стандартный механизм сериализации в java без проблем работает. Лишь бы хрень какую-нибудь написать.
Если граф с циклами, будет циклить. Граф != дерево.
JSON прекрасно поддерживает циклические связи (введением внутреннего ID). Мне другое интересно: как вообще посторонняя функциональность может быть "небезопасной для языка"? Хоть бы одну "уязвимость" написали! Тот же JSON - он существует. И работает. И ни одного репорта "это опасно!". В чём соль??
Тут про эти ваши безопасные сериализаторы xml и json https://www.github.com/mbechler/marshalsec/blob/master/marsh...
> Тут про эти ваши безопасные сериализаторы xml и json https://www.github.com/mbechler/marshalsec/blob/master/marsh...
>jsonЖусон* то причем? В жусоне ПРИНИПИАЛЬНО нет встроенной возможности задания исполняемого кода, там только строки, массивы, числа, да объекты(хеш-таблицы).
Другое дело если туповатый десериализатор начинает интерпретировать вышеперечисленное как исполняемых код.
Например в Java, где при десериализации хештаблицы вызывается метод hash() пользовательских объектов, где может быть произвольный код.
(да, по мнению изобретателя JSON - Д. Крокфорда, название формата произносится именно так)
> Например в Java, где при десериализации хештаблицы вызывается метод hash() пользовательских
> объектов, где может быть произвольный код.тоесть java десерилизует функции экземпляра объекта не на основе кода класса из заголовка потока, а на основе байткода функции из потока ??
//offtop
> (да, по мнению изобретателя JSON - Д. Крокфорда, название формата произносится именно так)"Жусон" - жесть то какая...
Ты можешь сериализовать любую имплементацию интерфейса. Система, на которой производится десериализация, может вообще не знать ничего об этой имплементации. По сути, сериализованный объект - это данные плюс поведение. Если нужны только данные, то есть "универсальные конвертеры" в JSON, XML и любые другие форматы. Если же нужно принимать именно реализацию - то обычно пользуются стандартной сериализацией. Это удобно. Но нужно понимать, что либо ты организовываешь безопасность получения этого кода, гарантируя, что посторонний код не может быть загружен. Либо обвешиваешься политиками безопасности.
А ЭЦП никак сюда не прикрутить?
Вы неправы!Вы не можете сериализовать интерфейс. Сериализуется объект, реализующий интерфейс. В поток записывается полное название класса этого объекта и данные полей. Если поле - это ссылка на другой объект, то описанная процедура выполняется и для него. Если поле ссылается на уже записанный в поток объект (циклическая ссылка), то пишется информация об этом.
При десериализции объекты восстанавливаются по полному названию классов. При этом классы эти могут быть совершенно другими (с другим набором методов и даже с реализацией совершенно других интерфейсов).
Таки образом, поведение не сериализуется! Проверено на практике
> Например в Java, где при десериализации хештаблицы вызывается метод hash() пользовательских
> объектов, где может быть произвольный код.В этом виновата не стандартная сериализация, а реализация класса HashMap. Там есть метод readObject, котором написана своя процедура десериализации, точно некоторые действия после стандартной десериализации
Я правильно понимаю, что все приложения под старыми версиями явы как работали, так и будут работать дальше, а вот при переходе на новые версии явы разработчики должны будут не забыть озаботиться заменой сериализации?
> Я правильно понимаю, что все приложения под старыми версиями явы как работали,
> так и будут работать дальше, а вот при переходе на новые
> версии явы разработчики должны будут не забыть озаботиться заменой сериализации?95% что да
вероятно в жавамашине будет "если версия скомпиленного байткода > N - запрещай старое
Хаха. Ничего "безопаснее", чемfopen();
fwrite();
fclose();так и не смогли придумать ;)
Короче мы облажались и ничего поправить немОгем.