Broken Authentication в API: Повний розбір, причини, наслідки та реальні кейси

Broken Authentication — одна з найнебезпечніших категорій вразливостей API. Вона виникає тоді, коли механізми автентифікації або управління сесіями реалізовані неправильно: токени можна вгадати, refresh-токени не оновлюються, endpoint-и не перевіряють авторизацію, а інколи облікові дані взагалі не потрібні.

У результаті атакувальник отримує можливість видавати себе за легального користувача, перехоплювати його сесію або виконувати дії з правами адміністратора.

1. Основні причини Broken Authentication в API

• Використання передбачуваних токенів (послідовні JWT ID, UUIDv1 тощо)
• Відсутність перевірки автентифікації на критичних endpoint-ах
• Неправильна обробка refresh-токенів
• Невірна інвалідація токенів після виходу або зміни пароля
• Відсутність перевірки ролей та дозволів (Broken Authorization)
• Відсутність rate-limit для логіну або відновлення пароля
• Basic Auth замість сучасної схемної аутентифікації
• Hardcoded токени або API-ключі в мобільних або веб-додатках

2. Типові варіанти атак

2.1. Перехоплення токена доступу

Якщо API передає токени через незахищений HTTP, або JWT зберігається у LocalStorage, атакувальник може викрасти токен через MITM або XSS.

2.2. Повторне використання токена (Replay Attack)

Деякі API не перевіряють час життя токена або не блокують старі токени після logout.

2.3. Перебір токенів (Token Bruteforce)

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

2.4. Broken OAuth

Помилки в реалізації OAuth 2.0 дозволяють атакувальникам захопити чужий акаунт через підміну redirect_uri або неправильну валідацію state.

2.5. Відсутність перевірки ролей

API може давати можливість виконувати дії адміністратора просто маючи валідний токен користувача.

3. Реальні приклади Broken Authentication у великих компаній

3.1. Uber — повний контроль над будь-яким акаунтом (Bug Bounty)

Дослідник знайшов endpoint, який приймав user_id без перевірки автентифікації. Достатньо було знати чужий ID — і можна було отримати токен доступу від імені жертви.

Причина: неправильна авторизація в API.

Наслідок: повний захват акаунтів.

3.2. Instagram (Meta) — вразливість у OAuth

Через неправильну валідацію redirect_uri атакувальник міг перехопити токен авторизації в рамках flow входу.

Тип: Broken OAuth + Broken Authentication.

3.3. Starbucks — повний доступ через Predictable Session Token

API генерував послідовні session ID. Дослідник зміг вгадати токени інших користувачів.

Наслідок: перегляд і зміна балансу Starbucks Cards.

3.4. Facebook — перехоплення access token через неправильну конфігурацію

У старій версії мобільного SDK токен можна було отримати через сторонній додаток, оскільки не застосовувалась прив’язка до конкретного пакету.

4. Broken Authentication у мобільних API

Найчастіші проблеми мобільних застосунків:

• вшиті secret keys у APK/IPA
• використання токенів без прив’язки до пристрою
• відсутність TLS pinning
• статичні токени, які не оновлюються
• кешування токенів у відкритих директоріях

5. Як виявити Broken Authentication під час тестування

Перевірки:

• Спроба доступу до ендпоінтів без токена
• Спроба доступу до чужих ресурсів зміною ID (IDOR)
• Перевірка життєвого циклу сесій
• Спроба reuse токена після logout
• Bruteforce логіна (без rate-limit)
• Перевірка багатьох ролей (user → admin)
• Підміна Authorization заголовка
• Виявлення hardcoded ключів у мобільних додатках

6. Як захиститися

6.1. Обов’язкові рекомендації

• Використовувати OAuth 2.0 + OpenID Connect
• Прив’язувати токен до пристрою або IP (там, де це можливо)
• Використовувати короткоживучі access tokens
• Використовувати secure refresh tokens із ротацією
• Увімкнути rate-limit на логін / reset password
• Уникати predictable IDs (UUIDv4 only)
• Шифрувати токени, не зберігати у LocalStorage
• Забезпечити TLS 1.2+ та TLS pinning

7. Висновок

Broken Authentication — одна з найсерйозніших і найпоширеніших загроз у сучасних API. Більшість реальних атак відбулися через неправильну або неповну перевірку токенів, слабку авторизацію, відсутність ротації сесій і помилки у реалізації OAuth. Захищаючи API, важливо завжди враховувати весь життєвий цикл сесій, рольову модель доступу, безпечне зберігання токенів та правильну перевірку автентифікації на кожному endpoint.