PHP: полный мануал с примерами, функциями и ООП

Полная карта официальной ветки Security

Эта глава следует всей официальной ветке Security, а затем расширяет её рабочими формами, входом, сессиями, файлами, SQL, журналами и жизненным циклом аккаунта. Это карта слоёв: функция PHP не способна исправить права ОС, открытый web-root или избыточные права пользователя базы.

От реального действия к границам доверия и минимальным правам

PHP-процесс умеет читать и менять файлы, открывать сеть, обращаться к базе и запускать программы — ровно в пределах учётной записи и политики сервера. Поэтому безопасность начинается не с «секретной функции», а с ответа на три вопроса: какие данные пришли, какое действие сейчас выполняется и какой минимальный участник имеет право его сделать.

Абсолютной защиты не бывает: меры выбирают по последствиям и удобству, а затем проверяют не только успешный путь. Маленький сайт тоже получает автоматические запросы. Ищите слабейшую связь: строгий журнал не доказывает личность, если весь вход держится на подменяемом cookie; HTTPS не исправляет SQL-склейку; скрытая кнопка не заменяет серверную авторизацию.

CGI, FastCGI, PHP-FPM и Apache: кто выполняет код

Сначала выясните, кто запускает PHP. В CLI это пользователь терминала. В Apache module код наследует права процесса Apache. В PHP-FPM запрос выполняет пользователь выбранного пула. В старом CGI-сценарии web-сервер вызывает отдельный бинарник. От этого зависит, какие файлы, сокеты, процессы и базы доступны при любой ошибке приложения.

Сессия: ID в cookie, серверное состояние и обязательные настройки

Сессия связывает случайный ID из cookie с серверным состоянием. Она помогает узнать следующий запрос, но не проверяет пароль, право на чужой объект или CSRF сама. Украденный действующий ID имеет возможности своей серверной записи, поэтому нужна защита транспорта, ротация на входе, сроки и отзыв.

Полный справочник конфигурации объясняет область изменения, единицы и backend; схема фиксации, ротации и сроков — жизненный цикл; HTTP-проект входа действительно отправляет cookie и проверяет коды 200/303/400/401/403/503. Не используйте ID сессии как CSRF-токен и не печатайте его в HTML или журнал.

Файлы: allowlist, корневой каталог, права и нулевой байт

Если имя файла пришло из query, формы, CSV или API, строка ../ может вывести путь из ожидаемого каталога. Простая приписка расширения этого не исправляет. Нулевой байт из исторического примера PHP.net раньше мог обрезать путь на границе C; современные версии обычно отвергают такой путь, но правило остаётся тем же: внешний ввод не становится безопасным именем файла.

<?php
declare(strict_types=1);

$root = __DIR__ . '/safe-files';
mkdir($root);
file_put_contents($root . '/invoice.txt', 'Счёт №42');
file_put_contents($root . '/help.txt', 'Как оплатить заказ');

function readDocument(string $requested, string $root): ?string
{
    $files = [
        'invoice' => 'invoice.txt',
        'help' => 'help.txt',
    ];
    if (!array_key_exists($requested, $files)) {
        return null;
    }

    $rootPath = realpath($root);
    $filePath = realpath($root . DIRECTORY_SEPARATOR . $files[$requested]);
    if ($rootPath === false || $filePath === false) {
        return null;
    }
    $prefix = $rootPath . DIRECTORY_SEPARATOR;
    if (!str_starts_with($filePath, $prefix)) {
        return null; // В том числе защищает от ссылки наружу каталога.
    }

    $content = file_get_contents($filePath);
    return $content === false ? null : $content;
}

foreach (['invoice', '../secret', "invoice\0.php", 'help'] as $name) {
    $content = readDocument($name, $root);
    echo $name === 'invoice' ? 'invoice' : ($name === 'help' ? 'help' : 'чужое имя');
    echo ': ', $content ?? 'отказ', "\n";
}

unlink($root . '/invoice.txt');
unlink($root . '/help.txt');
rmdir($root);

invoice: Счёт №42
чужое имя: отказ
чужое имя: отказ
help: Как оплатить заказ

Дальше: файлы и каталоги, загрузка файлов и проверка владельца объекта.

База: роль, канал, хранение и SQL как четыре разные границы

У базы четыре разные границы: кто подключается, как защищён канал, какие данные можно вернуть и как строится SQL. Подготовленное выражение отделяет текст запроса от значения, но не решает выбор чужого заказа, избыточные права пользователя базы и шифрование хранилища.

<?php
declare(strict_types=1);

