Энтузиаст обошёл аутентификацию AWS API Gateway через завершающий слеш

Энтузиаст рассказал, как он обошёл аутентификацию AWS API Gateway, добавив trailing slash (завершающий слеш, косую черту в конце URL-адреса) в конце. За это он получил вознаграждение в размере $12 000.

«Я изучал мобильный API одной финтех-компании и заметил нечто, что не имело смысла. Запрос GET /v1/accounts возвращал 401. Запрос GET /v1/accounts/ возвращал 200 с полными данными учётной записи. Один символ. Совершенно разный уровень безопасности», — отметил он.

Маршруты в OpenAPI:

YAMLCopy/v1/accounts:  get:    x-amazon-apigateway-integration:      uri: arn:aws:apigateway:.../v1/accounts/{accountId}:  get:    x-amazon-apigateway-integration:      uri: arn:aws:apigateway:...

Энтузиаст выяснил, что API работал на AWS HTTP API — более новой и дешёвой альтернативе REST API. Авторизатор Lambda проверял JWT на соответствие Cognito и возвращал политику IAM. При этом авторизатор запускался для каждого запроса, но HTTP API одновременно определял, существует ли этот маршрут и разрешает ли его авторизатор, и эти два уровня «не совпадали».

«Я запустил ffuf для этого пути. Результаты были… противоречивыми. Шаблон: любой путь, который более-менее соответствовал префиксу маршрута, запускал авторизатор, а затем переходил к интеграции без повторной проверки аутентификации», — пишет автор.

По его словам, HTTP API по умолчанию использует так называемое жадное сопоставление путей. /v1/accounts/ совпал с /v1/accounts в качестве префикса. Авторизатор выполнился и вернул Allow. Затем выполнилась интеграция — но сопоставление интеграции оказалось нечётким. Путь был переписан, контекст аутентификации был потерян, и энтузиаст оказался без действительного JWT.

Он решил отследить маршрут $default в HTTP API. Это универсальный маршрут, который финтех-компания настроила на возврат 404, но в какой-то момент также подключила фиктивную интеграцию для проверки работоспособности. Эта фиктивная интеграция не проверяла аутентификацию — она просто возвращала {«status»: «ok»}.

Но /v1/accounts/ не обращался к фиктивной интеграции, а к реальному бэкенду. Жадное сопоставление API Gateway переписало путь с завершающим слэшем, удалило слэш и перенаправило на интеграцию /v1/accounts. Проверка аутентификации произошла по исходному пути, а интеграция работала по переписанному пути. Таким образом, переписывание отбросило контекст аутентификации.

Энтузиаст подтвердил это с помощью пользовательского заголовка. Авторизатор устанавливает context.authorizer.userId, интеграция считывает его. Когда он обратился к /v1/accounts/, интеграция получила userId: undefined, не проверив userId. Она просто вернула все учётные записи для ключа API — который здесь даже не требовался, поскольку аутентификация должна была быть JWT.

Тот же обходной путь сработал на POST /v1/transfers/. Энтузиаст смог инициировать банковские переводы без действительного JWT.

Бэкенд проверил, что fromAccount принадлежит пользователю, но userId был undefined, поэтому он по умолчанию использовал системную учётную запись. Энтузиаст провёл один тестовый перевод на $0,01, и он прошел.

Тогда автор написал отчёт, приложив скриншоты ошибок 401 и 200, вывод ffuf, точное поведение переписывания пути. Компания исправила это поведение на следующий день, перейдя с HTTP API на REST API (более строгий поиск по пути).