«Дифференциал парсеров»: как разница в обработке входных данных ведет к уязвимости

Исследование со сложным названием «дифференциал парсеров» несет простую идею: если в системе два и более обработчика (например, JSON или YAML) по-разному обрабатывают одни и те же данные, то жди беды. Автор приводит несколько сценариев атак.

✨ Удаленное выполнение кода в CouchDB. Эта система БД написана на Erlang и использует JavaScript для валидации документов. При получении JSON с дублирующимися параметрами (например, два параметра “roles”) библиотека Erlang превращала их в массив и использовала первое встречное значение. А движок JavaScript брал только последнее значение из этого массива. Атакующий передавал два значения параметра “roles”, JS-движок видел безопасное значение и передавал дальше, а Erlang видел первое значение (_admin) и создавал привилегированную учетную запись.

Сценарий очень напоминает класс уязвимостей HTTP Parameter Pollution, да?

✨ Произвольная запись файлов. Разница парсеров Ruby и Go позволяла редиске обходить фильтр опасных параметров в YAML-файлах. Ruby-часть не фильтровала опасный параметр parent, а вот Go-парсер его видел. Атакующий успешно протащил запрещенный параметр мимо фильтров и смог записывать произвольные файлы в систему.

Как разработчику можно защититься от этой проблемы: на уровне архитектуры проекта не пересылай сырые данные от одного парсера к другому и используй принцип «передаю то, что понимаю». Проведи инвентаризацию всех парсеров, которые используются в твоей системе: с помощью SCA составь список библиотек, занимающихся парсингом, и с помощью SAST определи путь «сырых» входных данных. Попроси своего appsec-товарища изучить эту атаку и настроить DAST.

@makrushin l MAX l VK