Аутентификация. Виды аутентификации. Способы защиты

1.

Аутентификация.
Виды
аутентификации.
Способы защиты.

2.

Введение - Зачем это вообще нужно?
Простая аналогия:
Веб-приложение без аутентификации — это как аккаунт в TikTok с
публичным доступом. Все видят один и тот же контент.
Веб-приложение с аутентификацией — это ваш личный аккаунт
TikTok. Вы видите свою ленту, свои сообщения, свои подписки.
Сервер должен точно знать, кто вы.
Задача аутентификации: Ответить на вопрос "Кто вы?" и дать доступ
к персональным ресурсам.

3.

Путаница: Аутентификация vs. Авторизация
Аутентификация (Authentication - AuthN):
• "Кто ты?" — Процесс проверки личности.
• Пример: Ввод логина и пароля в TikTok. Система проверяет, есть ли ты вообще в её
базе.
• Ключевой момент: Проверка учетных данных (credentials).
Авторизация (Authorization - AuthZ):
• "Что тебе можно?" — Процеп проверки прав доступа.
• Пример: После входа в TikTok ты можешь комментировать чужие видео, но не
можешь удалить чужое видео. Это разные уровни прав.
• Ключевой момент: Проверка разрешений (permissions).
Запоминалка: AuthN - это Name (Имя), AuthZ - это Zapret (Запрет, т.е. права).

4.

Вид #1: Аутентификация на основе Сессий (Session-Based)
Как это работает?
1. Пользователь вводит логин/пароль и отправляет на сервер.
2. Сервер проверяет данные. Если всё ок, он создает запись
Сессии в своей базе данных (или в памяти). Сессия имеет
уникальный ID.
3. Сервер отправляет браузеру ответ, в заголовках которого
лежит Set-Cookie: sessionId=abc123...

5.

Вид #1: Аутентификация на основе Сессий (Session-Based)
3. Браузер автоматически сохраняет эту куку и посылает ее с каждым
последующим запросом на этот домен.
4. Сервер, получая sessionId из куки, находит по нему сессию в БД и
понимает, какой пользователь сделал запрос.
Аналогия из TikTok:
Сессия — это ваш бумажный пропуск в офис TikTok (выданный на
ресепшене после проверки паспорта).
Cookie (sessionId) — это бейдж с штрих-кодом, который вы носите с
собой. Охранник (сервер) сканирует бейдж и понимает, кто вы и куда
вам можно, не спрашивая паспорт каждый раз.

6.

Вид #2: Токен-аутентификация (JWT)
JSON Web Token (JWT) - компактный и самодостаточный способ
безопасной передачи информации между сторонами в виде JSONобъекта.
Структура JWT:
header.payload.signature
Header: Алгоритм шифрования и тип токена.
Payload: Полезная нагрузка (данные пользователя, e.g., userId,
username).
Signature: Подпись, которая гарантирует, что токен не был изменен.

7.

Как работает?
1. Пользователь логинится (логин/пароль).
2. Сервер проверяет данные и создает JWT-токен, подписывая его своим
секретным ключом.
3. Сервер отправляет токен клиенту (обычно в теле ответа, а не в куках).
4. Клиент (чаще всего Frontend) сохраняет токен (обычно в localStorage или в
куках) и посылает его в заголовке Authorization: Bearer <токен>.
5. Сервер проверяет подпись токена и извлекает данные из payload. Ему не
нужно хранить токен в БД (статус "независимый").
JWT — это QR-код на концерт. В самом QR-коде закодирована информация
(ряд, место, дата). Организатор просто сканирует его и проверяет
подлинность (подпись), ему не нужно сверяться с общим списком гостей.

8.

Вид #3: OAuth 2.0 и OpenID Connect (Вход через соцсети)
OAuth 2.0 — это не про аутентификацию, а про
делегирование доступа. Он позволяет вашему приложению
получить доступ к данным пользователя на другом сервисе
(например, получить список подписок в TikTok) без получения
его пароля.
OpenID Connect (OIDC) — это надстройка над OAuth 2.0,
которая как раз и решает задачу аутентификации ("Кто ты?").

9.

Роли в OAuth:
• Resource Owner (Владелец): Вы.
• Client (Клиент): Наше приложение, которое хочет
получить доступ.
• Authorization Server (Сервер авторизации): Сервер
TikTok (тот, где вы логинитесь и даете разрешение).
• Resource Server (Сервер ресурсов): API TikTok, где
хранятся данные (посты, подписки).

10.

