Увійти Реєстрація
Блог Серії
Кар'єра
Вакансії Компанії
Навчання
Документація Співбесіди Тестування Відео
Екосистема
Пакети Ресурси Проєкти Інструменти Події
Інше
Про нас Реклама

Що таке перелік облікових записів (account enumeration) і як його уникнути?

Перелік облікових записів - можливість дізнатися, чи зареєстрована певна адреса email (чи логін) у системі. Сама по собі це не злам, але:

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

Де це протікає:

1. Повідомлення входу:

«Користувача з таким email не знайдено»    ← протікає
«Невірний пароль»                          ← протікає
«Невірний email або пароль»                ← правильно

2. Скидання пароля:

«Лист надіслано» / «Такого email немає»                       ← протікає
«Якщо обліковий запис існує, ми надіслали інструкції на email»  ← правильно

3. Реєстрація: «Email уже зайнятий» - складніше уникнути, бо користувачу треба знати, що він уже зареєстрований. Варіант - завжди відповідати «Перевірте пошту», а існуючому користувачу надіслати лист «Ви вже маєте обліковий запис, ось посилання на вхід».

4. Час відповіді. Навіть з однаковими повідомленнями: якщо для неіснуючого користувача сервер відповідає за 5 мс, а для існуючого - 300 мс (бо перевіряє хеш bcrypt), час видає правду. Захист - виконувати перевірку хешу завжди (з фіктивним хешем, якщо користувача немає) і відправляти листи асинхронно з черги, щоб час відповіді на скидання пароля не залежав від того, чи надсилається лист.

5. API й публічні профілі: GET /api/users/check-email?email=... для «живої» перевірки в формі, профілі за передбачуваними URL.

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

У Laravel: стандартний ValidationException з auth.failed дає загальне повідомлення, а Password::sendResetLink повертає статус, який варто показувати однаково для всіх випадків. Fortify за замовчуванням дотримується цих правил, але власні контролери варто перевірити.

Докладніше в документації: OWASP: шпаргалка з автентифікації

1

Перевір себе

20 випадкових питань за спробу, після завершення - розбір кожної помилки

Схожі питання