При аудите API обнаружены два одинаковых параметра: как проверить, позволяет ли разбор их значений обойти валидацию?
Нужно отправить повторяющийся параметр с разными значениями и сравнить, какое значение видят валидатор, авторизационная логика и бизнес-операция. Уязвимость подтверждается, если проверка анализирует одно значение, а дальнейшая обработка использует другое либо объединяет значения неожиданным способом.
Форматы HTTP-запросов допускают передачу нескольких значений с одним именем параметра. Единое универсальное правило о том, должно ли приложение использовать первое значение, последнее, все значения или отклонять запрос, на уровне прикладной логики отсутствует.
Поэтому сервер, веб-фреймворк, библиотека валидации и бизнес-код могут по-разному интерпретировать один и тот же запрос. Такая несогласованность стала известна как HTTP Parameter Pollution и особенно опасна на границах между компонентами.
Предположим, параметр должен содержать только безопасное значение. Валидатор извлекает первое значение и отклоняет запрещённое, но прикладной обработчик получает последнее значение. В результате защитная проверка формально срабатывает, однако опасное значение всё равно доходит до чувствительной операции.
Обратная ошибка также возможна: проверяется последнее значение, а функция авторизации или журналирование используют первое. Последствия зависят от точки применения: обход фильтра, изменение целевого объекта, подмена значения в журнале или расхождение между фактически выполненной операцией и записанным событием.
Тест следует строить по цепочке обработки запроса:
Нужно установить не только факт принятия повторного параметра, но и семантику каждого слоя: первое значение, последнее значение, массив значений или ошибка. Особенно важны параметры, влияющие на права, идентификатор объекта, направление операции, путь к ресурсу и значение, проходящее в интерпретатор.
Безопасная политика для скалярного параметра обычно заключается в явном объявлении единственной допустимой кардинальности и отклонении повторов до бизнес-логики. Для параметров-массивов повторы могут быть нормальными, поэтому их нельзя запрещать безоговорочно: нужно явно определить тип, допустимые значения и способ дальнейшей обработки.
Надёжная защита требует единого разбора параметров на границе приложения. Нельзя рассчитывать, что отдельная проверка строки компенсирует различия между компонентами. После нормализации именно тот набор значений, который был проверен, должен передаваться во все последующие слои.
В API фильтр списка принимал параметр статуса. При одном значении сервис отклонял запрещённые статусы, но при двух параметрах валидатор рассматривал только первое значение, а слой построения фильтра объединял все значения. Это позволяло запросить данные по статусу, который должен был быть недоступен.
Рассматривались два варианта. Первый — принимать последнее значение, что сохраняло совместимость с частью существующих клиентов, но оставляло неоднозначность для других компонентов. Второй — поддержать массив явно и отклонять повторение у скалярного поля; этот вариант требовал проверки клиентов, зато устранял различие семантики.
Выбрали второй вариант: контракт API разделил скалярные и многозначные поля, а повторение скалярного параметра стало ошибкой до авторизации и бизнес-обработки. Регрессионные тесты проверили оба порядка значений и соответствие между валидируемыми, применёнными и журналируемыми данными.
1. Достаточно ли проверить только первое и последнее значение? Нет. Разные компоненты могут преобразовать повторяющиеся параметры в массив, объединённую строку или структуру с другой вложенностью. Поэтому нужно проверять фактический контракт конкретного endpoint и наблюдать результат чувствительной операции, а не делать вывод только по HTTP-ответу.
2. Является ли любой повтор параметра уязвимостью? Нет. Повтор может быть предусмотренной моделью массива, например для набора фильтров. Уязвимость возникает при несогласованной кардинальности или различии между тем, что проверяет один слой, и тем, что использует другой. Для намеренно многозначного поля нужно проверять ограничения каждого элемента и совокупного результата.
3. Можно ли устранить риск только общей проверкой входных данных? Нет. Общая проверка может сама выбрать не то значение, которое затем использует обработчик. Требуются единая нормализация, явная схема параметров и передача уже разобранной структуры между слоями. Отдельно следует проверять авторизацию, потому что корректно отфильтрованное значение всё равно не доказывает право пользователя выполнить операцию.