Блог з безпеки

OWASP Top 10 API Security: порушена автентифікація

7 хв читання

ResilientX

У сучасному цифровому середовищі API (Application Programming Interfaces) відіграють вирішальну роль у забезпеченні зв’язку та взаємодії між різними програмними системами. Однак API також можуть стати мішенню для зловмисників, якщо не впроваджено належних заходів безпеки. Одна з поширених вразливостей, що наражає API на ризики, — порушена автентифікація (broken authentication). У цій технічній статті ми розглянемо агентів загроз, вектори атак, слабкі місця безпеки та наслідки, пов’язані з порушеною автентифікацією API2:2023. Ми також обговоримо приклади сценаріїв атак і наведемо запобіжні заходи для пом’якшення цієї вразливості.

Агенти загроз / вектори атак

Агенти загроз, що націлюються на порушену автентифікацію, можуть варіюватися від опортуністичних зловмисників до витончених хакерів. Вектори атак, пов’язані з порушеною автентифікацією, можна класифікувати так:

Легкість експлуатації: Механізм автентифікації часто є легкою мішенню для зловмисників, оскільки він відкритий для всіх. Хоча деякі проблеми автентифікації можуть потребувати просунутих технічних навичок для експлуатації, доступні інструменти експлуатації роблять її досяжною для ширшого кола зловмисників.
Слабкість безпеки: Поширеність порушеної автентифікації переважно зумовлена хибними уявленнями та складнощами реалізації, пов’язаними з межами автентифікації. Інженери з програмного забезпечення та безпеки можуть мати хибні припущення або не мати повного розуміння того, як реалізувати безпечні механізми автентифікації. Це призводить до такої слабкості безпеки:
Хибні уявлення та складність реалізації: Хибні уявлення інженерів із програмного забезпечення та безпеки щодо меж автентифікації та властива складність реалізації роблять проблеми автентифікації поширеними. Ці хибні уявлення можуть призводити до вразливих механізмів автентифікації, залишаючи API відкритими до атак.

Наслідки: наслідки порушеної автентифікації можуть мати серйозні технічні та специфічні для бізнесу результати. Коли механізми автентифікації скомпрометовано, зловмисники отримують несанкціонований доступ до облікових записів користувачів, що призводить до таких наслідків:

Повне захоплення облікового запису: зловмисники можуть отримати повний контроль над обліковими записами інших користувачів у системі, що дає їм змогу читати особисті дані та виконувати чутливі дії від їхнього імені. Така компрометація може призвести до порушень приватності, фінансових втрат, репутаційної шкоди та юридичних наслідків.
Складність виявлення: атаки на порушену автентифікацію може бути складно виявити, оскільки дії зловмисників часто імітують поведінку легітимних користувачів. Системам важко розрізнити дії зловмисників і справжніх користувачів, що ускладнює своєчасне виявлення таких атак і реагування на них.

Чи вразливий цей API?

Щоб визначити, чи вразливий API до порушеної автентифікації, важливо оцінити кілька факторів. API можна вважати вразливим, якщо він має будь-яку з таких характеристик:

Підстановка облікових даних (Credential Stuffing): API дозволяє атаки типу credential stuffing, коли зловмисники застосовують методи повного перебору зі списком дійсних імен користувачів і паролів, щоб отримати несанкціонований доступ.
Атаки повним перебором: API дозволяє зловмисникам виконувати атаки повним перебором на той самий обліковий запис користувача без впровадження механізмів на кшталт CAPTCHA чи блокування облікового запису, які б запобігали численним невдалим спробам входу.
Слабкі паролі: API дозволяє використання слабких паролів, які легко вгадати або які вразливі до словникових атак.
Небезпечна передача: API надсилає чутливі дані автентифікації, як-от токени автентифікації та паролі, в URL. Ця практика наражає чутливу інформацію на потенційне перехоплення чи несанкціонований доступ.
Відсутність підтвердження для чутливих операцій: API дозволяє користувачам виконувати чутливі операції, як-от зміну електронних адрес чи паролів, не вимагаючи підтвердження пароля. Це полегшує зловмисникам захоплення контролю над обліковими записами користувачів.
Відсутність перевірки справжності токенів: API не перевіряє справжність токенів, що робить його вразливим до підробки токенів чи атак типу ін’єкції.
Використання слабких або непідписаних JWT-токенів: API приймає непідписані або слабко підписані JWT-токени (JSON Web Token), якими зловмисники можуть скористатися для отримання несанкціонованого доступу.
Відсутність перевірки строку дії JWT: API не перевіряє дату закінчення строку дії JWT-токенів, дозволяючи приймати прострочені токени та використовувати їх для автентифікації.
Небезпечне зберігання паролів: API зберігає паролі у відкритому тексті, у незашифрованому чи слабко хешованому форматі, що робить їх вразливими до несанкціонованого доступу.
Слабкі ключі шифрування: API використовує слабкі ключі шифрування, якими зловмисники можуть скористатися для розшифрування чутливої інформації.

