Comments 5
Разработчик который использует YAML для передачи данных заслуживает быть взломанным.
Более неоднозначного для реализации текстового формата еще надо поискать. Одинаковых реализаций нет, все имеют хоть какие-то отклонения от стандарта.
Даже, JSONа, спека которого умещается на салфетке, корректных реализаций дай бог одна на ЯП. Одни игнорируют лишние/отсутствующие запятые, многие поддерживают комментарии итд.
В таких расхождениях реализации стандартов и живут многие уязвимости (HTTP Request Smuggling, URL Parsing Confusion ...). Чем сложнее и запутанее спека, тем больше там спрятано баунти для взломщика.
Обычно хакеры под рукой держат что-то набодобие https://gchq.github.io/CyberChef/ и проблем с анализом никаких нет
главный совет для безопасности вашего сервера — отказаться от десериализации пользовательских данных совсем
Простите, а это как? Бинарных протоколов обмена с браузером не так много, из самого популярного только вебсокеты вспоминаю, но и там по-моему строки гоняются (grpc тоже сериализуется хоть и не в человекочитаемый).
В целом конечно интересно, но а кроме питоновской библиотеки работы с ямлом что-то ещё так же легко даёт доступ к системе?
Если нет, то имхо, совет отказываться от десериализации данных всех видов и на всех языках слишком спекулятивный.
Касательно питновского ямла, спасибо, возьму на заметку, что в нем допустимо указание команд, которые выполняются в системе. Но с json о подобном не слышал (разве что взлом через какие нить хитрые переполнения, но в современный век управляемой памяти это уже не так актуально).
Неужели существуют сайты, во взломе которых есть какой-то интерес, и при этом в которых на бэкэнд можно что-то отправить (не обязательно сериализируемые данные), и это что-то вызовет команду операционной системы??? Вот, ***, последствия советам уборщицам учить питоны :)
Как взломать сервис, в котором используется десериализация данных