$db = new PDO('sqlite::memory:', null, null, [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
    PDO::ATTR_EMULATE_PREPARES => false,
]);
$db->exec('CREATE TABLE orders (id INTEGER PRIMARY KEY, user_id INTEGER, item TEXT)');
$db->exec("INSERT INTO orders VALUES
    (1, 7, 'Книга'),
    (2, 7, 'Кабель'),
    (3, 8, 'Чужой заказ')");

$hostile = '7 OR 1=1';
$unsafeSql = 'SELECT COUNT(*) FROM orders WHERE user_id = ' . $hostile;
echo 'Склейка дала строк: ', $db->query($unsafeSql)->fetchColumn(), "\n";

function ordersForUser(PDO $db, mixed $rawUserId): array
{
    if (!is_string($rawUserId) || !ctype_digit($rawUserId)) {
        return [];
    }
    $userId = (int) $rawUserId;
    if ($userId < 1) {
        return [];
    }

    $statement = $db->prepare(
        'SELECT item FROM orders WHERE user_id = :user_id ORDER BY id'
    );
    $statement->bindValue(':user_id', $userId, PDO::PARAM_INT);
    $statement->execute();
    return $statement->fetchAll(PDO::FETCH_COLUMN);
}

echo 'Тот же внешний ввод: ', json_encode(
    ordersForUser($db, $hostile),
    JSON_UNESCAPED_UNICODE | JSON_THROW_ON_ERROR
), "\n";
echo 'Пользователь 7: ', json_encode(
    ordersForUser($db, '7'),
    JSON_UNESCAPED_UNICODE | JSON_THROW_ON_ERROR
), "\n";

Склейка дала строк: 3
Тот же внешний ввод: []
Пользователь 7: ["Книга","Кабель"]

Полная работа с подключением, таблицей, транзакцией и ошибкой находится в практической главе PDO. Хранение пароля — в password_*, обратимое шифрование — в Sodium.

Ошибки: подробности разработчику, нейтральный ответ посетителю

Разработчику нужна причина сбоя; посетителю не нужны путь C:\sites\..., SQL, DSN, stack trace или секрет. Поэтому в разработке включают E_ALL, а в опубликованном окружении отключают показ ошибок, оставляют закрытый журнал и связывают две стороны безопасным request_id.

<?php
declare(strict_types=1);

function publicOrderResponse(callable $operation, string $requestId, string $log): string
{
    try {
        $operation();
        return 'Заказ сохранён.';
    } catch (Throwable $error) {
        $record = json_encode([
            'request_id' => $requestId,
            'event' => 'order_save_failed',
            'error_type' => $error::class,
        ], JSON_UNESCAPED_UNICODE | JSON_THROW_ON_ERROR);
        file_put_contents($log, $record . "\n", FILE_APPEND | LOCK_EX);
        return 'Не удалось сохранить заказ. Код обращения: ' . $requestId;
    }
}

$log = __DIR__ . '/private-error.log';
$requestId = 'req-demo-001'; // В сервисе создаётся непредсказуемо для запроса.
$answer = publicOrderResponse(
    static fn () => throw new RuntimeException('dsn=mysql:host=secret-db; password=hunter2'),
    $requestId,
    $log
);

echo 'Пользователь: ', $answer, "\n";
$privateRecord = file_get_contents($log);
echo 'Журнал связывает событие: ', str_contains($privateRecord, $requestId) ? 'да' : 'нет', "\n";
echo 'Секрет попал в журнал: ', str_contains($privateRecord, 'hunter2') ? 'да' : 'нет', "\n";
unlink($log);

Пользователь: Не удалось сохранить заказ. Код обращения: req-demo-001
Журнал связывает событие: да
Секрет попал в журнал: нет

Внешние данные: тип, форма, смысл, право и место назначения

«Пользовательские данные» — шире формы. Недоверенными приходят query, POST, JSON body, заголовки, cookies, имя загруженного файла, webhook, CSV поставщика и ответ внешнего API. Данные из базы тоже сохраняют происхождение: однажды импортированный HTML не становится безопасным только потому, что теперь лежит в таблице.

<?php
declare(strict_types=1);

function readOrderId(mixed $value): ?int
{
    if (!is_string($value) || $value === '' || !ctype_digit($value)) {
        return null;
    }

    $orderId = (int) $value;
    return $orderId >= 1 && $orderId <= 1_000_000 ? $orderId : null;
}

$requests = [
    'Обычная строка' => '42',
    'Массив вместо строки' => ['42'],
    'Строка с командой' => '42; DELETE',
    'Ноль вне диапазона' => '0',
];

foreach ($requests as $label => $raw) {
    $orderId = readOrderId($raw);
    echo $label, ': ', $orderId === null
        ? "отказ\n"
        : "заказ {$orderId}\n";
}

Обычная строка: заказ 42
Массив вместо строки: отказ
Строка с командой: отказ
Ноль вне диапазона: отказ

Скрытие PHP уменьшает подсказки, но не заменяет защиту

Отключение expose_php, удаление баннера сервера и нейтральные расширения уменьшают случайную выдачу сведений, но не создают границу доступа. Фреймворк, cookie, заголовки и поведение ошибок всё равно могут выдать стек. Атака также может идти без определения технологии.

Обновления: поддерживаемый стек, стенд, наблюдение и откат

«PHP обновлён» не означает, что обновлено приложение. В стек входят ОС и web-сервер, PHP runtime и расширения, Composer-зависимости, фреймворк/плагины, контейнерный образ и внешние сервисы. Для каждого нужна поддерживаемая ветка, источник уведомлений, тестовый стенд и понятный откат.

Актуальные даты нельзя навечно зашивать в статью: проверяйте официальные поддерживаемые версии PHP и уведомления каждого поставщика перед решением. Эта глава объясняет процесс, а не объявляет конкретную версию безопасной на все будущие даты.

Первая граница безопасности: пользовательский текст остаётся текстом

В отзыве человек может ввести угловые скобки. Когда сайт вставляет строку в HTML без обработки, браузер может принять её за разметку. Нам нужно показать сам текст, а не дать ему изменить страницу.

Что уже пригодится. переменная и присваивание, массив, объявление и вызов функции

htmlspecialchars($text, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8') принимает строку, правила преобразования и кодировку. | объединяет флаги. Результат возвращается строкой; функция не отправляет ответ сама.

<?php
declare(strict_types=1);

$title = '<b>Болт & гайка</b>';
$safeTitle = htmlspecialchars($title, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
echo '<p>' . $safeTitle . '</p>';

<p>&lt;b&gt;Болт &amp; гайка&lt;/b&gt;</p>

Следующая ступень. Дальше разделяем проверку формы, права пользователя, защиту запросов SQL и межсайтовые запросы. Одной универсальной «очистки строки» для всех этих мест нет.

Данные могут быть корректными и всё равно недопустимыми

Запрос /orders/42 содержит вполне корректное целое число. Но если заказ принадлежит другому покупателю, возвращать его нельзя. Валидация формата не заменяет проверку полномочий. Начинайте проектирование действия с вопроса: кто выполняет операцию, над каким объектом и при каких условиях? Проверку делают на сервере при каждом обращении, включая скачивание файла, AJAX и экспорт. Спрятанная кнопка в интерфейсе не является защитой.

Удобно описывать границу доверия: всё из браузера, внешнего API, импортированного CSV и административной формы считается внешними данными. Даже текст, который уже хранится в вашей базе, не становится безопасным HTML. Сотрудник может вставить вредный фрагмент по ошибке, а интеграция — принести его из каталога партнёра. Разрешение читать запись также не означает разрешение её изменять: роли и условия действия проверяются отдельно.

Авторизация должна быть близка к запросу данных или сервисной операции. Например, выборка WHERE id=:id AND customer_id=:customer_id уменьшает шанс забыть проверку владельца после чтения. Для администратора задайте явную политику. Если объект не должен быть виден посторонним, одинаковый ответ 404 для отсутствующего и чужого объекта не раскрывает факт существования.

<?php
declare(strict_types=1);

function canEditOrder(array $actor, array $order): bool {
    return $actor['role'] === 'manager'
        || ($actor['id'] === $order['customerId'] && $order['status'] === 'draft');
}
$order = ['customerId'=>7,'status'=>'draft'];
foreach ([['id'=>7,'role'=>'customer'],['id'=>8,'role'=>'customer'],
    ['id'=>8,'role'=>'manager']] as $actor) {
    echo canEditOrder($actor,$order) ? "allowed
" : "denied
";
}

allowed
denied
allowed

Экранирование зависит от места назначения

Для обычного текста HTML используют htmlspecialchars с UTF-8 и кавычками; для SQL — параметры PDO; для JSON — json_encode; для компонента URL — rawurlencode. Это разные грамматики. HTML-экранирование не лечит SQL-инъекцию. Подготовленный SQL не защищает HTML от XSS. Универсальной функции «сделать строку безопасной для всего» нет.

Не вставляйте внешнюю строку в inline-JavaScript, CSS или имя атрибута. Если данные нужны скрипту, безопаснее получать JSON отдельным запросом либо использовать корректно сериализованный блок данных с подходящими флагами и безопасным чтением. Для ссылок дополнительно проверяют допустимый протокол: htmlspecialchars не запретит javascript:. Разметку, введённую пользователем, очищают специализированным HTML-санитайзером с разрешённым набором элементов; strip_tags не является полноценной политикой безопасности.

Не вызывайте unserialize для недоверенного ввода: восстановление объектов способно запускать магические методы и цепочки библиотечного кода. Для обмена структурированными данными используйте JSON с проверкой схемы. eval, динамический include и shell-команды с пользовательской строкой расширяют поверхность атаки. Нередко безопасная альтернатива — разрешённый список операций и обычный вызов функции без запуска оболочки.

<?php
declare(strict_types=1);

function approvedLink(string $url): ?string {
    if (filter_var($url, FILTER_VALIDATE_URL) === false) return null;
    $scheme = strtolower((string) parse_url($url, PHP_URL_SCHEME));
    return in_array($scheme,['https','http'],true) ? $url : null;
}
foreach (['https://example.com/catalog','javascript:alert(1)','not a url'] as $url) {
    echo approvedLink($url) === null ? "reject
" : "allow
";
}

allow
reject
reject

Пароли, токены и журналы

Пароли хранят как результат password_hash, а проверяют password_verify. Не шифруйте пароль обратимо и не используйте md5 или обычный sha256. Соль и параметры уже входят в формат хеша. Столбец под PASSWORD_DEFAULT закладывайте с запасом, например 255 символов, поскольку алгоритм по умолчанию может измениться. Сложность выбирают измерением на своём сервере: вычисление специально дорогое, поэтому вход требует ограничений частоты.

После успешной проверки используйте password_needs_rehash и при необходимости сохраните новый хеш. Для bcrypt действует предел 72 байта: политика длинных паролей должна учитывать алгоритм, а не молча считать число символов. Argon2id требует поддержки сборкой. Секреты API берут из окружения или хранилища секретов, ограничивают по правам и ротируют; .env не размещают в public и не коммитят. Примеры в документации используют только тестовые значения.

Сообщение «неверная почта или пароль» уменьшает перечисление пользователей. Но одинаковый текст сам по себе не выравнивает время выполнения: для отсутствующего пользователя проверяют заранее подготовленный фиктивный хеш того же класса сложности. Не генерируйте дорогой фиктивный хеш на каждый запрос. MFA, уведомления о входе и серверные лимиты дополняют пароль; IP не является надёжной личностью пользователя.

Защита аккаунта — это жизненный цикл, а не одна функция

От создания хеша до одноразового восстановления сервер должен сохранять одну связь: кто доказал право, какое действие разрешено сейчас и какие старые возможности после изменения надо отозвать. Реальный HTTP-вход и выход показывает cookie, CSRF и смену ID; новые опыты добавляют смену пароля и сброс доступа.

Защита должна быть наблюдаемой

Производственные ошибки записывают в закрытый журнал, пользователю показывают нейтральный ответ с идентификатором обращения. Не возвращают SQL, файловые пути и конфигурацию. Журналы тоже надо защищать: экранировать переводы строк в пользовательских значениях, исключать Authorization, cookies и тела платёжных запросов, ограничивать срок хранения и доступ.

Для изменений каталога полезен аудит: актор, действие, идентификатор записи, время и безопасное описание изменения. Логирование не отменяет транзакционность. Для высокорисковых действий повторно подтверждают полномочия, проверяют актуальность сессии и обеспечивают защиту от повторов. CSP, HTTPS и заголовки безопасности добавляют уровни защиты, но не исправляют отсутствующую проверку владельца или вывод сырого HTML.

Практика: проверьте решение, а не только успешный путь

Администратор импортировал название товара <img src=x onerror=alert(1)>. Где исправлять: при сохранении в базу или при показе карточки?

Применить разные границы в одном кабинете

Полный локальный кабинет соединяет проверки: типы полей → CSRF → пароль → новый ID → сроки → безопасный вывод → POST-выход. Отдельно сохранены все правила XSS/SQL/SSRF и доверия этой главы: ни одна из этих проверок не заменяет остальные.

Упражнение: измените idle30 на10, войдите при1000 и запросите кабинет при1010. Ожидается форма входа с сообщением об истечении. Затем верните30. Не делайте срок полем запроса клиента.