Окрім цих вразливостей, специфічних для API, мікросервіси можуть мати власний набір вразливостей, пов’язаних із порушеною автентифікацією. Мікросервіс вважається вразливим, якщо:

Відсутність автентифікації: Інші мікросервіси можуть отримати до нього доступ без належної автентифікації, що призводить до несанкціонованого доступу.
Слабкі або передбачувані токени: Мікросервіс покладається на слабкі чи передбачувані токени для автентифікації, що полегшує зловмисникам видавати себе за легітимних користувачів.

Приклади сценаріїв атак: щоб краще зрозуміти наслідки порушеної автентифікації, розгляньмо два сценарії атак, які зазвичай пов’язують із цією вразливістю.

Приклади порушеної автентифікації

Сценарій №1

Повний перебір облікових записів користувачів. У цьому сценарії механізм автентифікації API дозволяє клієнтам входити, надсилаючи запит GraphQL з обліковими даними користувача. Зловмисники використовують пакетування запитів GraphQL, щоб обійти обмеження частоти запитів і пришвидшити атаки повним перебором. Надсилаючи численні запити на вхід із різними паролями, зловмисники намагаються знайти дійсні облікові дані й отримати несанкціонований доступ до облікових записів користувачів.

Сценарій №2

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

Як запобігти порушеній автентифікації

Запобігання порушеній автентифікації потребує проактивного підходу до впровадження безпечних механізмів автентифікації. Розгляньте такі запобіжні заходи:

Розумійте потоки автентифікації: Переконайтеся, що всі можливі потоки автентифікації — мобільні, вебові та через deep links — ретельно проаналізовано та захищено. Співпрацюйте з інженерами, щоб виявити будь-які пропущені потоки та потенційні вразливості.
Знайте механізми автентифікації: Сформуйте всебічне розуміння механізмів автентифікації, що використовуються у вашій системі. Важливо розрізняти автентифікацію та авторизацію й не винаходити велосипед, спираючись на галузеві стандарти та найкращі практики.
Використовуйте усталені стандарти: Реалізуйте автентифікацію, генерацію токенів і зберігання паролів за усталеними стандартами, а не винаходьте ці компоненти заново. Стандарти на кшталт OAuth і безпечні алгоритми хешування паролів можуть суттєво посилити безпеку.
Безпечно ставтеся до ендпоінтів відновлення / забутого пароля: Ставтеся до ендпоінтів відновлення чи забутого пароля з таким самим рівнем безпеки, як до ендпоінтів входу. Впровадьте надійний захист від повного перебору, обмеження частоти запитів і механізми блокування облікового запису, щоб запобігти спробам несанкціонованого доступу.
Вимагайте повторної автентифікації: Для чутливих операцій, як-от зміна електронних адрес чи номерів телефону для 2FA (двофакторної автентифікації), вимагайте від користувачів повторної автентифікації через введення поточного пароля. Це гарантує, що лише авторизовані особи можуть виконувати критичні дії.
Дотримуйтеся настанов OWASP: Звертайтеся до OWASP (Open Web Application Security Project) Authentication Cheatsheet за найкращими практиками та настановами щодо безпечної реалізації автентифікації.
Впроваджуйте багатофакторну автентифікацію: Де можливо, розгляньте впровадження багатофакторної автентифікації, щоб додати додатковий рівень безпеки. Це можуть бути такі методи, як SMS-верифікація, підтвердження електронною поштою чи апаратні токени.
Застосовуйте механізми захисту від повного перебору: Пом’якшуйте credential stuffing, словникові атаки та атаки повним перебором, впроваджуючи механізми захисту від повного перебору. Ці механізми мають бути суворішими за звичайне обмеження частоти запитів і активно запобігати автоматизованим атакам.
Впроваджуйте блокування облікового запису та CAPTCHA: Захищайте конкретні облікові записи користувачів, впроваджуючи механізми блокування облікового запису та завдання CAPTCHA. Ці заходи ускладнюють атаки повним перебором, спрямовані на окремі облікові записи користувачів.
Забезпечуйте надійні паролі: Впроваджуйте перевірки, щоб забезпечити використання надійних паролів, зокрема вимоги до складності та перевірки за списками поширених паролів.
Розрізняйте API-ключі та автентифікацію користувачів: Розмежовуйте API-ключі та автентифікацію користувачів. API-ключі слід використовувати лише для автентифікації API-клієнтів, а не окремих облікових записів користувачів.

