Суперглобални променливи: $_GET, $_POST, $_FILES и др.

Накратко: Суперглобалните променливи са предварително дефинирани масиви, които PHP запълва автоматично при всяка заявка и които са достъпни навсякъде в кода. $_GET съдържа параметрите от адреса, $_POST данните от формулярите, $_FILES качените файлове, $_COOKIE бисквитките, а $_SERVER данни за заявката и сървъра. PHP създава тези масиви, преди да стартира кодът на Вашето приложение. Затова уязвимости именно в тази обработка, както при PHP2Shell, не могат да бъдат прихванати чрез проверки в приложението.

Какво са суперглобалните променливи?

В PHP една променлива обикновено важи само във функцията, в която е създадена. Суперглобалните променливи са изключението: те са на разположение във всеки обхват, без да е нужно да се вземат с global. Ръководството на PHP назовава девет от тях.

За нетехническите хора това може да се опише така: суперглобалните променливи са пощенската кутия на приложението. Всичко, което посетителят изпрати, попада там, преди приложението да го прочете. И всичко в пощенската кутия потенциално идва от непознат.

Суперглобалните променливи накратко

Особено коварна е $_SERVER. Според ръководството PHP създава за всеки заглавен ред на заявката запис с HTTP_ в началото, например HTTP_USER_AGENT. Тези стойности се задават от самия клиент. И SERVER_NAME според ръководството може да съдържа предоставеното от клиента име на хост и не е надеждно за решения, свързани със сигурността.

Как PHP запълва суперглобалните променливи

Преди да се изпълни първият знак на Вашия скрипт, PHP вече е работил. Той чете адреса, заглавните редове и съдържанието на заявката, разчленява ги и поставя резултатите в масивите. Този етап се управлява от няколко настройки:

1. variables_order (по подразбиране EGPCS) определя кои суперглобални променливи изобщо се създават: Environment, GET, POST, Cookie, Server.
2. request_order (по подразбиране празен) определя от какво се образува $_REQUEST. Ако е празен, важи variables_order. Доставяните файлове php.ini според ръководството пропускат бисквитките от съображения за сигурност.
3. max_input_vars (по подразбиране 1000) и max_input_nesting_level (по подразбиране 64) ограничават броя и вложеността на входните променливи.
4. post_max_size (по подразбиране 8M) ограничава съдържанието на заявката. Ако една заявка е по-голяма, $_POST и $_FILES остават празни.
5. enable_post_data_reading (по подразбиране включена) управлява дали PHP изобщо оценява автоматично съдържанието на POST заявките.

Ако enable_post_data_reading е изключена, приложението чете суровото съдържание само през php://input. От PHP 8.4.0 има допълнително request_parse_body(), което оценява данните от формуляри и качвания и за други методи освен POST и позволява собствени гранични стойности. Как протича частта с качването в детайли, обяснява страницата Как PHP обработва качването на файлове.

Сигурна работа с данните от заявките

Основното правило е просто: всяка стойност от $_GET, $_POST, $_COOKIE, $_FILES и записите HTTP_ на $_SERVER е чужд вход. Тя се проверява при приемането и се екранира подходящо при извеждането.

<?php
declare(strict_types=1);

// Очаква се цяло число: проверка вместо сляпо преобразуване
$seite = filter_var($_GET['seite'] ?? '1', FILTER_VALIDATE_INT, [
    'options' => ['min_range' => 1, 'max_range' => 500],
]);
if ($seite === false) {
    http_response_code(400);
    exit('Ungültige Seitenzahl');
}

// Позволявай само разрешени стойности
$sortierung = in_array($_GET['sort'] ?? '', ['name', 'datum'], true)
    ? $_GET['sort']
    : 'datum';

// Изходът винаги се екранира
echo htmlspecialchars($_POST['kommentar'] ?? '', ENT_QUOTES, 'UTF-8');

Честа клопка са данните за произхода на една заявка. Ако пред уеб сървъра стои reverse proxy, load balancer или CDN, $_SERVER['REMOTE_ADDR'] съдържа адреса на този посредник, а не на посетителя. Истинският адрес тогава стои в заглавен ред като X-Forwarded-For, който обаче всеки клиент може да зададе сам. Приложението бива да оценява такива заглавни редове само ако заявката доказано идва от собствен, известен proxy. Иначе блокиранията по IP адрес или протоколите лесно могат да бъдат подведени. Сходно важи за HTTPS: ако криптирането завършва при proxy, приложението трябва изрично да знае, че първоначалната връзка е била криптирана.

Допълнителни шаблони за валидиране и филтриране показва статията Валидиране и филтриране на входа в PHP. За данните на сесията в $_SESSION важат собствени правила; те са описани на страницата Сесии и бисквитки в PHP.

Суперглобални променливи и PHP2Shell: какво става преди Вашия код

Тук е връзката с актуалното положение. CVE-2026-109618 описва, че състояние на изчерпана памет (out-of-memory) може да прекъсне PHP, докато данните от заявката са инициализирани само частично; при почистването на заявката невалидни данни след това могат да бъдат третирани като валидни. При CVE-2026-109619 вътрешно състояние на заявка може да остане след освобождаването на паметта и да бъде използвано от по-късна заявка в същия работен процес.

И двете уязвимости са следователно в обработката, която PHP сам извършва около заявката, а не в кода на приложението. Екипът на PHP оценява риска при mod_php като най-висок; там е показан експлойт, преди изобщо да се изпълни код на приложението. Никакъв filter_var() и никаква проверка в приложението не може да предотврати това.

Как помага PHP SOS конкретно?

• Проверяваме ефективните гранични стойности за данните на заявките за всеки уебсайт и ги задаваме съобразно приложението.
• Внасяме актуализацията на PHP, рестартираме всички работни процеси и доказваме състоянието на корекциите в рамките на нашата услуга за PHP корекции.
• Проверяваме собствените разработки дали стойности от суперглобални променливи стигат непроверени до база данни, файлова система или изход.
• Запазваме логовете на уеб сървъра от 20.10.2026 г., за да остане възможен по-късен анализ.

Често задавани въпроси

Източници

• Ръководство на PHP: Суперглобални променливи
• Ръководство на PHP: $_SERVER
• Ръководство на PHP: директиви на php.ini
• Ръководство на PHP: request_parse_body