# Речник: PHP и ИТ сигурност

> Специализирани термини за PHP и ИТ сигурност, обяснени накратко.

Източник: https://phpsos.de/bg/glossar/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**2FA**: 2FA (двуфакторно удостоверяване) изисква при вход освен паролата и втори документ за самоличност, например код от приложение или ключ за сигурност. Откраднатата парола сама по себе си вече не стига. За всички административни достъпи до CMS, хостинг панел и сървъри 2FA трябва да е стандарт. Още: [Настройване на двуфакторно удостоверяване за администраторски достъпи](https://phpsos.de/bg/ratgeber/zwei-faktor-admin/)

**Apache**: Apache HTTP Server е един от най-старите и най-разпространените уеб сървъри. PHP работи в него или като модул (mod_php), или чрез PHP-FPM през FastCGI. С .htaccess файлове конфигурацията може да се настройва по директории. Още: [Как да обезопасите Apache с mod_php](https://phpsos.de/bg/server/apache-mod-php/)

**Backdoor (задна вратичка)**: Backdoor (задна вратичка) е скрит достъп, през който атакуващите могат да се върнат след пробив. Това може да е файл, администраторски акаунт, cron задача или SSH ключ. Затова всяко почистване включва търсене на всички видове достъпи, а не само на файлове. Още: [Откриване на задна вратичка в WordPress: систематично търсене](https://phpsos.de/bg/ratgeber/backdoor-wordpress-finden/)

**Backport**: Backport пренася корекция за сигурност в по-стара версия на програма, без да се преминава към новата версия. Linux дистрибуциите и хостинг доставчиците го правят често; показаният номер на версията тогава остава същият. Дали backport е инсталиран, доказват changelog на пакета и потвърждението на доставчика, а не номерът. Още: [Ъпгрейд на PHP или backport? Решението за стари системи](https://phpsos.de/bg/blog/php-upgrade-oder-backport/)

**Brute Force (груба сила)**: При атака с груба сила (brute force) атакуващ автоматизирано изпробва много пароли за един акаунт. Целта често са административните входове на CMS, SSH или FTP. Защита дават силни пароли, двуфакторно удостоверяване и автоматични блокирания като Fail2ban. Още: [Защита на админ входовете от brute force: защита от brute force за всеки вход](https://phpsos.de/bg/ratgeber/brute-force-login-schutz/)

**BSI**: BSI (Bundesamt für Sicherheit in der Informationstechnik, Федерална служба за информационна сигурност на Германия) е органът на федерално ниво за киберсигурност. Той публикува предупреждения, препоръки и стандарти като IT-Grundschutz. По повод PHP2Shell BSI обяви ниво на предупреждение 3 (оранжево) и препоръча незабавна актуализация. Още: [Какво препоръчва BSI за PHP2Shell](https://phpsos.de/bg/compliance/bsi-empfehlungen/)

**CDN**: CDN (Content Delivery Network) доставя съдържание през много разпределени сървъри и стои пред самия уебсайт. Много CDN предлагат допълнително WAF правила, например Cloudflare срещу PHP2Shell. Защитата действа само за трафика през CDN и не заменя актуализацията на PHP. Още: [Правилата за защита на Cloudflare срещу PHP2Shell: какво постигат и какво не](https://phpsos.de/bg/blog/cloudflare-waf-php2shell/)

**CERT-Bund**: CERT-Bund е екипът за реагиране при компютърни инциденти на германската федерална администрация към BSI. Той публикува предупредителни и информационни услуги за уязвимости и уведомява мрежовите оператори за уязвими системи. CERT-Bund е предупредил и във връзка с PHP2Shell. Още: [Какво съветват CERT-EU и CERT-Bund за PHP2Shell](https://phpsos.de/bg/blog/cert-eu-empfehlungen-php/)

**CERT-EU**: CERT-EU е екипът за киберсигурност на институциите, органите и агенциите на Европейския съюз. Според доклади CERT-EU смята за възможно при PHP2Shell да са засегнати версии от PHP 5 нататък. Той препоръчва публично достъпните приложения да се изолират, ако не могат да бъдат пачнати своевременно. Още: [Какво съветват CERT-EU и CERT-Bund за PHP2Shell](https://phpsos.de/bg/blog/cert-eu-empfehlungen-php/)

**CGI**: CGI (Common Gateway Interface) е стар интерфейс, при който уеб сървърът стартира външна програма при всяка заявка и връща нейния изход. Той е прост, но бавен, и за PHP е изместен до голяма степен от FastCGI. Стари CGI конфигурации все още се срещат на някои хостинг и Windows системи. Още: [CGI и FastCGI: основите](https://phpsos.de/bg/php/cgi-und-fastcgi/)

**cgroups**: cgroups (Control Groups) са функция на ядрото на Linux, с която могат да се ограничават паметта, процесорът и други ресурси за групи процеси. Контейнерите и systemd ги използват, например с MemoryMax. php.net препоръчва като временна мярка срещу PHP2Shell ограничение на паметта чрез контейнер или cgroup вместо чрез RLIMIT_AS или RLIMIT_DATA. Още: [Задаване на лимити на паметта със systemd и cgroups](https://phpsos.de/bg/blog/speichergrenzen-systemd-cgroups/)

**Chain of Custody (верига на съхранение)**: Chain of custody (верига на съхранение на доказателствата) документира без пропуски кой кога е запазил, предал и обработил едно доказателство. Допълнена с контролни суми, тя доказва, че данните не са променяни. Без тази документация следите губят стойност пред съда или пред застрахователите. Още: [ИТ форензика след атака срещу уеб сървър](https://phpsos.de/bg/leistungen/it-forensik/)

**Changelog**: Changelog изброява промените във версия на програма или пакет, при корекции за сигурност обикновено с номер CVE. При Debian и Ubuntu apt-get changelog показва changelog на пакета, а в семейството на RHEL – rpm -q --changelog. Така backport може да се докаже и при един и същ номер на версията. Още: [Доказване на CVE номера в changelog на пакета](https://phpsos.de/bg/blog/cve-im-changelog-nachweisen/)

**CLI**: CLI (Command Line Interface) е PHP в командния ред, например за cron задачи, конзолни команди на CMS и Composer. PHP в CLI може да е друга версия от PHP, който обслужва уеб страниците. Затова командата php -v показва само версията за командния ред; и двата пътя трябва да са коригирани. Още: [PHP в командния ред (CLI)](https://phpsos.de/bg/php/php-cli/)

**CloudLinux**: CloudLinux е Linux дистрибуция за споделен хостинг, която разделя клиентите в ограничени среди. С alt-php тя предоставя много версии на PHP едновременно, включително по-стари. Всяка от тези версии трябва да бъде пачната поотделно. Още: [CloudLinux и alt-php: какво трябва да знаят хостинг клиентите](https://phpsos.de/bg/blog/cloudlinux-alt-php/)

**Composer**: Composer е мениджърът на пакети за PHP. Той инсталира библиотеки според записите в composer.json и съхранява точните версии в composer.lock. С composer audit инсталираните пакети могат да се проверят за известни уязвимости; уязвимости в самия PHP командата не открива. Още: [Composer: управлението на пакети за PHP](https://phpsos.de/bg/php/composer/)

**cPanel**: cPanel е панел за управление на уеб хостинг, с WHM като интерфейс за администратора на сървъра. Версиите на PHP там се предоставят най-често чрез собствени пакети (EasyApache). Кои билдове са коригирани, потвърждават състоянието на пакета и хостинг доставчикът. Още: [cPanel и WHM: как да обезопасите PHP](https://phpsos.de/bg/server/cpanel/)

**Credential Stuffing**: При credential stuffing атакуващите изпробват данни за достъп от предишни изтичания на данни при други услуги. Това работи, защото много хора използват една и съща парола многократно. Защита дават уникални пароли за всяка услуга и двуфакторно удостоверяване. Още: [Настройване на двуфакторно удостоверяване за администраторски достъпи](https://phpsos.de/bg/ratgeber/zwei-faktor-admin/)

**CSP**: CSP (Content Security Policy) е хедър, който определя от кои източници една страница може да зарежда скриптове, изображения и друго съдържание. Тя затруднява XSS и внедряването на чужди скриптове, например при скимване. Строга CSP трябва да се тества внимателно, за да продължи уебсайтът да работи. Още: [Хедъри за сигурност на уебсайтове: правилно задаване на Security Headers](https://phpsos.de/bg/ratgeber/sicherheits-header/)

**CSRF**: CSRF (Cross-Site Request Forgery) принуждава браузъра на влязъл потребител нежелано да извърши действие на друг уебсайт. Типични са промени в административни области. Защита дават случайни токени във формите и бисквитки с атрибут SameSite. Още: [CSRF защита в PHP приложения](https://phpsos.de/bg/blog/csrf-schutz-php/)

**CVE**: CVE (Common Vulnerabilities and Exposures) е използван в световен мащаб каталог, който дава на всяка известна уязвимост уникален номер, например CVE-2026-109618. Номерът прави съобщенията на производители, органи и дистрибуции съпоставими. По номера CVE може да се провери и в changelog на пакета дали корекцията е инсталирана. Още: [Доказване на CVE номера в changelog на пакета](https://phpsos.de/bg/blog/cve-im-changelog-nachweisen/)

**CVSS**: CVSS (Common Vulnerability Scoring System) оценява тежестта на една уязвимост по скала от 0 до 10. Оценката отчита например дали е възможна атака през мрежата и без вход. Уязвимостите PHP2Shell имат по CVSS v4.0 9,2; за конкретния риск във Вашата среда стойността сама по себе си не казва нищо.

**DDoS**: DDoS атаката (Distributed Denial of Service) претоварва една услуга със заявки от много източници, докато тя престане да бъде достъпна. Данни по правило не се крадат. DDoS трябва да се отличава от експлойт, който целенасочено използва уязвимост. Още: [DDoS или хакерска атака? Правилна преценка на атаките](https://phpsos.de/bg/ratgeber/ddos-oder-exploit/)

**Defacement (обезобразяване на сайт)**: При defacement атакуващите променят видимо началната страница или съдържанието на уебсайт, например с послания или изображения. То бие на очи, но често е само видимият знак на по-дълбок пробив. Уебсайтът трябва да се третира като компрометиран, докато ситуацията не бъде изяснена. Още: [Хакнат уебсайт: какво да правя? Спешна помощ отдалечено](https://phpsos.de/bg/leistungen/website-gehackt-notfallhilfe/)

**disable_functions**: disable_functions е настройка в php.ini, с която се изключват отделни PHP функции, обикновено тези за изпълнение на системни команди. Тя може да се задава само в php.ini, не в кода на приложението. Затруднява живота на атакуващите, но не заменя нито актуализациите, нито правилните права. Още: [Правилно използване на PHP disable_functions](https://phpsos.de/bg/ratgeber/disable-functions/)

**display_errors**: display_errors определя дали PHP показва съобщенията за грешки директно в браузъра. В продукционна среда стойността трябва да е Off, а грешките се записват с log_errors в протокол. Иначе видимите съобщения издават пътища, версии и откъси от код. Още: [display_errors off: изключване на изхода на грешки в продукция](https://phpsos.de/bg/blog/display-errors-produktion/)

**EDR**: EDR (Endpoint Detection and Response) е софтуер на сървъри и работни места, който наблюдава процеси, достъпи до файлове и мрежови връзки и съобщава за подозрително поведение или го спира. На уеб сървъри той може например да разпознае, че PHP-FPM стартира шел. Тъй като за PHP2Shell няма потвърдени IOC, подобен анализ на поведението е особено важен. Още: [Предупредителен сигнал: уеб сървърът стартира shell](https://phpsos.de/bg/blog/webserver-startet-shell/)

**End of Life (край на поддръжката)**: End of Life (EOL) означава, че една версия на софтуер вече не получава актуализации от производителя, дори и корекции за сигурност. PHP 8.1 и по-стари версии вече не получават официални актуализации от проекта PHP; за 7.4, 8.0 и 8.1 има само минимални backport корекции в изходния код. Системите със софтуер в EOL се нуждаят от план за надграждане. Още: [PHP End of Life: рискове от остарели версии](https://phpsos.de/bg/ratgeber/php-end-of-life-risiken/)

**Exploit (експлойт)**: Експлойт е код или метод, който реално експлоатира конкретна уязвимост. Щом се появи пач, атакуващите могат да го анализират и да изведат експлойти. Затова след публикуването на пач времето до атаките често се съкращава значително. Още: [Времевият прозорец между пач и атака](https://phpsos.de/bg/blog/zeitfenster-patch-angriff/)

**expose_php**: expose_php определя дали PHP издава версията си в HTTP хедъра X-Powered-By. В продукционна среда настройката трябва да е Off, за да не виждат атакуващите веднага коя версия на PHP работи. Това е защита на информацията, не заместител на актуализацията. Още: [expose_php и Server заглавия: скриване на данните за версиите](https://phpsos.de/bg/blog/expose-php-versionsangaben/)

**Extension (разширение)**: Разширението (extension) допълва PHP с функции, например за бази данни, изображения или криптиране. Разширенията работят в същия процес като PHP и имат същите права. Изключването на ненужните разширения намалява повърхността за атака. Още: [Разбиране на PHP разширенията (Extensions)](https://phpsos.de/bg/php/php-erweiterungen/)

**Fail2ban**: Fail2ban чете лог файлове и блокира временно IP адреси във файъруола след повторни неуспешни опити. Типични области на приложение са SSH, имейл и административните входове на уебсайтове. Срещу разпределени атаки от много адреси помага само ограничено. Още: [Настройка на Fail2ban за уеб сървъри](https://phpsos.de/bg/blog/fail2ban-fuer-webserver/)

**FastCGI**: FastCGI е протокол, чрез който уеб сървърът предава заявки на постоянно работещи програмни процеси, например на PHP-FPM. За разлика от класическия CGI не се стартира нов процес при всяка заявка. Тъй като процесите обработват последователно много заявки, след актуализации е важно рестартиране по правилния начин. Още: [CGI и FastCGI: основите](https://phpsos.de/bg/php/cgi-und-fastcgi/)

**FPM пул**: Пулът е група от PHP-FPM процеси със собствена конфигурация, собствен сокет и в идеалния случай собствен системен потребител. Отделен пул за всеки уебсайт разделя сайтовете един от друг, така че пробив в един сайт да не достига директно файловете на останалите. В пула настройките могат да се зададат твърдо чрез php_admin_value. Още: [Изолиране на PHP-FPM пулове за всеки сайт](https://phpsos.de/bg/blog/php-fpm-pools-isolieren/)

**FrankenPHP**: FrankenPHP е съвременен сървър за приложения на PHP, базиран на уеб сървъра Caddy. PHP е вграден директно в него, а в worker режим приложението остава в паметта между заявките. Според екипа на PHP FrankenPHP е сред засегнатите режими на работа; след актуализацията сървърът трябва да се рестартира с новия PHP. Още: [Как да обезопасите FrankenPHP](https://phpsos.de/bg/server/frankenphp/)

**GHSA**: GHSA е идентификаторът на GitHub Security Advisory, т.е. на съобщение за сигурност в базата данни на GitHub. Много проекти с отворен код, включително PHP, публикуват там своите съобщения допълнително към номера CVE. За PHP2Shell това са GHSA-w8hw-w9fx-j79w и GHSA-6wmf-4rv5-p3rp.

**HSTS**: HSTS (HTTP Strict Transport Security) е хедър, с който един уебсайт съобщава на браузъра да го отваря за определено време само през HTTPS. Това пречи връзките да бъдат понижени до некриптиран HTTP. Преди включването HTTPS трябва да работи надеждно на всички засегнати домейни. Още: [Хедъри за сигурност на уебсайтове: правилно задаване на Security Headers](https://phpsos.de/bg/ratgeber/sicherheits-header/)

**.htaccess**: .htaccess файловете са конфигурационни файлове по директории за Apache и съвместими сървъри като LiteSpeed. CMS ги използват за пренасочвания и защита на достъпа, а атакуващите – за скрити пренасочвания. Nginx не обработва .htaccess; защитните правила там трябва да са в конфигурацията на сървъра. Още: [Сигурна конфигурация на Apache за PHP](https://phpsos.de/bg/blog/apache-fuer-php-absichern/)

**Image digest**: Image digest е хеш стойност (sha256), която еднозначно определя съдържанието на образ на контейнер. За разлика от таг като php:8.3-fpm, който може да бъде преместен към нови билдове, digest никога не се променя. Който фиксира образите по digest, трябва да го актуализира съзнателно след актуализация за сигурност. Още: [Официални PHP Docker образи: тагове, digest и ново изграждане](https://phpsos.de/bg/blog/offizielle-php-docker-images/)

**Incident Response (реагиране при инциденти)**: Incident response е организираната обработка на инцидент със сигурността: разпознаване, ограничаване, запазване на следите, почистване, възстановяване и последваща оценка. Установеният ред пречи в суматохата да бъдат унищожени доказателства или да бъдат пропуснати задни вратички. Важни са ясни отговорности и непрекъснато документиране. Още: [Реагиране при инциденти (Incident Response) при атаки на сървъри](https://phpsos.de/bg/leistungen/incident-response/)

**ini_set()**: ini_set() е PHP функция, с която скрипт променя настройки по време на изпълнение. Какво може да промени един скрипт, зависи от режима на промяна на настройката. Тъй като и злонамерен код може да извика ini_set(), защитните настройки принадлежат в конфигурацията на сървъра или на пула, а не в кода на приложението. Още: [php.ini, обяснен: структура, нива и приоритет](https://phpsos.de/bg/php/php-ini-erklaert/)

**IOC**: IOC (Indicator of Compromise) са конкретни следи от атака, например имена на файлове, хеш стойности, IP адреси или домейни. С тях системите могат да се проверят целенасочено за известна атака. За PHP2Shell няма публикувани, потвърдени IOC; откриването се основава на анализ на поведението. Още: [Вече компрометиран ли съм? Признаци след PHP2Shell](https://phpsos.de/bg/php2shell/bin-ich-gehackt-anzeichen/)

**ISO 27001**: ISO/IEC 27001 е международният стандарт за системи за управление на информационната сигурност (СУИС). Той изисква уреден подход към рисковете, мерките и подобренията, включително управление на уязвимостите и на инцидентите. Фирмите могат да се сертифицират по него. Още: [ISO 27001 и TISAX: какво засяга уеб сървърите](https://phpsos.de/bg/blog/iso-27001-tisax-webserver/)

**IT-Grundschutz**: IT-Grundschutz на BSI е методика с модули и изисквания за информационна сигурност във фирми и органи. Има отделни модули например за уеб сървъри и уеб приложения. Може да се използва като основа за СУИС или за сертификация. Още: [CIS Benchmarks и модули на BSI за уеб сървъри](https://phpsos.de/bg/blog/cis-benchmarks-bsi-bausteine/)

**JIT**: JIT (Just-in-Time компилатор) превежда често изпълнявания PHP код в машинен код по време на работа. Той е добавен с PHP 8.0 и е част от OPcache. При обикновени уебсайтове ползата за производителността е обикновено малка, а при изчислително тежки задачи е по-голяма. Още: [JIT и производителност в PHP 8](https://phpsos.de/bg/php/jit-und-performance/)

**Least Privilege (минимални права)**: Least Privilege (принцип на минималните права) означава, че всеки потребител и всеки процес получава само правата, от които наистина се нуждае. Ако PHP работи с ограничени права, атакуващият може да причини по-малко щети след пробив. Това засяга системните потребители, правата върху файловете, акаунтите в базата данни и административните достъпи. Още: [Least Privilege: права на потребителя на уеб сървъра](https://phpsos.de/bg/blog/rechte-des-webserver-benutzers/)

**Lessons Learned (изводи от инцидента)**: Lessons learned е последващата оценка на един инцидент: какво се е случило, какво е минало добре, какво трябва да се промени? Целта са конкретни мерки с отговорници и срокове, а не обвинения. Резултатите се вливат в плана за спешни случаи, процеса на пачване и обученията. Още: [Lessons Learned: да станем по-добри след инцидента](https://phpsos.de/bg/blog/lessons-learned-nach-vorfall/)

**LFI**: LFI (Local File Inclusion) е налице, когато приложение включва локален файл, чийто път атакуващият може да повлияе. Така могат да се четат конфигурационни файлове или при някои обстоятелства да се изпълни внедрен код. Защита дават фиксирани списъци с разрешени стойности вместо имена на файлове от въвеждани данни. Още: [Предотвратяване на Local File Inclusion във PHP: LFI и RFI](https://phpsos.de/bg/ratgeber/lfi-rfi/)

**LiteSpeed**: LiteSpeed е уеб сървър, който е до голяма степен съвместим с конфигурации на Apache като .htaccess и свързва PHP чрез собствения си интерфейс LSAPI. Разпространен е при хостинг доставчиците; OpenLiteSpeed е свободният вариант. Според екипа на PHP LiteSpeed е сред режимите на работа, засегнати от PHP2Shell. Още: [LiteSpeed и LSAPI: как да актуализирате PHP](https://phpsos.de/bg/server/litespeed/)

**memory_limit**: memory_limit ограничава колко оперативна памет може да заема един PHP скрипт; по подразбиране са 128 MB. При достигане на границата PHP прекъсва работата с грешка за недостиг на памет. Срещу CVE-2026-109618 php.net препоръчва като временна мярка memory_limit=-1, зададен твърдо, и ограничение на паметта чрез контейнер или cgroup. Още: [Правилна настройка на memory_limit](https://phpsos.de/bg/blog/memory-limit-richtig-setzen/)

**mod_php**: mod_php е PHP модулът за уеб сървъра Apache. При него PHP работи директно в процеса на Apache и най-често с правата на неговия потребител. Екипът на PHP оценява риска от PHP2Shell при mod_php като най-висок; там е показан експлойт още преди да започне да се изпълнява какъвто и да е код на приложението. Още: [mod_php, обяснен: PHP в процеса на Apache](https://phpsos.de/bg/php/mod-php-erklaert/)

**ModSecurity**: ModSecurity е разпространена WAF с отворен код, която работи като модул в Apache, Nginx или други уеб сървъри. Тя оценява заявките по правила и може да ги записва в протокол или да ги блокира. Най-често се използва заедно с OWASP Core Rule Set. Още: [Внедряване на ModSecurity и OWASP Core Rule Set](https://phpsos.de/bg/blog/modsecurity-owasp-crs/)

**Nginx**: Nginx е разпространен уеб сървър и reverse proxy. Той не изпълнява PHP сам, а предава заявките чрез FastCGI на PHP-FPM. Важна е конфигурация, която предава на PHP само истински PHP файлове и изключва папките за качване. Още: [Как да обезопасите Nginx с PHP-FPM](https://phpsos.de/bg/server/nginx-php-fpm/)

**NIS2**: NIS2 е директива на ЕС, която определя за много фирми и организации задължения за управление на риска и за уведомяване за инциденти със сигурността. Тя засяга значително повече браншове и размери на фирми от предишната уредба. Дали Вашата фирма е обхваната, трябва да изясните въз основа на националното прилагане и с правна консултация. Още: [NIS2 и сигурност на уеб сървърите](https://phpsos.de/bg/compliance/nis2/)

**OPcache**: OPcache е вграденият кеш за байткод на PHP. Той съхранява вече преведения код в споделена памет, за да не се компилират PHP файловете наново при всяка заявка. След актуализация или почистване кешът трябва да се изчисти, респективно PHP да се рестартира, иначе може да продължи да се изпълнява стар код. Още: [OPcache, обяснен: кешът за байткод на PHP](https://phpsos.de/bg/php/opcache/)

**open_basedir**: open_basedir ограничава до кои директории PHP скриптовете имат достъп с файловите функции. На сървъри с няколко уебсайта това пречи един сайт лесно да чете файловете на друг. Това не е пълна изолация; към нея спадат и отделните системни потребители и FPM пулове. Още: [open_basedir и изолация за всеки уебсайт](https://phpsos.de/bg/ratgeber/open-basedir/)

**Origin сървър**: Origin сървърът е същинският уеб сървър зад CDN или reverse proxy. Ако е достъпен и директно през своя IP адрес, атакуващите могат да заобиколят защитата пред него. Затова origin сървърът трябва да приема връзки само от CDN или от проксито. Още: [Правилата за защита на Cloudflare срещу PHP2Shell: какво постигат и какво не](https://phpsos.de/bg/blog/cloudflare-waf-php2shell/)

**Out of Memory (недостиг на памет)**: Out of Memory е състоянието, в което една програма не получава повече памет и трябва да прекрати работата си. В PHP това се случва, когато memory_limit бъде надвишен. При CVE-2026-109618 такова прекъсване може да спре PHP, докато данните от заявката са инициализирани само частично. Още: [memory_limit и Out-of-Memory: какво се случва отвътре](https://phpsos.de/bg/php/out-of-memory/)

**OWASP CRS**: OWASP Core Rule Set (CRS) е свободно достъпен набор от правила за ModSecurity и съвместими WAF. Той разпознава типични класове атаки като SQL инжекция или инжектиране на команди. Правилата трябва да се съобразят с приложението, иначе блокират и легитимни заявки. Още: [Внедряване на ModSecurity и OWASP Core Rule Set](https://phpsos.de/bg/blog/modsecurity-owasp-crs/)

**OWASP Top 10**: OWASP Top 10 е редовно актуализиран списък на най-важните рискове за уеб приложенията, издаван от нестопанската организация OWASP Foundation. Той служи като основа за разработка, проверки и обучения. В допълнение OWASP предлага Cheat Sheets с конкретни противомерки.

**PECL**: PECL (PHP Extension Community Library) е каталогът за PHP разширения, написани на C, които не са част от стандартния комплект. Такива разширения трябва да съответстват на инсталираната версия на PHP. След смяна на основната версия на PHP те често трябва да се компилират наново или да се заменят. Още: [Разбиране на PHP разширенията (Extensions)](https://phpsos.de/bg/php/php-erweiterungen/)

**PHP**: PHP е скриптов език, който работи най-вече на уеб сървъри и там генерира уеб страници. Много разпространени CMS и магазинни системи като WordPress, TYPO3 или Shopware са написани на PHP. Уязвимост в интерпретатора на PHP засяга всички приложения, които работят върху него, независимо от собственото им състояние на актуализация. Още: [Какво е PHP? Езикът за програмиране, обяснен](https://phpsos.de/bg/php/was-ist-php/)

**php-cgi**: php-cgi е PHP програмата за работа през CGI или FastCGI. Според екипа на PHP тя е сред режимите на работа, засегнати от PHP2Shell. Където php-cgi все още се използва, си струва да се провери дали е възможен преход към PHP-FPM. Още: [php-cgi: наследство с риск](https://phpsos.de/bg/server/php-cgi/)

**PHP-FPM**: PHP-FPM (FastCGI Process Manager) е самостоятелна услуга, която управлява PHP процеси в пулове и приема заявки от уеб сървъра чрез FastCGI. Днес това е обичайният режим на работа с Nginx и на много Apache сървъри. След актуализация на PHP трябва да се рестартира PHP-FPM, за да не продължат да работят стари процеси. Още: [PHP-FPM, обяснен: мениджър на процесите, пулове и работни процеси](https://phpsos.de/bg/php/php-fpm-erklaert/)

**php.ini**: php.ini е централният конфигурационен файл на PHP. Той определя ограничения, настройки за сигурност и за грешки, например memory_limit или display_errors. Често за всеки SAPI (FPM, CLI, Apache) има собствен php.ini, който трябва да се поддържа отделно. Още: [php.ini, обяснен: структура, нива и приоритет](https://phpsos.de/bg/php/php-ini-erklaert/)

**PHP2Shell**: PHP2Shell е името на две критични уязвимости в самия PHP, CVE-2026-109618 и CVE-2026-109619, и двете с CVSS v4.0 9,2. Те позволяват изпълнение на злонамерен код от разстояние без вход в системата. Отстранени са в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, публикувани на 21.10.2026 г. Още: [Какво е PHP2Shell? Уязвимостта, обяснена просто](https://phpsos.de/bg/php2shell/was-ist-php2shell/)

**php_admin_value**: php_admin_value задава PHP настройка в FPM пула или в конфигурацията на Apache така, че приложенията да не могат да я презапишат чрез ini_set() или .htaccess. За превключватели има php_admin_flag. php.net препоръчва този път за временните мерки срещу PHP2Shell, например за memory_limit. Още: [php_admin_value: заключване на настройки срещу презаписване](https://phpsos.de/bg/blog/php-admin-value-sperren/)

**Plesk**: Plesk е разпространен панел за управление на уеб сървъри, с който могат да се настройват домейни, версии на PHP и handler за всеки уебсайт. Той носи собствени PHP пакети, но може да ползва и PHP пакетите на дистрибуцията. При backport Plesk може да продължи да показва по-стар номер като 8.2.34, макар пачът да е инсталиран. Още: [Plesk сървър: проверка и пач на версиите на PHP](https://phpsos.de/bg/server/plesk/)

**post_max_size**: post_max_size определя колко голямо може да бъде общото съдържание на една POST заявка; по подразбиране са 8 MB. Като временна мярка срещу PHP2Shell php.net посочва 8M за уебсайтове без качване на файлове и 32M при качване. upload_max_filesize трябва да е под тази стойност. Още: [Разумно ограничаване на post_max_size и upload_max_filesize](https://phpsos.de/bg/blog/post-max-size-upload-limits/)

**Proof of Concept (доказателство за концепцията)**: Proof of Concept (PoC) е доказателство, че една уязвимост може да бъде експлоатирана, често като прост демонстрационен код. Той служи на производителите и изследователите за оценка, но може да послужи и като шаблон на атакуващите. Публикуван PoC затова по правило повишава спешността на пачването.

**Ransomware (рансъмуер)**: Рансъмуерът криптира данни и иска откуп за декриптирането им, често заедно със заплахата, че откраднатите данни ще бъдат публикувани. Компрометиран уеб сървър може да е входна точка за това. Най-ефективната защита са отделни, тествани резервни копия и план за спешни случаи. Още: [Стратегия за резервни копия на сървър: резервни копия по правилото 3-2-1](https://phpsos.de/bg/ratgeber/backups-3-2-1/)

**RCE**: RCE (Remote Code Execution) означава, че атакуващ може да изпълнява собствен код на чужда система от разстояние. Ако за това не е нужен вход в системата, се говори за unauthenticated RCE – най-тежкия клас уязвимости на уеб сървъри. С RCE атакуващият може да чете данни, да създава задни вратички и да злоупотребява със сървъра по-нататък. Още: [Какво е PHP2Shell? Уязвимостта, обяснена просто](https://phpsos.de/bg/php2shell/was-ist-php2shell/)

**Reverse Proxy**: Reverse proxy приема заявки от интернет и ги предава на един или няколко сървъра зад него. Той може да поеме TLS, да разпределя натоварването и да служи като място за правила за филтриране или за WAF. Защита предлага само ако сървърите зад него не са достъпни и директно. Още: [Филтриране на заявки за качване в периферията: възможности и рискове](https://phpsos.de/bg/blog/upload-anfragen-am-rand-filtern/)

**RFI**: RFI (Remote File Inclusion) е вариантът, при който приложение зарежда и изпълнява код от чужд адрес. В PHP настройката allow_url_include=Off, която отдавна е стандартна, предотвратява включването на отдалечени файлове. Старите приложения и конфигурации трябва да се проверят за това. Още: [Предотвратяване на Local File Inclusion във PHP: LFI и RFI](https://phpsos.de/bg/ratgeber/lfi-rfi/)

**Root сървър**: Root сървърът е нает сървър, на който клиентът има пълни администраторски права. Така и пълната отговорност за актуализациите, заздравяването и наблюдението е на клиента. Доставчикът предоставя само хардуер и мрежа. Още: [Как сами да обезопасите root сървър и vServer](https://phpsos.de/bg/server/root-server-vserver/)

**SAPI**: SAPI (Server Application Programming Interface) е интерфейсът, чрез който PHP общува със средата си, например с Apache, PHP-FPM или командния ред. Използваният SAPI определя как PHP процесите се стартират, използват повторно и рестартират. При PHP2Shell според екипа на PHP са засегнати няколко режима на работа, като най-висок е рискът при mod_php. Още: [SAPI, обяснен: как PHP общува с уеб сървъра](https://phpsos.de/bg/php/sapi-erklaert/)

**SEO спам**: SEO спамът са внедрени страници, връзки или пренасочвания, с които атакуващите позиционират чужди оферти в търсачките. Често само търсачките или посетителите, дошли от Google, виждат манипулираното съдържание. Освен почистването след това е нужна проверка в Google Search Console. Още: [SEO спам и чужди страници в индекса на Google](https://phpsos.de/bg/blog/seo-spam-im-google-index/)

**serialize_handler**: session.serialize_handler определя в какъв формат PHP съхранява данните на сесията, например php, php_binary или php_serialize. Бележката за CVE-2026-115560 засяга само необичайна конфигурация, в която този формат се сменя по време на изпълнение и session upload progress е активен. Мярка до следващото издание с корекции е session.upload_progress.enabled=0. Още: [CVE-2026-115560: бележка за Session Upload Progress](https://phpsos.de/bg/php2shell/cve-2026-115560/)

**session.upload_progress**: Session upload progress е функция на PHP, която записва напредъка на текущите качвания на файлове в сесията; тя е включена по подразбиране. php.net препоръчва като временна мярка session.upload_progress.enabled=0 в php.ini, в FPM пула или в конфигурацията на сървъра, след което всички worker процеси се рестартират. Според специализирани доклади тази настройка сама по себе си не затваря и двете уязвимости PHP2Shell; актуализацията остава задължителна. Още: [Изключване на session.upload_progress: правилно и трайно](https://phpsos.de/bg/blog/session-upload-progress-abschalten/)

**SIEM**: SIEM (Security Information and Event Management) събира централно лог данни от много системи и ги оценява за събития по сигурността. Така могат да се разпознаят връзки, които се губят в отделните логове. SIEM се нуждае от поддържани правила и от хора, които обработват съобщенията. Още: [Наблюдение на сигурността (Security Monitoring) за уеб сървъри](https://phpsos.de/bg/leistungen/security-monitoring/)

**SQL инжекция**: При SQL инжекция атакуващ внедрява чрез въвеждани данни собствени команди към базата данни в приложението. Така данни могат да бъдат прочетени или променени. Защита дават подготвените заявки (prepared statements) с контейнери за стойности вместо слепени SQL текстове. Още: [Предотвратяване на SQL инжекция в PHP](https://phpsos.de/bg/ratgeber/sql-injection-php/)

**SSRF**: SSRF (Server-Side Request Forgery) принуждава приложение да изпраща по поръчка на атакуващия заявки към други адреси, включително към вътрешни системи. Така стават достъпни услуги, които отвън би трябвало да са защитени. Защита дават списъци с разрешени цели и блокиране на вътрешните адресни диапазони. Още: [Предотвратяване на Server-Side Request Forgery (SSRF) в PHP](https://phpsos.de/bg/blog/ssrf-in-php/)

**Superglobals (суперглобални променливи)**: Суперглобалните променливи са променливи, които PHP предоставя във всеки скрипт, например $_GET, $_POST, $_COOKIE, $_FILES, $_SERVER и $_SESSION. Те съдържат данните от текущата заявка, които в голямата си част идват от посетителя. Всичко в тях трябва да се третира като недоверено и да се проверява. Още: [Суперглобални променливи: $_GET, $_POST, $_FILES и др.](https://phpsos.de/bg/php/superglobals/)

**sury.org**: sury.org е хранилище на пакети на Ondřej Surý с актуални и по-стари версии на PHP за Debian и Ubuntu. То е предложение на трета страна, а не архивът за сигурност на Debian. Според доклади там са предоставени билдове за всички клонове от 5.6 до 8.5. Още: [Хранилището sury.org: PHP пакети от външен източник](https://phpsos.de/bg/blog/sury-repository-php/)

**Threat Hunting (лов на заплахи)**: Threat hunting е активното търсене на атакуващи в собствената мрежа, без да има предупреждение. Изходна точка са хипотези, например: стартирал ли е процес на уеб сървъра шел от 20.10. насам? Така се откриват пробиви, които автоматичните инструменти пропускат. Още: [Предупредителен сигнал: уеб сървърът стартира shell](https://phpsos.de/bg/blog/webserver-startet-shell/)

**TISAX**: TISAX е процедура за проверка и обмен в областта на информационната сигурност в автомобилната индустрия. Тя се основава на каталог с изисквания на Германския съюз на автомобилната индустрия и се управлява от ENX Association. Доставчиците трябва с нея да доказват нивото на сигурност пред производителите. Още: [ISO 27001 и TISAX: какво засяга уеб сървърите](https://phpsos.de/bg/blog/iso-27001-tisax-webserver/)

**TLS**: TLS (Transport Layer Security) криптира връзката между браузъра и сървъра; разпознава се по HTTPS. Понастоящем се препоръчват TLS 1.2 и 1.3, а по-старите версии на протокола трябва да са изключени. TLS защитава данните по пътя, но не и от уязвимости на самия сървър. Още: [Правилна конфигурация на TLS и HTTPS](https://phpsos.de/bg/blog/tls-https-richtig-konfigurieren/)

**Type Juggling**: Type Juggling се нарича автоматичното преобразуване на типове в PHP, например при свободно сравнение с ==. Така стойности могат да се считат за равни, макар да не са, което става опасно при проверка на пароли или токени. Защита дават строгите сравнения с === и hash_equals() за тайни стойности. Още: [Type Juggling в PHP: хлабавите сравнения като риск за сигурността](https://phpsos.de/bg/blog/type-juggling-php/)

**upload_max_filesize**: upload_max_filesize ограничава размера на един качен файл; по подразбиране са 2 MB. Стойността трябва да е по-малка от post_max_size, защото файлът е част от POST заявката. Твърде щедри стойности увеличават повърхността за атака без полза. Още: [Разумно ограничаване на post_max_size и upload_max_filesize](https://phpsos.de/bg/blog/post-max-size-upload-limits/)

**.user.ini**: .user.ini файловете са настройки на PHP по директории, които PHP-FPM и CGI обработват. С тях собствениците на уебсайтове могат да променят отделни стойности без достъп до сървъра, но само такива, които PHP разрешава за целта. Настройки, свързани със сигурността, като session.upload_progress.enabled=0 срещу PHP2Shell, според php.net не бива да се задават чрез .user.ini. Още: [php.ini, обяснен: структура, нива и приоритет](https://phpsos.de/bg/php/php-ini-erklaert/)

**VdS 10000**: VdS 10000 е насока на VdS Schadenverhütung (германска организация за превенция на щети) за информационна сигурност в малките и средните предприятия. Тя е по-стегната от ISO 27001 и съобразена с възможностите на МСП. По нея е възможна сертификация. Още: [VdS 10000: информационна сигурност за малки и средни предприятия](https://phpsos.de/bg/blog/vds-10000-kmu/)

**vServer**: vServer (виртуален сървър) е виртуална машина на споделен хардуер със собствена операционна система и най-често root достъп. За сигурността важи същото като при root сървъра: актуализациите и заздравяването са работа на клиента. Много vServer-и работят с предварително инсталирани панели като Plesk. Още: [Как сами да обезопасите root сървър и vServer](https://phpsos.de/bg/server/root-server-vserver/)

**WAF**: WAF (Web Application Firewall) проверява HTTP заявките пред приложението и блокира известни модели на атака. Тя може да работи като облачна услуга, като прокси или като модул на уеб сървъра. Осигурява време, но не заменя актуализацията и се заобикаля, ако сървърът е достъпен и директно. Още: [WAF и виртуално пачване за PHP](https://phpsos.de/bg/leistungen/waf-virtuelles-patching/)

**XSS**: XSS (Cross-Site Scripting) означава, че чужд JavaScript се изпълнява през един уебсайт в браузъра на други посетители. Така могат да се превземат сесии или да се прочетат въведени във форми данни. Защита дават последователното кодиране на всички изходни данни и Content Security Policy. Още: [Предотвратяване на XSS в PHP: надеждна защита от Cross-Site Scripting](https://phpsos.de/bg/ratgeber/xss-php/)

**XXE**: XXE (XML External Entities) се възползва от това, че XML парсерите могат да зареждат външни препратки в документи. Така при някои обстоятелства могат да се четат файлове от сървъра или да се предизвикват вътрешни заявки. Защита дава изключването на зареждането на външни обекти при обработка на недоверени XML данни. Още: [Предотвратяване на XML External Entities (XXE) в PHP](https://phpsos.de/bg/blog/xxe-in-php/)

**ZAC**: Zentrale Ansprechstellen Cybercrime (ZAC, централни контактни звена за киберпрестъпност) на германската полиция са специализирани звена за фирми и органи, станали жертва на кибератака. Има ги във всички германски провинции и в BKA. Те приемат сигнали и съветват за по-нататъшните действия. Още: [Подаване на сигнал: Zentrale Ansprechstellen Cybercrime](https://phpsos.de/bg/compliance/anzeige-polizei-zac/)

**Zend Engine**: Zend Engine е ядрото на интерпретатора на PHP. Тя превежда PHP кода във вътрешни команди (опкодове), изпълнява ги и управлява паметта. Грешки в Zend Engine засягат всяко PHP приложение и могат да се отстранят само чрез актуализация на PHP. Още: [Zend Engine: сърцето на PHP](https://phpsos.de/bg/php/zend-engine/)

**Zero-Day**: Zero-Day е уязвимост, която се експлоатира или е публично известна, преди производителят да е предоставил пач. Операторите нямат нито един ден преднина. До пача помагат само временни мерки, изолация и наблюдение. Още: [Времевият прозорец между пач и атака](https://phpsos.de/bg/blog/zeitfenster-patch-angriff/)

**Виртуално пачване**: Виртуалното пачване блокира атаки срещу известна уязвимост пред приложението, най-често с WAF, без да променя уязвимия код. То осигурява време, докато стане възможна истинската актуализация. При PHP2Shell например Cloudflare предупреждава, че правила, базирани само на данните от заявката, не са достатъчни; актуализацията остава задължителна. Още: [WAF и виртуално пачване за PHP](https://phpsos.de/bg/leistungen/waf-virtuelles-patching/)

**Времева линия**: Времевата линия (timeline) подрежда хронологично всички следи от един инцидент: записи в логове, промени във файлове, влизания, процеси. Тя показва кога е започнала атаката и какво се е случило в каква последователност. Важна е единна часова зона, най-добре UTC. Още: [Изготвяне на времевата линия на един инцидент](https://phpsos.de/bg/blog/zeitleiste-eines-vorfalls/)

**Десериализация**: Десериализацията превръща съхранени данни обратно в обекти, в PHP например с unserialize(). Ако данните идват от потребители, атакуващите могат да построят обекти така, че при зареждането да се изпълни нежелан код. За потребителски данни JSON е по-безопасният избор. Още: [Несигурна десериализация във PHP: unserialize и сигурност](https://phpsos.de/bg/ratgeber/deserialisierung-php/)

**Договор за обработване на данни (AVV)**: Договорът за обработване на лични данни (AVV, Auftragsverarbeitungsvertrag) по чл. 28 от ОРЗД е необходим, когато изпълнител обработва по поръчка лични данни или може да има достъп до тях. Това често важи и за хостинг доставчици, агенции и ИТ изпълнители с достъп до сървъра. Договорът урежда, наред с другото, указанията, защитните мерки и пътищата за уведомяване. Още: [Обработване на данни по поръчка, когато доставчици имат достъп до сървъри](https://phpsos.de/bg/blog/auftragsverarbeitung-serverzugriff/)

**Ембарго**: Ембаргото е договореният срок, през който подробностите за една уязвимост остават поверителни, докато пачовете са готови. Така производителите и дистрибуциите могат да подготвят актуализации. При PHP2Shell според няколко доклада подробности са станали публични преди изтичането на ембаргото; затова php.net обяви пачовете на 20.10.2026 г. Още: [Защо PHP уязвимостта стана известна преди пача](https://phpsos.de/bg/blog/php-luecke-vorzeitig-bekannt/)

**Жизнен цикъл на версиите**: Всяка версия на PHP първо получава корекции на грешки, а след това известно време само корекции за сигурност. Кога приключва поддръжката на дадена версия, проектът PHP публикува на php.net сред поддържаните версии. PHP 8.2 достига според php.net края на поддръжката на 31.12.2026 г. Още: [PHP версии и цикъл на издаване](https://phpsos.de/bg/php/release-zyklus/)

**Заздравяване (hardening)**: Заздравяването означава да се настрои една система така, че да предлага възможно най-малка повърхност за атака: само необходими услуги, ограничени права, сигурни настройки по подразбиране. При PHP сървърите към това спадат например отделни пулове, блокирани функции и липса на изпълнение на PHP в папките за качване. Заздравяването ограничава щетите, но не заменя актуализациите. Още: [Заздравяване (hardening) на сървъри за PHP](https://phpsos.de/bg/leistungen/server-haertung/)

**Запазване на доказателства**: Запазването на доказателства означава да се съхранят следите от един инцидент, преди да се загубят чрез почистване, рестартиране или преинсталиране. Към това спадат лог файловете, образите на носителите и според случая оперативната памет. Специализираната преса препоръчва след PHP2Shell сървърните логове да се пазят от 20.10.2026 г. Още: [Запазете доказателствата, преди да преинсталирате сървъра](https://phpsos.de/bg/blog/beweise-sichern-vor-neuinstallation/)

**Инжектиране на команди**: При инжектиране на команди (command injection) въвеждани данни попадат непроверени в системна команда, която приложението изпълнява. Така атакуващият може да стартира собствени команди с правата на уеб сървъра. Защита дават отказът от извиквания на шела, където е възможно, и последователното екраниране с escapeshellarg(). Още: [Предотвратяване на Command Injection в PHP](https://phpsos.de/bg/blog/command-injection-php/)

**Киберзастраховка**: Киберзастраховката покрива според договора разходи след атака, например за форензика, възстановяване или прекъсване на дейността. Много договори съдържат задължения като своевременни актуализации и незабавно уведомяване за щетата. Какво важи в конкретния случай, изяснете със своя застраховател. Още: [Киберзастраховка: какво е важно при щета](https://phpsos.de/bg/compliance/cyberversicherung/)

**Контейнер**: Контейнерът е изолирана среда за изпълнение, която стартира приложение с всички зависимости от образ (image), например с Docker. PHP в контейнера идва от образа, а не от хост системата. Затова актуализация на хоста не го пачва; образът трябва да се изгради наново, а контейнерът да се рестартира. Още: [Експлоатация на PHP в контейнери](https://phpsos.de/bg/php/php-in-containern/)

**Криптоминър**: Криптоминърът е зловреден софтуер, който изчислява криптовалута на чужди сървъри. Типични признаци са трайно високо натоварване на процесора и непознати процеси. Миньорът показва, че атакуващ може да изпълнява код; сървърът тогава трябва да се счита за компрометиран. Още: [Криптоминър на уеб сървъра: признаци и действия](https://phpsos.de/bg/blog/kryptominer-auf-dem-server/)

**Мониторинг**: Мониторингът е текущото наблюдение на системите, например на достъпността, натоварването, лог файловете и промените във файловете. Мониторингът за сигурност търси целенасочено нередности като нови PHP файлове или шелове, стартирани от уеб сървъра. Той помага само ако някой оценява съобщенията своевременно. Още: [Наблюдение на сигурността (Security Monitoring) за уеб сървъри](https://phpsos.de/bg/leistungen/security-monitoring/)

**Ниво на предупреждение**: BSI класифицира заплахата при предупрежденията за сигурност по нива, които са означени и с цветове. Ниво 3 (оранжево) означава критична за бизнеса ситуация с възможно масивно затруднение на нормалната дейност. За PHP2Shell важи ниво на предупреждение 3 / оранжево. Още: [BSI ниво на предупреждение оранжево: какво означава оценката](https://phpsos.de/bg/blog/bsi-warnstufe-orange-erklaert/)

**ОРЗД, чл. 33**: Чл. 33 от ОРЗД задължава администраторите да уведомят компетентния надзорен орган за нарушение на сигурността на личните данни по възможност в рамките на 72 часа след узнаването. Задължението отпада само ако няма вероятност да съществува риск за засегнатите лица. В конкретния случай съветват длъжностните лица по защита на данните или адвокатите. Още: [Задължение за уведомяване по ОРЗД: 72 часа след инцидента](https://phpsos.de/bg/compliance/dsgvo-meldepflicht-72-stunden/)

**ОРЗД, чл. 34**: Чл. 34 от ОРЗД урежда уведомяването на самите засегнати лица. То е необходимо, когато нарушение на сигурността на данните вероятно води до висок риск за техните права и свободи. Дали това е така, трябва да се оцени с длъжностните лица по защита на данните или с адвокати. Още: [Задължение за уведомяване по ОРЗД: 72 часа след инцидента](https://phpsos.de/bg/compliance/dsgvo-meldepflicht-72-stunden/)

**Пач (patch)**: Пачът е корекция от производителя, която затваря уязвимост в програмния код. Той действа едва когато е инсталиран и всички работещи процеси са рестартирани. Пачът не премахва вече внедрен зловреден софтуер и не доказва, че преди това нищо не се е случило. Още: [Услуга за пач на PHP: актуализация с рестартиране и доказателство](https://phpsos.de/bg/leistungen/php-patch-service/)

**План за спешни случаи**: ИТ планът за спешни случаи определя кой какво прави при инцидент: контакти, пътища за вземане на решения, първи стъпки, възобновяване на работата. Той трябва да е достъпен и офлайн, в случай че системите отпаднат. Редовните упражнения показват дали работи в реална ситуация. Още: [Как да изготвите ИТ авариен план за уеб сървъри](https://phpsos.de/bg/compliance/notfallplan-erstellen/)

**Проверка на целостта**: При проверка на целостта файловете се сравняват с известно оригинално състояние, най-често чрез контролни суми. Много CMS предлагат за това собствени команди, например за WordPress, Nextcloud или Matomo. Променени файлове, качени файлове и съдържание на базата данни такова сравнение не обхваща. Още: [Сравняване на основните файлове на CMS с оригинала](https://phpsos.de/bg/blog/cms-kerndateien-vergleichen/)

**Резервно копие 3-2-1**: Правилото 3-2-1 препоръчва три копия на данните на два различни носителя, от които едно на друго място. Поне едно копие трябва да не може да бъде променяно от сървъра, за да не могат атакуващите да го изтрият или криптират. Резервното копие се брои едва когато възстановяването е тествано. Още: [Стратегия за резервни копия на сървър: резервни копия по правилото 3-2-1](https://phpsos.de/bg/ratgeber/backups-3-2-1/)

**Сесия**: Сесията свързва няколко заявки на един и същ посетител, например за вход или за количка. PHP съхранява данните от страна на сървъра и дава на браузъра идентификатор на сесия, по подразбиране в бисквитката PHPSESSID. Който познава чужд идентификатор на сесия, при някои обстоятелства може да се представи за този потребител. Още: [Сесии и бисквитки (cookies) в PHP](https://phpsos.de/bg/php/sessions-und-cookies/)

**Скимване**: При скимване в онлайн магазини атакуващите внедряват в страницата за плащане JavaScript, който прочита платежните и клиентските данни и ги изпраща. Кодът често се крие във файлове на темата, в скриптове за проследяване или в записи на базата данни. Клиентите не забелязват нищо, търговецът често научава едва от сигнали на платежни доставчици. Още: [Хакнат онлайн магазин? ИТ сигурност за търговци](https://phpsos.de/bg/branchen/onlineshops/)

**Споделен хостинг**: При споделения хостинг много клиенти споделят един сървър, който се управлява от хостинг доставчика. Доставчикът отговаря за PHP, операционната система и уеб сървъра, клиентът – за своето приложение. При PHP2Shell това означава: попитайте хостинг доставчика за състоянието на пача и проверете собствения си уебсайт за следи. Още: [Споделен хостинг: какво прави доставчикът и какво трябва да направите Вие](https://phpsos.de/bg/server/shared-hosting/)

**Уеб шел (webshell)**: Уеб шелът е скрипт, който атакуващите оставят на уеб сървър, за да го управляват отдалечено през браузъра. Често е малък, замаскиран и скрит в папки за качване или кеш. Уеб шелът остава и след актуализация на PHP или CMS и трябва да се търси целенасочено. Още: [Разпознаване и премахване на уеб шел](https://phpsos.de/bg/ratgeber/webshell-erkennen/)

**Управляван сървър**: При управляван сървър (managed server) доставчикът предоставя собствен сървър и поема по договор определени части от експлоатацията, често актуализациите на операционната система и на PHP. Какво точно влиза в това, е записано в договора и се различава силно между доставчиците. При съмнение отговорността за пачовете трябва да се потвърди писмено. Още: [Управляван сървър: изяснете отговорността](https://phpsos.de/bg/server/managed-server/)

**Форензика**: ИТ форензиката проучва методично след инцидент какво се е случило: как е влязъл атакуващият, какво е направил и кои данни са засегнати. Основа са защитени копия на носители, оперативна памет и логове. Резултатите са важни за задълженията за уведомяване, застраховката и подаването на сигнал до органите. Още: [ИТ форензика след атака срещу уеб сървър](https://phpsos.de/bg/leistungen/it-forensik/)

**Хедъри за сигурност**: Хедърите за сигурност са HTTP заглавни редове в отговора, които дават на браузъра защитни правила, например Content-Security-Policy, Strict-Transport-Security или X-Content-Type-Options. Те защитават посетителите от определени атаки в браузъра. Срещу уязвимости на сървъра като PHP2Shell не помагат. Още: [Хедъри за сигурност на уебсайтове: правилно задаване на Security Headers](https://phpsos.de/bg/ratgeber/sicherheits-header/)