Динамічне тестування безпеки застосунків і тестування безпеки API від ResilientX

Щоб протидіяти вразливості API2:2023 Broken Authentication, ResilientX пропонує розширені можливості динамічного тестування безпеки застосунків (DAST) і тестування безпеки API. Ці передові рішення допомагають клієнтам виявляти й пом’якшувати ризики, пов’язані з несанкціонованим доступом до чутливих даних. Використовуючи потужні інструменти тестування безпеки ResilientX, організації можуть посилити безпеку своїх API та зміцнити захист. Ось як рішення ResilientX допомагають виявляти й запобігати порушеній авторизації на рівні об’єктів:

Комплексне сканування вразливостей: Інструменти DAST і тестування безпеки API від ResilientX проводять ретельне сканування вразливостей по всіх ендпоінтах API. Цей процес передбачає прискіпливий аналіз запитів і відповідей, перевірку ідентифікаторів об’єктів та їх використання у викликах API. Застосовуючи інтелектуальні методи сканування, інструменти ResilientX забезпечують широке покриття, ефективно виявляючи слабкі місця безпеки, якими могли б скористатися зловмисники.
Виявлення прогалин в авторизації на рівні об’єктів: Рішення ResilientX прискіпливо аналізують механізми авторизації, реалізовані в ендпоінтах API, щоб виявити прогалини в авторизації на рівні об’єктів. Перевіряючи валідацію та авторизацію ідентифікаторів об’єктів, ці інструменти виявляють випадки, коли належні перевірки відсутні чи недостатні, що призводить до потенційних вразливостей. Генеруються детальні звіти, які підкреслюють конкретні ділянки з порушеною авторизацією на рівні об’єктів, даючи організаціям змогу пріоритезувати зусилля з усунення вразливостей.
Симуляція атак та оцінка впливу: Інструменти ResilientX виходять за межі простого виявлення вразливостей, симулюючи реальні атаки, що експлуатують порушену авторизацію на рівні об’єктів. Ця функція симуляції дає організаціям змогу оцінити вплив і серйозність потенційних витоків. Розуміючи наслідки успішної експлуатації, організації можуть посилити свій захист і впровадити відповідні контрзаходи.
Безперервний моніторинг і відповідність вимогам: Інструменти тестування ResilientX пропонують функції безперервного моніторингу та відповідності вимогам, щоб забезпечити постійний захист від вразливостей порушеної авторизації на рівні об’єктів. Організації можуть налаштувати автоматизовані сканування безпеки для виявлення нових випадків порушеної авторизації на рівні об’єктів у міру розвитку API. Такий проактивний моніторинг уможливлює своєчасне усунення вразливостей, мінімізуючи вікно можливостей для зловмисників експлуатувати вразливості. Рішення ResilientX також допомагають організаціям дотримуватися галузевих стандартів і нормативних вимог, гарантуючи, що API відповідають необхідним вимогам безпеки.

Використовуючи можливості динамічного тестування безпеки застосунків і тестування безпеки API від ResilientX, організації отримують потужні інструменти для виявлення та запобігання вразливостям порушеної авторизації на рівні об’єктів. Завдяки комплексному скануванню вразливостей, симуляціям атак, безпечному огляду коду, безперервному моніторингу та функціям співпраці організації можуть посилити стан безпеки своїх API й захиститися від несанкціонованого доступу до чутливих даних.

Порушена автентифікація API2:2023 несе значні ризики для безпеки та цілісності API й мікросервісів. Розуміючи агентів загроз, вектори атак, слабкі місця безпеки та наслідки, пов’язані з порушеною автентифікацією, організації можуть вживати проактивних заходів для пом’якшення цих вразливостей. Впровадження безпечних механізмів автентифікації, дотримання галузевих стандартів і застосування запобіжних заходів можуть допомогти захистити API від несанкціонованого доступу, захоплення облікових записів та пов’язаних ризиків.