Розробка функціоналу скидання пароля часто здається тривіальним завданням, проте реалізація безпечного потоку вимагає значно більше зусиль. Під час створення API для менеджера завдань автор виявив чотири серйозні проблеми, які могли б скомпрометувати безпеку користувачів. Ці вразливості стосуються не лише логіки обробки запитів, а й фундаментальних принципів захисту даних, таких як запобігання витоку інформації про реєстрацію та забезпечення цілісності транзакцій у базі даних.
Перша проблема полягає у витоку даних через повідомлення про скидання пароля. Стандартна практика повернення різних відповідей для існуючих та неіснуючих адрес дозволяє зловмисникам перевіряти наявність користувачів у системі. Рішення полягає в уніфікації відповідей: сервер повинен завжди повертати статус 200, незалежно від того, чи знайдено користувача. Це запобігає використанню вашого сервісу як інструменту для збору бази дійсних електронних адрес, що є критичним для захисту приватності.
Друга вразливість пов'язана з атаками за часом під час входу в систему. Якщо перевірка пароля виконується швидше для неіснуючих користувачів, зловмисник може обчислити різницю в часі відповіді та визначити наявність акаунта. Ефективним захистом є використання фіктивного хешування для неіснуючих користувачів, щоб час виконання запиту залишався однаковим. Це гарантує, що жоден зовнішній спостерігач не зможе отримати інформацію про внутрішню логіку обробки запитів через аналіз затримок сервера.
Третя проблема стосується відсутності атомарності при оновленні пароля. Виконання кількох окремих запитів до бази даних створює умови для стану гонки, коли два паралельні запити можуть використовувати один і той самий токен. Вирішенням є використання єдиної транзакції, яка одночасно перевіряє та анулює токен. Це гарантує, що навіть при одночасних запитах лише один з них буде успішним, а інші отримають відмову, що запобігає несанкціонованому використанню токенів скидання.
Четверта вразливість виникає через можливість існування кількох активних токенів одночасно. Кожен запит на скидання пароля створював новий токен, залишаючи попередні дійсними, що значно розширювало вікно для атаки. Сучасний підхід передбачає анулювання всіх попередніх токенів користувача при створенні нового або використанні одного з них. Це забезпечує безпеку, гарантуючи, що після успішного скидання пароля старі посилання стають марними, мінімізуючи ризики, пов'язані з перехопленням листів.
Окрім виправлення цих помилок, важливо враховувати питання ідемпотентності та захисту від повторних запитів. Хоча автор впровадив механізми захисту, він зазначає, що існують певні прогалини при паралельних запитах з однаковими ключами. Це підкреслює необхідність постійного аудиту коду автентифікації. Безпека — це не статичний стан, а процес постійного вдосконалення, де навіть незначні деталі можуть стати точками входу для зловмисників, якщо їх не врахувати під час проектування архітектури.
🔗 Першоджерело: Читати оригінал