В данной статье рассмотрим уязвимость на основе подмены сериализованного Java-объекта ViewState и метод её эксплуатации на примере web-приложения виртуальной машины с HackTheBox, использующей технологию Apache MyFaces.
Рубрика «сериализация» - 2
Apache, ViewState&Deserialisation
2019-09-25 в 12:01, admin, рубрики: Apache, cybersecurity, java, security, безопасность, Блог компании T.Hunter, информационная безопасность, сериализация, сериализация сложного объекта, уязвимость
Как мы нашли критичную уязвимость AspNetCore.Mvc и перешли на собственную сериализацию
2019-01-10 в 11:41, admin, рубрики: AspNetCore.Mvc, Блог компании Retail Rocket, оптимизация производительности, Программирование, сериализация, уязвимостьПривет!
В этой статье мы хотим поделиться нашим опытом в оптимизации производительности и исследовании особенностей AspNetCore.Mvc.
Предыстория
Несколько лет назад на одном из наших нагруженных сервисов мы заметили существенное потребление ресурсов CPU. Это выглядело странно, так как задачей сервиса было фактически взять сообщение и переложить его в очередь, предварительно произведя над ним некоторые операции, такие как валидация, дополнение данными, и т.п.
В результате профилирования мы обнаружили, что большую часть процессорного времени “съедает” десериализация. Мы выкинули стандартный сериализатор и написали свой на Jil, в результате чего потребление ресурсов снизилось в разы. Все работало как нужно и мы успели об этом позабыть.
Читать полностью »
Protobuffers — это неправильно
2018-10-22 в 8:08, admin, рубрики: java, Protobuffers, protocol buffers, XML, Микроформаты, Разработка веб-сайтов, сериализация, статическая типизацияЗначительную часть своей профессиональной жизни я выступаю против использования Protocol Buffers. Они явно написаны любителями, невероятно узкоспециализированы, страдают от множества подводных камней, сложно компилируются и решают проблему, которой на самом деле нет ни у кого, кроме Google. Если бы эти проблемы протобуферов остались в карантине абстракций сериализации, то мои претензии на этом и закончились бы. Но, к сожалению, плохой дизайн Protobuffers настолько навязчив, что эти проблемы могут просочиться и в ваш код.
Узкая специализация и разработка любителями
Остановитесь. Закройте свой почтовый клиент, где уже написали мне полписьма о том, что «в Google работают лучшие в мире инженеры», что «их разработки по определению не могут быть созданы любителями». Не хочу этого слышать.
Давай просто не будем обсуждать эту тему. Полное раскрытие: мне доводилось работать в Google. Это было первое (но, к сожалению, не последнее) место, где я когда-либо использовал Protobuffers. Все проблемы, о которых я хочу поговорить, существуют в кодовой базе Google; это не просто «неправильное использование протобуферов» и тому подобная ерунда.
Читать полностью »
Темная сторона TypeScript — @декораторы на примерах
2016-10-18 в 11:52, admin, рубрики: injection, javascript, TypeScript, Блог компании ДоксВижн, декораторы, метаданные, примеры кода, Программирование, Разработка веб-сайтов, сервисы, сериализация, устройствоДекораторы — это невероятно круто. Они позволяют описывать мета информацию прямо в объявлении класса, группируя все в одном месте и избегая дублирования. Ужасно удобно. Однажды попробовав, вы уже никогда не согласитесь писать по-старому.
Однако, несмотря на всю полезность, декораторы в TypeScript (заявлены также на стандарт) не так просты, как хотелось бы. Работа с ними требует навыков джедая, так как необходимо разбираться в объектной модели JavaScript (ну, вы поняли, о чем я), API несколько запутанный и, к тому же, еще не стабильный. В этой статье я немного расскажу об устройстве декораторов и покажу несколько конкретных приемов, как поставить эту темную силу на благо front-end разработки.
Помимо TypeScript, декораторы доступны в Babel. В этой статье рассматривается только реализация в TypeScript.
JSON-сериализатор на быстрых шаблонах
2016-09-29 в 9:07, admin, рубрики: c++, highload, inline, json, высокая производительность, метапрограммирование, оптимизация, Программирование, сериализация, списки типов
В чем проблема текстовых форматов обмена данными? Они медленные. И не просто медленные, а чудовищно медленные. Да, они избыточны, по сравнению с бинарными протоколами и, по идее, текстовый сериализатор должен быть медленнее примерно на столько же, на сколько он избыточен. Но на практике получается, что текстовые сериализаторы иной раз на порядки уступают бинарным аналогам.
Я не буду рассуждать о преимуществах JSON перед бинарными форматами — у каждого формата есть своя область применения, в которой он хорош. Но зачастую мы вынуждены отказываться от чего-то удобного в пользу не очень комфортного в силу катастрофической неэффективности первого. Разработчики отказываются от JSON, даже если он прекрасно подходит для решения задачи, только из-за того, что он оказывается узким местом в системе. Конечно же, виноват не JSON сам по себе, а реализации соответствующих библиотек.
В этой статье я расскажу не только о проблемах парсеров текстовых форматов вообще и JSON в частности, но и о нашей библиотеке, которую мы используем уже много лет в самых высоконагруженных проектах. Она настолько нас устраивает и в плане быстродействия, и в плане удобства использования, что порой отказываемся от бинарного формата там, где бы он больше подошел. Конечно же, я имею в виду некие пограничные условия, без претензий на все случаи жизни.
Пишем сериализатор для сетевой игры на C++11
2016-06-15 в 20:14, admin, рубрики: c++, c++11, perfect forwarding, variadic templates, ненормальное программирование, Программирование, сериализация
Написать этот пост меня вдохновила замечательная статья в блоге Gaffer on Games «Reading and Writing Packets» и неуёмная тяга автоматизировать всё и вся (особенно написание кода на C++!).
Начнём с постановки задачи. Мы пишем сетевую игру (и сразу MMORPG, конечно же!), и независимо от архитектуры у нас возникает необходимость постоянно посылать и получать данные по сети. У нас, скорее всего, возникнет необходимость посылать несколько разных типов пакетов (действия игроков, обновления игрового мира, просто-напросто аутентификация, в конце концов!), и для каждого у нас должна быть функция чтения и функция записи. Казалось бы, не вопрос сесть и написать спокойно эти две функции и не нервничать, однако у нас сразу же возникает ряд проблем.
- Выбор формата. Если бы мы писали простенькую игру на JavaScript, нас бы устроил JSON или любой его самописный родственник. Но мы пишем серьёзную многопользовательскую игру, требовательную к трафику; мы не можем позволить себе отправлять ~16 байт на float вместо четырёх. Значит, нам нужен «сырой» двоичный формат. Однако, двоичные данные усложняют отладку; было бы здорово, если бы мы могли менять формат в любой момент, не переписывая целиком все наши функции чтения/записи.
- Проблемы безопасности. Первое правило сетевой игры: не доверяй данным, присланным клиентом! Функция чтения должна уметь оборваться в любой момент и вернуть
false, если что-то пошло не так. При этом использовать исключения считается неважной идеей, поскольку они слишком медленные. Мамкин хакер пусть и не сломает ваш сервер, но вполне может ощутимо замедлить его беспрерывными эксепшнами. Но вручную писать код, состоящий из if'ов и return'ов, неприятно и неэстетично. - Повторяющийся код. Функции чтения и записи похожи, да не совсем. Необходимость изменить структуру пакета приводит к необходимости поменять две функции, что рано или поздно приведёт к тому, что вы забудете поменять одну из них или поменяете их по-разному, что приведёт к трудно отлавливаемым багам. Как справедливо замечает Gaffer on Games, it is really bloody annoying to maintain separate read and write functions.
Всех интересующихся тем, как Бендер выполнил своё обещание и при этом решил обозначенные проблемы, прошу под кат.
Читать полностью »
Простой и не очень очевидный способ повесить chrome, firefox и nodejs внутри нативной функции
2016-03-16 в 12:34, admin, рубрики: javascript, V8, заметки, криворукость, сериализацияВот весь код: var x = []; x[0x7fffffff]=1; JSON.stringify(x);
Для желающих попробовать: jsfiddle
Таким незамысловатым способом, можно намертво повесить firefox, довести до падения вкладку хрома и повесить основной поток nodejs.
Самое примечательное в этом то, что зависание происходит на уровне нативного кода функции JSON.stringify, что не позволяет прервать выполнение в том же firefox'е, как это обычно бывает при простом while(true);.
При выполнении внутри WebWorker'а в chrome, страница продолжает отвечать, но terminate не может завершить поток.
Так же по понятным причинам, такой код не обнаруживается jslint'ом.
KTV. Грабли на пути к маршалингу
2016-03-14 в 7:14, admin, рубрики: ktv, swift, маршалинг, разработка мобильных приложений, разработка под iOS, сериализацияЯ писал про KTV, но одно дело — придумать что-то непонятное, другое — попробовать это использовать. Помимо стилевой системы S2 я планирую использовать KTV для работы с сервером вместо JSON. Планов завоевать мир у меня нет, но разобраться, удобнее получилось или нет, хочется. Для того, чтобы общаться было легко, нужно уметь парсить объекты из ktv-файлов, и сериализовывать обратно в них же.
Swift, для которого я это пишу, в настоящий момент (Swift 2.x), не предназначен для динамического парсинга совсем, никак, вообще. Поэтому пришлось придумать что-то немного странное и нестандартное. После чего это странное и нестандартное нужно было реализовать.
В процессе было наступлено на бесчисленное количество граблей, про которые я и расскажу. Возможно, кто-то посмеётся над несмышлёным мной, может, кому-то они помогут избежать аналогичных вещей — не знаю. Мне было разбираться полезно.
Если кто видит, как можно проще или лучше решить указанные задачи, пишите. С удовольствием узнаю ещё варианты, так как все, что перечислены ниже, в той или иной степени — костыли. Вдруг есть что-то более приятное.
Читать полностью »
Сериализация C++ с полиморфизмом и прототипами
2014-12-08 в 16:13, admin, рубрики: c++, c++11, КодоБред, полиморфизм, Программирование, сериализацияУже достаточно давно заинтересовался темой сериализации, а если конкретно, то сериализацией объектов, хранящихся по указателю на базовый класс. Например, если мы хотим загружать интерфейс приложения из файла, то скорее всего нам придется заполнять полиморфными объектами контейнер по типу “std::vector<iWidget*>”. Возникает вопрос, как подобное реализовать. Этим я недавно решил заняться и вот что получилось.
Для начала я предположил, что нам все-таки придется унаследовать в базовом классе интерфейс iSerializable, такого вида:
class iSerializable
{
public:
virtual void serialize (Node node) = 0;
};
Сериализация и С++11
2014-12-04 в 1:19, admin, рубрики: c++, c++11, ненормальное программирование, Программирование, сериализация 
Уверен, что многим кто работает с С++ хотелось, чтобы в этом, дивном языке, была возможность сериализовать объекты так же просто, как скажем в С#. Вот и мне этого захотелось. И я подумал, а почему бы и нет, с помощью нового стандарта это должно быть несложно. Для начала стоит определиться с тем, как это должно выглядеть.
class Test : public Serializable
{
public:
int SomeInt = 666;
float SomeFloat = 42.2;
string SomeString = "Hello My Little Pony";
private:
serialize(SomeInt);
serialize(SomeFloat);
serialize(SomeString);
};
Такое мне вполне подходило, и я уже представлял себе решение.
Читать полностью »