Які типові помилки при реалізації входу через Google чи інший OAuth-провайдер?

«Увійти через Google/GitHub» здається простим, бо бібліотека (у Laravel - Socialite) бере на себе протокол. Але кілька помилок у логіці застосунку роблять його небезпечним.

1. Об'єднання облікових записів за email без перевірки.

$user = User::firstOrCreate(['email' => $socialUser->getEmail()], [...]);
Auth::login($user);

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

• зв'язувати лише з підтвердженим у провайдера email (наприклад, email_verified в OpenID Connect);
• зберігати ідентифікатор провайдера (provider + provider_id), а не лише email, і шукати насамперед за ним;
• прив'язку соцмережі до існуючого облікового запису робити з облікового запису (користувач уже увійшов паролем) чи з підтвердженням поштою.

2. Відсутність перевірки state. Параметр state пов'язує відповідь провайдера із сесією користувача, що почав вхід. Без нього можлива CSRF-атака на вхід: жертву непомітно входять в обліковий запис зловмисника (і вона, наприклад, зберігає туди свої дані). Socialite перевіряє state за замовчуванням; stateless() вимикає перевірку - лише для API з PKCE.

3. Відкрите перенаправлення. Параметр «куди повернутися після входу» (?redirect=) без перевірки - фішинг на вашому домені. Дозволений лише відносний шлях свого сайту.

4. Неправильні redirect URI в налаштуваннях провайдера. Шаблони (https://*.example.com/*) чи зайві адреси дозволяють перехопити код авторизації. Точні адреси, лише HTTPS.

5. Довіра до даних профілю. Ім'я, аватар, email від провайдера - звичайні дані користувача: їх треба валідувати й екранувати.

6. Втрата доступу при видаленні облікового запису провайдера. Користувач без пароля, що втратив Google-акаунт, втрачає доступ - потрібні альтернативні способи входу.

7. Зайві права (scopes). Просити лише потрібне (openid email profile), а не доступ до пошти чи диска «на майбутнє».

8. Токени провайдера. Якщо застосунку справді потрібні токени доступу до API провайдера - зберігати їх зашифрованими (encrypted cast) і оновлювати refresh-токенами.

Для співбесіди: найважливіше - пункт 1. Захоплення облікових записів через неперевірений email - найпоширеніша реальна вразливість соціального входу.

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