Flow на примере "Войти через TikTok":
1. Пользователь жмет кнопку "Войти через TikTok" в нашем
приложении.
2. Наше приложение перенаправляет его на tiktok.com.
3. Пользователь вводит свои логин/пароль в форму TikTok
(мы их никогда не видим!).
4. TikTok спрашивает: "Приложение 'MyCoolApp' хочет
получить доступ к вашему профилю. Разрешаете?".

11.

Flow на примере "Войти через TikTok":
5. Если пользователь соглашается, TikTok перенаправляет
его обратно в наше приложение с специальным code.
6. Наше приложение (бэкенд!) меняет этот code на Access
Token.
7. С этим токеном наше приложение может спросить у TikTok:
"Эй, а кто же у тебя там авторизовался?" и получить данные
профиля (username, id). Это и есть аутентификация.

12.

Защита веб-приложений и Best Practices
1. Инъекции (Injection)
• SQL, NoSQL, Command Injection
• Защита: Использование подготовленных запросов
(prepared statements), ORM, валидация и санитизация
входных данных
2. Недостатки аутентификации (Broken Authentication)
• Слабые пароли, неправильная реализация сессий
• Защита: Многофакторная аутентификация, надежные
хэши паролей, защита сессий

13.

Защита веб-приложений и Best Practices
3. Раскрытие конфиденциальных данных (Sensitive Data
Exposure)
• Нешифрованные данные, слабое шифрование
• Защита: HTTPS, сильные алгоритмы шифрования, не
хранить лишние данные
4. XXE (XML External Entities)
• Уязвимости обработки XML
• Защита: Отключение обработки внешних сущностей в
XML-парсерах

14.

Защита веб-приложений и Best Practices
5. Недостатки контроля доступа (Broken Access Control)
• Неправильная проверка прав доступа
• Защита: Принцип минимальных привилегий, проверка
прав на сервере
6. Небезопасная конфигурация (Security Misconfiguration)
• Стандартные учетные данные, ненужные службы
• Защита: Харденинг серверов, регулярный аудит
конфигурации

15.

Защита веб-приложений и Best Practices
7. XSS (Cross-Site Scripting)
• Внедрение вредоносных скриптов
• Защита: Санитизация пользовательского ввода, CSP
(Content Security Policy)
8. Небезопасная десериализация (Insecure Deserialization)
• RCE, повышение привилегий
• Защита: Проверка целостности данных, избегание
десериализации непроверенных данных

16.

Защита веб-приложений и Best Practices
9. Использование компонентов с известными
уязвимостями
• Устаревшие зависимости
• Защита: Регулярное обновление зависимостей,
сканирование уязвимостей
10. Недостатки логирования и мониторинга
• Недостаточное отслеживание инцидентов
• Защита: Полное логирование, система оповещений,
регулярный аудит логов

17.

Инструменты безопасности
1. Статический анализ кода
• ESLint с security плагинами (eslint-plugin-security)
• SonarQube
2. Сканирование зависимостей
• npm audit, yarn audit
• Snyk, Dependabot
3. Динамическое тестирование
• OWASP ZAP
• Burp Suite
4. Мониторинг
• Логирование security событий
• SIEM системы (Splunk, ELK)

18.

Культура безопасности
1. Принцип минимальных привилегий
• Давать только необходимые права
2. Защита на всех уровнях
• Сеть, приложение, база данных, инфраструктура
3. Регулярное обучение
• Актуализация знаний о новых угрозах
4. Security by Design
• Включать безопасность в процесс разработки с самого начала
5. План реагирования на инциденты
• Что делать при обнаружении уязвимости или атаке

19.

Итоги: Что и когда использовать?
Метод
Плюсы
Минусы
Идеальный кейс
Session-Based
Прост в понимании,
легкая инвалидация
(удалить сессию)
Stateful (сервер
хранит состояние),
сложнее
масштабировать
Классические вебсайты (MVC)
JWT
Stateless (легко
масштабировать),
мобильный-friendly
Сложнее
инвалидировать
отдельный токен,
риски безопасности
при хранении
SPA, мобильные
приложения,
микросервисы
OAuth 2.0 / OIDC
Не мы храним пароли,
доверие через
крупный провайдер
Сложная настройка,
зависимость от
третьей стороны
"Войти через
Google/Facebook/TikTo
k"

20.

Демо и Домашнее задание
1. Откройте и установите
2. Запустите session-сервер (node server-session.js).
3. Создайте базовый FrontEnd
4. Запустите session-jwt (node server-jwt .js).
5. Создайте минимальный FrontEnd
6. Изучите и прикрепите выполненное задание в сдо