Broken Authentication

Особливості цієї вразливості

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

Поширеність

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

Впливи

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

Як зрозуміти що API вразлива?

Кінцеві точки автентифікації та потоки – це активи, які потрібно захищати. Крім того, «Забули пароль / скинути пароль» слід розглядати так само, як механізми автентифікації.

API є вразливим, якщо він:

Дозволяє надсилати облікові дані, коли зловмисник використовує brute force зі списком дійсних імен користувачів і паролів.
Дозволяє зловмисникам виконувати атаку brute force на той самий обліковий запис користувача, не використовуючи механізм блокування облікового запису.
Дозволяє слабкі паролі.
Надсилає конфіденційні дані автентифікації, такі як маркери автентифікації та паролі в URL-адресі.
Дозволяє користувачам змінювати адресу електронної пошти, поточний пароль або виконувати будь-які інші конфіденційні операції, не запитуючи підтвердження пароля.
Не перевіряє автентичність токенів.
Приймає непідписані/слабо підписані маркери JWT ( {"alg":"none"})
Не перевіряє термін дії JWT.
Використовує простий текст, незашифровані або слабко хешовані паролі.
Використовує слабкі ключі шифрування.

Крім того, мікросервіс вразливий, якщо:

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

Приклади сценаріїв атак

Сценарій №1

Щоб виконати автентифікацію користувача, клієнт має надіслати запит API, подібний до наведеного нижче, з обліковими даними користувача:

POST /graphql { "query":"mutation { login (username:"<username>",password:"<password>") { token } }" }

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

Щоб увійти в обліковий запис жертви brute force, зловмисники використовують групування запитів GraphQL, щоб обійти обмеження частоти запитів, прискорюючи атаку:

POST /graphql [ {"query":"mutation{login(username:"victim",password:"password"){token}}"}, {"query":"mutation{login(username:"victim",password:"123456"){token}}"}, {"query":"mutation{login(username:"victim",password:"qwerty"){token}}"}, ... {"query":"mutation{login(username:"victim",password:"123"){token}}"}, ]

Сценарій №2

Щоб оновити адресу електронної пошти, пов’язану з обліковим записом користувача, клієнти повинні надіслати запит API, подібний до наведеного нижче:

PUT /account Authorization: Bearer <token> { "email": "<new_email_address>" }

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

Як запобігти

Переконайтеся, що ви знаєте всі можливі потоки для автентифікації в API (мобільні/веб/діплінки, які реалізують автентифікацію в один клік тощо), щоб їх перевірити.
Прочитайте про ваші механізми автентифікації. Переконайтеся, що ви розумієте, що і як вони використовують.
Не винаходьте новий велосипед в автентифікації, генерації маркерів або зберіганні паролів. Використовуйте існуючі стандарти.
Кінцеві точки відновлення облікових даних/забутого пароля слід розглядати як кінцеві точки входу з точки зору brute force, обмеженням швидкості та захистом блокування.
Вимагати другий фактор для конфіденційних операцій (наприклад, зміна електронної адреси власника облікового запису/номера телефону 2FA).
Використовуйте Authentication Cheat Sheet.
За можливості запровадьте багатофакторну автентифікацію.
Застосуйте механізми проти перебору, щоб пом’якшити словникові атаки та атаки підбору на ваші кінцеві точки автентифікації. Цей механізм має бути суворішим, ніж звичайні механізми обмеження швидкості на ваших API.
Застосуйте механізми блокування облікового запису / captcha, щоб запобігти атакам грубої сили на конкретних користувачів. Запровадити перевірку слабких паролів.
Ключі API не слід використовувати для автентифікації користувача. Їх слід використовувати лише для автентифікації клієнтів API .