Аутентификация с помощью API

Разъединение вызывает еще ряд проблем, когда речь заходит об аутентификации и авторизации. Нередко встречаются API, не требующие аутентификации, но есть вероятность, что некоторые веб-сервисы будут требовать, чтобы их клиенты так или иначе проходили аутентификацию.

Так как же нам добиться аутентификации с помощью API? Этот процесс ничем не отличается оттипичного приложения. По сути, аутентификация требует, чтобы вы предоставили что-то, что вы знаете, и при необходимости нечто, что у вас есть, что соответствует записи в базе данных API. Если это секретная информация и только владелец этой информации, по-видимому, имеет к ней доступ,API можетбытьдостаточно уверен,что клиент,предоставляющийданную информацию,получитдоступ.APIтеперьнужнотолько отслеживатьэтого конкретного клиента, поскольку HTTP в данном случае не поможет.

Традиционные веб-приложения будут принимать данные аутентификации (нечто, что вы знаете, вместе с комбинацией имени пользователя и пароля) и могутпотребовать наличия второго фактора (одноразовый пароль,номер SMS или мобильное push-уведомление). Как только вы будете верифицированы, вам выдадут идентификатор сеанса,который ваш браузер передастдля последующих запросов аутентификации через куки-файлы.

API-интерфейсы похожитем,что онитребуют,чтобы какой-либо секретный ключ или токен передавался обратно при каждом запросе, требующем аутентификации.Этоттокен обычно генерируется API и предоставляется пользователю после успешной аутентификации с помощью других средств. В то время как типичное веб-приложение почти всегда использует заголовок Cookie для отслеживания сеанса, у API есть несколько вариантов.

Базовая аутентификация

Да, она также распространена в веб-приложениях, но обычно не используется в современных приложениях из-за проблем, связанных с безопасностью. При базовой аутентификации имя пользователя и парольпередаются в открытом виде через заголовок Authorization.

GET /users?name=admin HTTP/1.1

Host: api.ecorp.local:8081

Content-Type: application/json

Accept: application/json

Authorization: Basic YWRtaW46c2VjcmV0

Cache-Control: no-cache

Очевидные проблемы, связанные с этим, заключаются в том, что учетные данныепередаютсяпопроводамввиденезашифрованноготекстаизлоумыш-

Как и ключи,токены на предъявителя представляютсобой секретные значения,которые обычно также передаются через HTTP-заголовок Authorization, новместотипаBasic используетсятипBearer.ВслучаесRESTAPI,покаклиент исервердоговариваютсяотом,какобмениватьсяэтимтокеном,несуществует­ стандарта, определяющего этот процесс, и поэтому на практике можно встретить его вариации.

GET /users?name=admin HTTP/1.1 Host: api.ecorp.local:8081 Content-Type: application/json Accept: application/json

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjEiLCJ1c2VyIjoiYWRtaW4i LCJpc19hZG1pbiI6dHJ1ZSwidHMiOjEwNDUwNzc1MH0.TstDSAEDcXFE2Q5SJMWWKIsXV 3_krfE4EshejZXnnZw

Cache-Control: no-cache

Предыдущий токен на предъявителя является примером JWT. Он немного длиннее традиционного скрытого токена, но у него есть ряд преимуществ.

JWT

JWT – это относительно новый механизм аутентификации, который завоевываетсвоюдолю на рынке веб-сервисов.Это компактный автономный метод безопасной передачи информации между двумя сторонами.

Токены JWT универсальны,и ихлегко реализоватьв протоколах аутентификации. SOAP и OAuth могут без проблем реализовывать токен JWT в качестве токена на предъявителя.

Информацию об OAuth можно найти на странице https:// oauth.net/2/.

Токены JWT, по сути,утверждают,что они подписаны с использованием ко-

да аутентификации сообщений, применяющего хеш-функции (HMAC), и

но использоватьдля проверки как целостностиданных,так и аутентификации сообщения, что хорошо подходит для токенов JWT. Токены JWT представляют собой сочетание заголовка, полезной нагрузки и соответствующей подписи в кодировке base64url:

base64url(header) . base64url(payload) . base64url(signature)

В заголовкетокена будетуказан алгоритм,используемыйдля подписи,а полезная нагрузка будеттребованием (например,я–user1,а я–администратор), в то время как третья часть– это сама подпись.

Если проверим предыдущий токен на предъявителя, то увидим структуру типичноготокена JWT.Естьтри фрагмента информации,разделенныхточкой, в кодировке base64url.

В этой кодировке используется тотже алфавит,что и в традиционном формате Base64, за исключением замены символов + на – и / на _.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

.

