Сессии, cookies и аутентификация

Login-flow

Псевдокод авторизации с проверкой пароля и регенерацией ID:

<?php
function login(PDO $pdo, string $email, string $password): bool
{
    $stmt = $pdo->prepare('SELECT id, password_hash FROM users WHERE email = :email');
    $stmt->execute(['email' => $email]);
    $user = $stmt->fetch();

    if ($user === false) {
        // намеренная задержка чтобы враг не отличил «нет юзера» от «неверный пароль»
        password_verify($password, '$2y$12$dummyhashtoblockstoptimingattacks........');
        return false;
    }

    if (!password_verify($password, $user['password_hash'])) {
        return false;
    }

    // главное: меняем session ID после смены прав
    session_regenerate_id(delete_old_session: true);

    $_SESSION['user_id'] = $user['id'];
    $_SESSION['logged_in_at'] = time();

    return true;
}

function logout(): void
{
    $_SESSION = [];
    if (ini_get('session.use_cookies')) {
        $params = session_get_cookie_params();
        setcookie(session_name(), '', time() - 42000,
            $params['path'], $params['domain'],
            $params['secure'], $params['httponly'],
        );
    }
    session_destroy();
}

Почему session_regenerate_id

Это защита от session fixation: атакующий узнаёт чей-то session ID до логина (например, подсунул через URL) и после успешного логина пользуется тем же ID. Регенерация выдаёт новый ID после смены прав - старый становится бесполезным.

Делай регенерацию также при смене пароля и при повышении прав (например, обычный юзер → админ).

Проверка авторизации

Middleware-обёртка, которая пускает только залогиненных:

<?php
function requireAuth(): int
{
    if (!isset($_SESSION['user_id'])) {
        http_response_code(401);
        header('Content-Type: application/json');
        echo json_encode(['error' => 'unauthorized']);
        exit;
    }
    return (int) $_SESSION['user_id'];
}

// использование в защищённом эндпоинте
$userId = requireAuth();
echo "Привет, юзер #$userId";

В PSR-15 это будет полноценный middleware - посмотри урок 17, паттерн идентичный.

password_hash и password_verify

Никогда не храни пароли в открытом виде или через md5/sha1. PHP даёт встроенные функции с современным bcrypt/argon2:

<?php
// при регистрации:
$hash = password_hash('user-password', PASSWORD_DEFAULT);
// $2y$12$... - bcrypt с cost=12

// при логине:
if (password_verify('user-password', $hash)) {
    // совпало
}

// автообновление при изменении алгоритма/cost:
if (password_needs_rehash($hash, PASSWORD_DEFAULT)) {
    $newHash = password_hash($plainPassword, PASSWORD_DEFAULT);
    // save $newHash
}

PASSWORD_DEFAULT сейчас - bcrypt, но в будущих версиях PHP может стать argon2. Хранить хеши в колонке VARCHAR(255), чтобы новых алгоритмов хватило.

CSRF-токен (превью)

Если у тебя сессионная авторизация, то любая форма с побочными эффектами должна защищаться CSRF-токеном - иначе чужой сайт может отправить от твоего имени запрос с угнанной сессией. Базовая реализация:

<?php
function csrfToken(): string
{
    if (empty($_SESSION['csrf'])) {
        $_SESSION['csrf'] = bin2hex(random_bytes(32));
    }
    return $_SESSION['csrf'];
}

function csrfVerify(string $token): bool
{
    return !empty($_SESSION['csrf'])
        && hash_equals($_SESSION['csrf'], $token);
}

В форме:

<form method="POST">
    <input type="hidden" name="_csrf" value="<?= htmlspecialchars(csrfToken()) ?>">
    <!-- ... -->
</form>

На сервере:

<?php
if (!csrfVerify($_POST['_csrf'] ?? '')) {
    http_response_code(403);
    exit('CSRF token mismatch');
}

hash_equals - сравнение строк в постоянном времени (защита от timing-атак). Подробнее CSRF/XSS/SQLi - в следующем уроке про безопасность; базовый CSRF-токен мы видели в уроке про формы.

Хранение сессий

По умолчанию PHP сохраняет сессии в файлы. Для прода с несколькими PHP-инстансами файлы не подходят - нужен общий хранитель:

php.ini:

session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?database=0"

Как это в Symfony

Symfony Security Component делает всё это «из коробки», но идеи те же:

# config/packages/security.yaml
security:
  password_hashers:
    App\Entity\User: 'auto'   # PHP-DEFAULT bcrypt/argon2

  providers:
    app_user_provider:
      entity: { class: App\Entity\User, property: email }

  firewalls:
    main:
      provider: app_user_provider
      form_login: { login_path: app_login, check_path: app_login }
      logout: { path: app_logout }
      remember_me:
        secret: '%kernel.secret%'
        lifetime: 604800  # неделя

И в контроллере:

<?php
#[Route('/me')]
public function me(#[CurrentUser] User $user): Response
{
    return new JsonResponse(['email' => $user->getEmail()]);
}

#[CurrentUser] достаёт авторизованного пользователя из сессии - null если не залогинен. CSRF-токены, регенерация ID, безопасные cookie - всё уже учтено.

Типичные ошибки

1. Хранение паролей открытым текстом или через md5. Только password_hash + password_verify. Никаких исключений.
2. Сессионный ID в URL (PHPSESSID=...). session.use_only_cookies=1 - обязательно. Иначе ссылку с ID можно слить в реферер.
3. session_regenerate_id забыли при логине. Открывает session fixation.
4. samesite=None без secure. Браузеры отвергают такой cookie. Если нужна кросс-сайтовая отправка - обязательно по HTTPS.
5. Долгие сессии для админок. Чем больше прав, тем короче должна быть сессия (15-30 минут с авто-логаутом) и тем чаще регенерация.
6. Сессия как кэш для тяжёлых данных. Сессия - для «кто залогинен», флага csrf_token, может корзины. Списки заказов - в БД.

Best practices

• Для сессионного cookie обязательный минимум: httponly: true, secure: true, samesite: Lax - без этого куки уязвимы к XSS и CSRF.
• Вызывай session_regenerate_id(delete_old_session: true) при каждом логине, смене пароля и повышении прав - защита от session fixation.
• Не храни в сессии тяжёлые данные (списки заказов, профили) - только минимум: user_id, csrf_token, флаги. Остальное в БД по user_id.
• Переименуй сессионный cookie с дефолтного PHPSESSID через session_name() - дефолт раскрывает технологию в запросах.
• Для нескольких PHP-инстансов или Kubernetes используй Redis как хранилище сессий: файлы хранятся локально на воркере и не шарятся между ними.

Мини-задание

• Bootstrap с session_set_cookie_params (secure+httponly+SameSite) и session_start()
• Таблица users(id, email UNIQUE, password_hash, created_at). Функция register(PDO, email, password) сохраняет с password_hash
• Функции login() и logout() с session_regenerate_id и очисткой
• Защищённый эндпоинт /me, отвечает 401 если не авторизован, иначе JSON {user_id: N}
• Добавь csrfToken() и проверку на POST-эндпоинте; убедись, что без токена - 403