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

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

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

Маршруты в OpenAPI:

YAML
Copy
/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 программный оболочку. Авторизатор Lambda проверял JWT на соответствие Cognito и возвращал политику IAM. При этом авторизатор запускался для каждого запроса, но HTTP программный оболочку одновременно определял, существует ли этот маршрут и разрешает ли его авторизатор, и эти два уровня «не совпадали».

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

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

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

Но /v1/accounts/ не обращался к фиктивной интеграции, а к реальному бэкенду. Жадное сопоставление программный интерфейс 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 программный оболочку (более строгий поиск по пути).