eyJpZCI6IjEiLCJ1c2VyIjoiYWRtaW4iLCJpc19hZG1pbiI6dHJ1ZSwidHMiOjEwND

UwNzc1MH0

.

TstDSAEDcXFE2Q5SJMWWKIsXV3_krfE4EshejZXnnZw

Первый фрагмент – заголовок, описывающий алгоритм подписи. В данном случае это HMAC с SHA-256. Тип определяется как токен JWT.

Можно использовать функцию JavaScript atob() в консоли браузера для декодирования этого фрагмента в удобочитаемый текст.

> atob('eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9') "{"alg":"HS256","typ":"JWT"}"

Второй фрагмент обычно представляет собой произвольные данные, которые что-либо утверждают. Они также известны как полезная нагрузка. В этом случае они сообщают серверу, что я являюсь пользователем с правами администратора admin с идентификатором пользователя 1 и временной отметкой 104507750. Временные отметки – хорошая идея, поскольку они могут предотвратить атаки повторного воспроизведения.

> atob('eyJpZCI6IjEiLCJ1c2VyIjoiYWRtaW4iLCJpc19hZG1pbiI6dHJ1ZSwidH MiOjEwNDUwNzc1MH0') "{"id":"1","user":"admin","is_admin":true,"ts":104507750}"

HMAC в кодировке base64url.

Когда API-сервер получит этот токен, состоящий из трех частей, он сделает следующее:

выполнит синтаксический анализ заголовка, чтобы определить алгоритм: в данном случае это HMAC SHA-256;

рассчитает значение HMAC SHA-256 для первых двух фрагментов, закодированных в base64url, объединенных точкой:

HMAC-SHA256(base64url(header) + "." + base64url(payload),"secret_key");

если подпись подтверждается, можно считать полезную нагрузку также валидной.

Причуды JWT

Хотя в настоящее время этот процесс криптографически безопасен,есть несколько способов, которые мы можем использовать, чтобы поэкспериментировать с этим токеном и попытаться обмануть слабые реализации API.

Прежде всего, хотя заголовок и полезная нагрузка подписаны, их можно модифицировать. Данные токена находятся под нашим контролем. Единст­ венное, что нам не известно, – это секретный ключ. Если мы модифицируем полезную нагрузку, подпись не пройдет проверку и, скорее всего, сервер отклонит наш запрос.

Помните, однако, что фрагмент заголовка анализируется до того, как будет выполнена верификация подписи. Это связано с тем, что в заголовке содержатся инструкции относительно того,как API проверяет сообщение.Это означает,что мы могли бы потенциально изменить данные и что-либо нарушить в реализации.

Интересно, что рабочее предложение (RFC) указывает поддерживаемый алгоритм подписи под названием none, который может использоваться реализацией­ для предположения,что токен был проверен другими способами

(рис. 11.2).

Полное определение токена JWT в открытом стандарте RFC 7519

можно найти на странице https://tools.ietf.org/html/rfc7519.

Некоторые библиотеки JWT следуют стандарту и также поддерживают этот алгоритм. Итак, что происходит, когда мы используем алгоритм none с нашей предыдущей полезной нагрузкой?

Рис.11.2. В RFC упоминается о незащищенных токенах JWT, использующих алгоритм «none»

Вот как будет выглядеть наш токен без подписи,добавленной после последней точки.

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0

.

eyJpZCI6IjEiLCJ1c2VyIjoiYWRtaW4iLCJpc19hZG1pbiI6dHJ1ZSwidHMiOjEwND

UwNzc1MH0

.

[blank]

Токен будет проверен и считаться действительным, если серверная библиотека придерживается стандарта JWT RFC. Мы можем протестировать этот модифицированный токен, используя расширение JSON Web Tokens (рис. 11.3) из Burson Suite, которое можно загрузить из BApp Store.

Рис.11.3. Расширение JSON Web Tokens

МожноввестизначениеJWTвпервоеполеипредоставитьфиктивныйключ. ПосколькумыбольшенеиспользуемHMAC,этозначениебудетигнорироваться. Расширение должно подтвердить,что подпись и токен JWT действительны.

Рис.11.4. Токен JWT без подписи считается действительным

Более подробную информацию об этом типе атаки можно найти на странице https://auth0.com/blog/critical-vulnerabilities-

injson-web-token-libraries/.

Рис.11.6. Загрузка файла JWT4B

JWT4Bпозволитнамперехватыватьзапросысзаголовкамиавторизации,содержащими токен JWT,заменять полезную нагрузку и подписывать повторно, используя тот же ключ (если он у нас есть) либо случайный ключ или даже изменять алгоритм подписи.

Рис.11.7. Модификация токенов JWT на лету