Słownik: PHP i bezpieczeństwo IT

125 pojęć fachowych prostymi słowami, każde z odesłaniem do odpowiedniej strony fachowej.

#A B C D E F G H I J K L M N O P R S T U V W X Z

#

2FA: 2FA (uwierzytelnianie dwuskładnikowe) wymaga przy logowaniu oprócz hasła drugiego dowodu, na przykład kodu z aplikacji lub klucza bezpieczeństwa. Samo skradzione hasło już wtedy nie wystarcza. Dla wszystkich dostępów administracyjnych do CMS, panelu hostingowego i serwerów 2FA powinno być standardem. Jak wdrożyć uwierzytelnianie dwuskładnikowe dla dostępów administratora →

A

Apache: Apache HTTP Server to jeden z najstarszych i najbardziej rozpowszechnionych serwerów WWW. PHP działa w nim albo jako moduł (mod_php), albo przez PHP-FPM za pomocą FastCGI. Za pomocą plików .htaccess można dostosowywać konfigurację dla poszczególnych katalogów. Zabezpieczenie Apache z mod_php →

B

Backdoor: Backdoor (tylna furtka) to ukryty dostęp, przez który atakujący mogą wrócić po włamaniu. Może to być plik, konto administratora, zadanie cron lub klucz SSH. Dlatego do każdego oczyszczania należy wyszukiwanie wszystkich rodzajów dostępów, a nie tylko plików. Backdoor w WordPressie: systematyczne wyszukiwanie tylnych furtek →
Backport: Backport przenosi poprawkę bezpieczeństwa do starszej wersji programu, bez przechodzenia na nową wersję. Dystrybucje Linuksa i firmy hostingowe robią to często; wyświetlany numer wersji pozostaje wtedy taki sam. To, czy backport został wprowadzony, potwierdza changelog pakietu i potwierdzenie dostawcy, a nie numer. Aktualizacja PHP czy backport? Decyzja dla starych systemów →
Brute Force: W ataku brute force atakujący automatycznie próbuje wielu haseł do jednego konta. Celem są często logowania administratorów CMS, SSH lub FTP. Ochronę zapewniają silne hasła, uwierzytelnianie dwuskładnikowe i automatyczne blokady, takie jak Fail2ban. Ochrona logowania administratora przed brute force: ochrona każdego logowania →
BSI: BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) to niemiecki federalny organ ds. cyberbezpieczeństwa. Publikuje ostrzeżenia, zalecenia i standardy, takie jak IT-Grundschutz. W sprawie PHP2Shell BSI ogłosiło poziom ostrzeżenia 3 (pomarańczowy) i zaleciło natychmiastową aktualizację. Co BSI zaleca w sprawie PHP2Shell →

C

CDN: CDN (Content Delivery Network) dostarcza treści przez wiele rozproszonych serwerów i stoi tym samym przed właściwą stroną. Wiele sieci CDN oferuje dodatkowo reguły WAF, na przykład Cloudflare przeciw PHP2Shell. Ochrona działa tylko dla ruchu przechodzącego przez CDN i nie zastępuje aktualizacji PHP. Reguły ochronne Cloudflare przeciw PHP2Shell: co dają, a czego nie →
CERT-Bund: CERT-Bund to Computer Emergency Response Team niemieckiej administracji federalnej przy BSI. Publikuje usługi ostrzegawcze i informacyjne o lukach i powiadamia operatorów sieci o podatnych systemach. CERT-Bund ostrzegał także w sprawie PHP2Shell. Co CERT-EU i CERT-Bund radzą w sprawie PHP2Shell →
CERT-EU: CERT-EU to zespół cyberbezpieczeństwa dla instytucji, organów i agencji Unii Europejskiej. Według raportów CERT-EU uważa za możliwe, że w przypadku PHP2Shell dotknięte są wersje od PHP 5. Zaleca izolowanie aplikacji dostępnych publicznie, jeśli nie da się ich załatać w krótkim czasie. Co CERT-EU i CERT-Bund radzą w sprawie PHP2Shell →
CGI: CGI (Common Gateway Interface) to stary interfejs, w którym serwer WWW uruchamia zewnętrzny program dla każdego żądania i zwraca jego wynik. Jest prosty, ale wolny, i w PHP został w dużej mierze zastąpiony przez FastCGI. Stare konfiguracje CGI nadal spotyka się w niektórych systemach hostingowych i systemach Windows. CGI i FastCGI: podstawy →
cgroups: cgroups (Control Groups) to funkcja jądra Linuksa, za pomocą której można ograniczać pamięć, CPU i inne zasoby dla grup procesów. Korzystają z nich kontenery i systemd, na przykład z MemoryMax. php.net zaleca jako środek tymczasowy przeciw PHP2Shell limit pamięci ustawiony przez kontener lub cgroup zamiast przez RLIMIT_AS lub RLIMIT_DATA. Ustawianie limitów pamięci za pomocą systemd i cgroups →
Chain of Custody: Chain of custody (łańcuch dowodowy) dokumentuje bez luk, kto, kiedy zabezpieczył, przekazał i opracował dany dowód. Uzupełniony sumami kontrolnymi dowodzi, że dane nie zostały zmienione. Bez tej dokumentacji ślady tracą wartość przed sądem lub wobec ubezpieczycieli. Informatyka śledcza po ataku na serwer WWW →
Changelog: Changelog wymienia zmiany w wersji programu lub pakietu, przy poprawkach bezpieczeństwa zwykle z numerem CVE. W Debianie i Ubuntu changelog pakietu pokazuje apt-get changelog, w rodzinie RHEL rpm -q --changelog. W ten sposób można udokumentować backport także przy niezmienionym numerze wersji. Dowód CVE w changelogu pakietu →
CLI: CLI (Command Line Interface) to PHP w wierszu poleceń, na przykład dla zadań cron, poleceń konsolowych CMS i Composera. PHP w CLI może być inną wersją niż PHP obsługujące strony internetowe. Polecenie php -v pokazuje więc tylko wersję z wiersza poleceń; obie ścieżki muszą być załatane. PHP w wierszu poleceń (CLI) →
CloudLinux: CloudLinux to dystrybucja Linuksa dla hostingu współdzielonego, która rozdziela klientów w ograniczonych środowiskach. Za pomocą alt-php udostępnia obok siebie wiele wersji PHP, także starszych. Każda z tych wersji musi być załatana osobno. CloudLinux i alt-php: co powinni wiedzieć klienci hostingu →
Command Injection: Przy command injection dane wejściowe trafiają bez sprawdzenia do polecenia systemowego, które wykonuje aplikacja. Atakujący może w ten sposób uruchamiać własne polecenia z uprawnieniami serwera WWW. Ochronę zapewniają rezygnacja z wywołań powłoki tam, gdzie to możliwe, oraz konsekwentne maskowanie za pomocą escapeshellarg(). Zapobieganie command injection w PHP →
Composer: Composer to menedżer pakietów dla PHP. Instaluje biblioteki zgodnie z danymi w composer.json i zapisuje dokładne wersje w composer.lock. Poleceniem composer audit można sprawdzić zainstalowane pakiety pod kątem znanych luk bezpieczeństwa; luk w samym PHP to polecenie nie znajdzie. Composer: menedżer pakietów dla PHP →
cPanel: cPanel to panel zarządzania hostingiem, z WHM jako interfejsem dla administratora serwera. Wersje PHP są tam zwykle udostępniane przez własne pakiety (EasyApache). To, które buildy są załatane, potwierdzają stan pakietów i firma hostingowa. cPanel i WHM: zabezpieczenie PHP →
Credential Stuffing: W credential stuffing atakujący próbują w innych usługach danych logowania z wcześniejszych wycieków. Działa to dlatego, że wielu ludzi używa haseł wielokrotnie. Ochronę zapewniają unikalne hasła dla każdej usługi i uwierzytelnianie dwuskładnikowe. Jak wdrożyć uwierzytelnianie dwuskładnikowe dla dostępów administratora →
CSP: CSP (Content Security Policy) to nagłówek, który określa, z jakich źródeł strona może ładować skrypty, obrazy i inne treści. Utrudnia XSS i wprowadzanie obcych skryptów, na przykład przy skimmingu. Restrykcyjną CSP trzeba starannie przetestować, aby strona nadal działała. Nagłówki bezpieczeństwa stron WWW: jak je prawidłowo ustawić →
CSRF: CSRF (Cross-Site Request Forgery) skłania przeglądarkę zalogowanego użytkownika do niezamierzonego wykonania akcji na innej stronie. Typowe są zmiany w panelach administracyjnych. Ochronę zapewniają losowe tokeny w formularzach i ciasteczka z atrybutem SameSite. Ochrona przed CSRF w aplikacjach PHP →
CVE: CVE (Common Vulnerabilities and Exposures) to używany na całym świecie rejestr, który każdej znanej luce bezpieczeństwa nadaje jednoznaczny numer, na przykład CVE-2026-109618. Numer sprawia, że komunikaty producentów, organów i dystrybucji są porównywalne. Po numerze CVE można także sprawdzić w changelogu pakietu, czy poprawka została wprowadzona. Dowód CVE w changelogu pakietu →
CVSS: CVSS (Common Vulnerability Scoring System) ocenia wagę luki w skali od 0 do 10. Ocena uwzględnia na przykład to, czy atak jest możliwy przez sieć i bez logowania. Luki PHP2Shell mają po CVSS v4.0 9,2; o konkretnym ryzyku w Państwa środowisku sama ta wartość nic nie mówi.
Cykl wydawniczy: Każda wersja PHP otrzymuje najpierw poprawki błędów, a następnie przez pewien czas już tylko poprawki bezpieczeństwa. Kiedy kończy się wsparcie dla danej wersji, projekt PHP publikuje na php.net w sekcji wspieranych wersji. Według php.net PHP 8.2 osiąga koniec wsparcia 31.12.2026. Wersje PHP i cykl wydawniczy →

D

DDoS: Atak DDoS (Distributed Denial of Service) przeciąża usługę żądaniami z wielu źródeł, aż przestanie być dostępna. Dane zasadniczo nie są przy tym wykradane. DDoS należy odróżniać od exploitu, który celowo wykorzystuje lukę. DDoS czy atak hakerski? Jak prawidłowo ocenić atak →
Defacement: Przy defacement atakujący widocznie zmieniają stronę główną lub treści strony internetowej, na przykład wstawiając komunikaty lub obrazy. Jest to rzucające się w oczy, ale często stanowi tylko widoczny znak głębszego włamania. Do czasu wyjaśnienia stronę należy traktować jako skompromitowaną. Strona zhakowana, co robić? Zdalna pomoc awaryjna →
Deserializacja: Deserializacja zamienia zapisane dane z powrotem w obiekty, w PHP na przykład za pomocą unserialize(). Jeśli dane pochodzą od użytkowników, atakujący mogą skonstruować obiekty tak, że przy ich ładowaniu uruchomi się niepożądany kod. Dla danych użytkowników bezpieczniejszym wyborem jest JSON. Niebezpieczna deserializacja w PHP: unserialize i bezpieczeństwo →
disable_functions: disable_functions to ustawienie php.ini, którym wyłącza się pojedyncze funkcje PHP, zazwyczaj te służące do wykonywania poleceń systemowych. Można je ustawić tylko w php.ini, nie w kodzie aplikacji. Utrudnia życie atakującym, ale nie zastępuje ani aktualizacji, ani prawidłowych uprawnień. Jak prawidłowo stosować PHP disable_functions →
display_errors: display_errors określa, czy PHP wyświetla komunikaty o błędach bezpośrednio w przeglądarce. W produkcji wartość powinna wynosić Off, a błędy zapisuje się zamiast tego do dziennika za pomocą log_errors. Widoczne komunikaty zdradzają bowiem ścieżki, wersje i fragmenty kodu. display_errors off: wyłączanie komunikatów błędów w produkcji →

E

EDR: EDR (Endpoint Detection and Response) to oprogramowanie na serwerach i stanowiskach pracy, które obserwuje procesy, dostępy do plików i połączenia sieciowe oraz zgłasza lub zatrzymuje podejrzane zachowania. Na serwerach WWW może rozpoznać na przykład to, że PHP-FPM uruchamia powłokę. Ponieważ dla PHP2Shell nie ma potwierdzonych IOC, taka analiza zachowania jest szczególnie ważna. Sygnał ostrzegawczy: serwer WWW uruchamia powłokę →
Embargo: Embargo to uzgodniony termin, w którym szczegóły luki pozostają poufne do czasu przygotowania poprawek. Dzięki temu producenci i dystrybucje mogą przygotować aktualizacje. W przypadku PHP2Shell szczegóły stały się według kilku raportów publiczne przed upływem embargo; php.net zapowiedział więc poprawki 20.10.2026. Dlaczego luka w PHP stała się znana przed poprawką →
End of Life: End of Life (EOL) oznacza, że wersja oprogramowania nie otrzymuje już od producenta żadnych aktualizacji, także poprawek bezpieczeństwa. PHP 8.1 i starsze nie otrzymują od projektu PHP oficjalnych aktualizacji; dla 7.4, 8.0 i 8.1 istnieją tylko minimalne backporty źródłowe. Systemy z oprogramowaniem EOL potrzebują planu modernizacji. Koniec wsparcia PHP (End of Life): ryzyko przestarzałych wersji →
Exploit: Exploit to kod lub metoda, która faktycznie wykorzystuje konkretną lukę. Gdy tylko pojawi się poprawka, atakujący mogą ją przeanalizować i wyprowadzić z niej exploity. Dlatego po opublikowaniu poprawki czas do pierwszych ataków często wyraźnie się skraca. Okno czasowe między poprawką a atakiem →
expose_php: expose_php steruje tym, czy PHP ujawnia swoją wersję w nagłówku HTTP X-Powered-By. W środowisku produkcyjnym ustawienie powinno mieć wartość Off, aby atakujący nie widzieli od razu, jaka wersja PHP działa. To ochrona informacji, a nie zamiennik aktualizacji. expose_php i nagłówki Server: ukrywanie informacji o wersji →

F

Fail2ban: Fail2ban czyta pliki logów i po powtarzających się nieudanych próbach tymczasowo blokuje adresy IP w zaporze. Typowe zastosowania to SSH, poczta i logowania administratorów stron. Przeciw rozproszonym atakom z wielu adresów pomaga tylko w ograniczonym stopniu. Konfiguracja Fail2ban dla serwerów WWW →
FastCGI: FastCGI to protokół, którym serwer WWW przekazuje żądania do stale działających procesów programów, na przykład do PHP-FPM. W odróżnieniu od klasycznego CGI nie uruchamia się nowego procesu dla każdego żądania. Ponieważ procesy obsługują kolejno wiele żądań, po aktualizacjach ważny jest prawidłowy restart. CGI i FastCGI: podstawy →
FrankenPHP: FrankenPHP to nowoczesny serwer aplikacji dla PHP oparty na serwerze WWW Caddy. PHP jest tam osadzone bezpośrednio, a w trybie worker aplikacja pozostaje w pamięci między żądaniami. Według zespołu PHP FrankenPHP należy do dotkniętych trybów pracy; po aktualizacji serwer trzeba zrestartować z nowym PHP. Zabezpieczenie FrankenPHP →

G

GHSA: GHSA to identyfikator GitHub Security Advisory, czyli komunikatu bezpieczeństwa w bazie GitHuba. Wiele projektów open source, także PHP, publikuje tam swoje komunikaty dodatkowo obok numeru CVE. Dla PHP2Shell są to GHSA-w8hw-w9fx-j79w i GHSA-6wmf-4rv5-p3rp.

H

Hosting współdzielony: W hostingu współdzielonym (shared hosting) wielu klientów dzieli serwer, który prowadzi firma hostingowa. Firma hostingowa odpowiada za PHP, system operacyjny i serwer WWW, klient za swoją aplikację. W przypadku PHP2Shell oznacza to: zapytać firmę hostingową o stan poprawek i sprawdzić własną stronę pod kątem śladów. Hosting współdzielony: co robi hoster, a co muszą zrobić Państwo →
HSTS: HSTS (HTTP Strict Transport Security) to nagłówek, którym strona informuje przeglądarkę, że przez określony czas ma być wywoływana wyłącznie przez HTTPS. Zapobiega to obniżeniu połączeń do nieszyfrowanego HTTP. Przed włączeniem HTTPS powinno niezawodnie działać na wszystkich objętych domenach. Nagłówki bezpieczeństwa stron WWW: jak je prawidłowo ustawić →
.htaccess: Pliki .htaccess to pliki konfiguracyjne obowiązujące w poszczególnych katalogach, dla Apache i zgodnych serwerów, takich jak LiteSpeed. CMS używają ich do przekierowań i ochrony dostępu, atakujący do ukrytych przekierowań. Nginx nie interpretuje .htaccess; reguły ochronne trzeba tam umieścić w konfiguracji serwera. Bezpieczna konfiguracja Apache dla PHP →

I

Image Digest: Image digest to wartość skrótu (sha256), która jednoznacznie określa zawartość obrazu kontenera. W odróżnieniu od tagu, takiego jak php:8.3-fpm, który można przesunąć na nowe buildy, digest nigdy się nie zmienia. Kto przypina obrazy przez digest, musi go po aktualizacji bezpieczeństwa świadomie zaktualizować. Oficjalne obrazy PHP Docker: tagi, digesty i przebudowa →
Informatyka śledcza: Informatyka śledcza (IT-Forensik) bada metodycznie po incydencie, co się stało: jak atakujący się dostał, co zrobił i jakie dane zostały dotknięte. Podstawą są zabezpieczone kopie nośników danych, pamięci operacyjnej i logów. Wyniki są ważne dla obowiązków zgłoszeniowych, ubezpieczenia i zawiadomienia o przestępstwie. Informatyka śledcza po ataku na serwer WWW →
ini_set(): ini_set() to funkcja PHP, którą skrypt zmienia ustawienia w czasie działania. To, co skrypt może zmienić, zależy od trybu zmiany danego ustawienia. Ponieważ także złośliwy kod może wywołać ini_set(), ustawienia ochronne należą do konfiguracji serwera lub puli, a nie do kodu aplikacji. php.ini wyjaśniony: budowa, poziomy i pierwszeństwo →
IOC: IOC (Indicator of Compromise) to konkretne ślady ataku, na przykład nazwy plików, wartości skrótu, adresy IP lub domeny. Pozwalają celowo sprawdzić systemy pod kątem znanego ataku. Dla PHP2Shell nie ma opublikowanych, potwierdzonych IOC; wykrywanie opiera się na analizie zachowania. Czy już doszło do naruszenia? Oznaki po PHP2Shell →
ISO 27001: ISO/IEC 27001 to międzynarodowa norma dla systemów zarządzania bezpieczeństwem informacji (ISMS). Wymaga uporządkowanego postępowania z ryzykami, środkami i usprawnieniami, w tym zarządzania lukami i incydentami. Firmy mogą się według niej certyfikować. ISO 27001 i TISAX: czego dotyczą serwery WWW →
IT-Grundschutz: IT-Grundschutz BSI to metodyka z modułami i wymaganiami dla bezpieczeństwa informacji w firmach i urzędach. Istnieją osobne moduły, na przykład dla serwerów WWW i aplikacji internetowych. Można go wykorzystać jako podstawę dla ISMS lub certyfikacji. Benchmarki CIS i moduły BSI dla serwerów WWW →

J

JIT: JIT (kompilator Just-in-Time) tłumaczy często wykonywany kod PHP na kod maszynowy w czasie działania programu. Pojawił się w PHP 8.0 i jest częścią OPcache. Dla typowych stron internetowych zysk wydajności jest zwykle niewielki, większy przy zadaniach wymagających dużej mocy obliczeniowej. JIT i wydajność w PHP 8 →

K

Kontener: Kontener to wyizolowane środowisko uruchomieniowe, które uruchamia aplikację ze wszystkimi zależnościami z obrazu, na przykład za pomocą Dockera. PHP w kontenerze pochodzi z obrazu, a nie z systemu gospodarza. Aktualizacja na hoście nie łata go więc; obraz trzeba zbudować od nowa, a kontener zrestartować. Eksploatacja PHP w kontenerach →
Kontrola integralności: Przy kontroli integralności pliki porównuje się ze znanym stanem oryginalnym, zwykle za pomocą sum kontrolnych. Wiele systemów CMS oferuje do tego własne polecenia, na przykład WordPress, Nextcloud czy Matomo. Takie porównanie nie obejmuje zmodyfikowanych plików, przesłanych plików ani zawartości bazy danych. Porównywanie plików rdzenia CMS z oryginałem →
Koparka kryptowalut: Koparka kryptowalut (kryptominer) to złośliwe oprogramowanie, które na cudzych serwerach wylicza kryptowalutę. Typowe oznaki to stale wysokie obciążenie procesora i nieznane procesy. Koparka pokazuje, że atakujący może wykonywać kod; serwer należy wtedy uznać za skompromitowany. Koparka kryptowalut na serwerze WWW: oznaki i działania →
Kopia zapasowa 3-2-1: Reguła 3-2-1 zaleca trzy kopie danych na dwóch różnych nośnikach, z czego jedną w innym miejscu. Co najmniej jedna kopia powinna być niemożliwa do zmiany z serwera, aby atakujący nie mogli jej usunąć ani zaszyfrować. Kopia zapasowa liczy się dopiero wtedy, gdy odtwarzanie zostało przetestowane. Strategia backupu serwera: backupy według reguły 3-2-1 →

L

Least Privilege: Least privilege (zasada minimalnych uprawnień) oznacza, że każdy użytkownik i każdy proces otrzymuje tylko te uprawnienia, których naprawdę potrzebuje. Jeśli PHP działa ze skromnymi uprawnieniami, atakujący po włamaniu może narobić mniej szkód. Dotyczy to użytkowników systemowych, uprawnień do plików, kont bazodanowych i dostępów administracyjnych. Least Privilege: uprawnienia użytkownika serwera WWW →
Lessons Learned: Lessons learned to omówienie incydentu po jego zakończeniu: co się stało, co poszło dobrze, co trzeba zmienić? Celem są konkretne działania z osobami odpowiedzialnymi i terminami, a nie wskazywanie winnych. Wyniki trafiają do planu awaryjnego, procesu poprawek i szkoleń. Lessons learned: stać się lepszym po incydencie →
LFI: LFI (Local File Inclusion) występuje wtedy, gdy aplikacja włącza lokalny plik, którego ścieżkę może kształtować atakujący. W ten sposób można odczytywać pliki konfiguracyjne lub w pewnych okolicznościach wykonać wprowadzony kod. Ochronę zapewniają stałe listy dozwolonych zamiast nazw plików z danych wpisanych przez użytkownika. Zapobieganie Local File Inclusion w PHP: LFI i RFI →
LiteSpeed: LiteSpeed to serwer WWW, który jest w dużej mierze zgodny z konfiguracjami Apache, takimi jak .htaccess, i łączy PHP przez własny interfejs LSAPI. Jest rozpowszechniony u firm hostingowych; OpenLiteSpeed to wersja swobodna. Według zespołu PHP LiteSpeed należy do trybów pracy dotkniętych przez PHP2Shell. LiteSpeed i LSAPI: aktualizacja PHP →

M

memory_limit: memory_limit ogranicza, ile pamięci operacyjnej może zająć pojedynczy skrypt PHP; domyślnie jest to 128 MB. Po osiągnięciu limitu PHP przerywa działanie z błędem braku pamięci. Przeciw CVE-2026-109618 php.net zaleca tymczasowo memory_limit=-1, ustawione na stałe, oraz limit pamięci ustawiony przez kontener lub cgroup. Prawidłowe ustawienie memory_limit →
mod_php: mod_php to moduł PHP dla serwera WWW Apache. PHP działa wtedy bezpośrednio w procesie Apache i zwykle z jego uprawnieniami użytkownika. Zespół PHP ocenia ryzyko związane z PHP2Shell w przypadku mod_php jako najwyższe; pokazano tam exploit, zanim jeszcze zacznie działać kod aplikacji. mod_php wyjaśniony: PHP w procesie Apache →
ModSecurity: ModSecurity to popularna zapora WAF o otwartym kodzie, działająca jako moduł w Apache, Nginx lub innych serwerach WWW. Ocenia żądania na podstawie reguł i może je rejestrować lub blokować. Zwykle stosuje się ją razem z OWASP Core Rule Set. Stosowanie ModSecurity i OWASP Core Rule Set →
Monitoring: Monitoring to bieżący nadzór nad systemami, na przykład dostępnością, obciążeniem, plikami logów i zmianami w plikach. Monitoring bezpieczeństwa szuka celowo nieprawidłowości, takich jak nowe pliki PHP lub powłoki uruchamiane przez serwer WWW. Pomaga tylko wtedy, gdy ktoś ocenia komunikaty w krótkim czasie. Monitoring bezpieczeństwa dla serwerów WWW →

N

Nagłówki bezpieczeństwa: Nagłówki bezpieczeństwa to nagłówki odpowiedzi HTTP, które narzucają przeglądarce reguły ochronne, na przykład Content-Security-Policy, Strict-Transport-Security lub X-Content-Type-Options. Chronią odwiedzających przed pewnymi atakami w przeglądarce. Przed lukami na serwerze, takimi jak PHP2Shell, nie pomagają. Nagłówki bezpieczeństwa stron WWW: jak je prawidłowo ustawić →
Nginx: Nginx to rozpowszechniony serwer WWW i reverse proxy. Nie wykonuje PHP sam, lecz przekazuje żądania przez FastCGI do PHP-FPM. Ważna jest konfiguracja, która przekazuje do PHP tylko prawdziwe pliki PHP i pomija katalogi przesyłanych plików. Zabezpieczenie Nginx z PHP-FPM →
NIS2: NIS2 to dyrektywa UE, która dla wielu firm i podmiotów określa obowiązki w zakresie zarządzania ryzykiem i zgłaszania incydentów bezpieczeństwa. Obejmuje wyraźnie więcej branż i wielkości przedsiębiorstw niż poprzednie uregulowanie. To, czy Państwa firma jest objęta, należy ustalić na podstawie krajowego wdrożenia i przy pomocy prawnej. NIS2 a bezpieczeństwo serwerów WWW →

O

OPcache: OPcache to dołączana do PHP pamięć podręczna bajtkodu. Przechowuje już przetłumaczony kod we wspólnej pamięci, aby pliki PHP nie były kompilowane od nowa przy każdym żądaniu. Po aktualizacji lub oczyszczeniu trzeba opróżnić pamięć podręczną albo zrestartować PHP, w przeciwnym razie może nadal działać stary kod. OPcache wyjaśniony: pamięć podręczna bajtkodu PHP →
open_basedir: open_basedir ogranicza, do jakich katalogów skrypty PHP mogą sięgać funkcjami plikowymi. Na serwerach z wieloma stronami zapobiega to temu, by jedna strona po prostu czytała pliki innej. To nie jest pełna izolacja; należą do niej także oddzielni użytkownicy systemowi i pule FPM. open_basedir i izolacja każdej strony →
Out of Memory: Out of Memory oznacza stan, w którym program nie dostaje więcej pamięci i musi przerwać działanie. W PHP dzieje się tak po przekroczeniu memory_limit. W przypadku CVE-2026-109618 takie przerwanie może zatrzymać PHP w chwili, gdy dane żądania są zainicjowane tylko częściowo. memory_limit i Out-of-Memory: co dzieje się w środku →
OWASP CRS: OWASP Core Rule Set (CRS) to swobodnie dostępny zestaw reguł dla ModSecurity i zgodnych zapór WAF. Rozpoznaje typowe klasy ataków, takie jak SQL injection czy command injection. Reguły trzeba dopasować do aplikacji, w przeciwnym razie blokują także prawidłowe żądania. Stosowanie ModSecurity i OWASP Core Rule Set →
OWASP Top 10: OWASP Top 10 to regularnie aktualizowana lista najważniejszych zagrożeń dla aplikacji internetowych, wydawana przez niekomercyjną organizację OWASP Foundation. Stanowi podstawę dla programowania, kontroli i szkoleń. Uzupełniająco OWASP oferuje Cheat Sheets z konkretnymi środkami zaradczymi.
Oś czasu: Oś czasu (timeline) porządkuje chronologicznie wszystkie ślady incydentu: wpisy w logach, zmiany w plikach, logowania, procesy. Pokazuje, kiedy atak się zaczął i co działo się w jakiej kolejności. Ważna jest jednolita strefa czasowa, najlepiej UTC. Przygotowanie osi czasu incydentu →

P

PECL: PECL (PHP Extension Community Library) to katalog rozszerzeń PHP napisanych w C, które nie należą do standardowego zakresu. Takie rozszerzenia muszą pasować do zainstalowanej wersji PHP. Po zmianie głównej wersji PHP trzeba je często zbudować od nowa lub zastąpić. Rozszerzenia PHP (extensions): jak je rozumieć →
PHP: PHP to język skryptowy, który działa głównie na serwerach WWW i generuje tam strony internetowe. Wiele popularnych systemów CMS i sklepów, takich jak WordPress, TYPO3 czy Shopware, jest napisanych w PHP. Luka w interpreterze PHP dotyczy więc wszystkich działających na nim aplikacji, niezależnie od stanu ich własnych aktualizacji. Czym jest PHP? Język programowania wyjaśniony →
php-cgi: php-cgi to program PHP do pracy przez CGI lub FastCGI. Według zespołu PHP należy do trybów pracy dotkniętych przez PHP2Shell. Tam, gdzie php-cgi jest jeszcze używane, warto sprawdzić, czy możliwe jest przejście na PHP-FPM. php-cgi: stare obciążenie z ryzykiem →
PHP-FPM: PHP-FPM (FastCGI Process Manager) to osobna usługa, która zarządza procesami PHP w pulach i przyjmuje żądania od serwera WWW przez FastCGI. Jest dziś zwykłym trybem pracy z Nginx i na wielu serwerach Apache. Po aktualizacji PHP trzeba zrestartować PHP-FPM, aby nie działały dalej stare procesy. PHP-FPM wyjaśniony: menedżer procesów, pule i workery →
php.ini: Plik php.ini to centralny plik konfiguracyjny PHP. Określa limity oraz ustawienia bezpieczeństwa i błędów, na przykład memory_limit lub display_errors. Często dla każdej SAPI (FPM, CLI, Apache) istnieje osobny plik php.ini, który trzeba utrzymywać oddzielnie. php.ini wyjaśniony: budowa, poziomy i pierwszeństwo →
PHP2Shell: PHP2Shell to nazwa dwóch krytycznych luk w samym PHP, CVE-2026-109618 i CVE-2026-109619, każda z oceną CVSS v4.0 9,2. Umożliwiają zdalne wykonanie złośliwego kodu bez logowania. Zostały usunięte w PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35, opublikowanych 21.10.2026. Czym jest PHP2Shell? Luka wyjaśniona prosto →
php_admin_value: php_admin_value ustawia opcję PHP w puli FPM lub w konfiguracji Apache w taki sposób, że aplikacje nie mogą jej nadpisać przez ini_set() ani .htaccess. Dla przełączników istnieje php_admin_flag. php.net zaleca tę drogę dla środków tymczasowych przeciw PHP2Shell, na przykład dla memory_limit. php_admin_value: blokowanie ustawień przed nadpisaniem →
Plan awaryjny: Awaryjny plan IT określa, kto w razie incydentu co robi: kontakty, ścieżki decyzyjne, pierwsze kroki, wznowienie pracy. Musi być dostępny także offline na wypadek awarii systemów. Regularne ćwiczenia pokazują, czy w razie potrzeby zadziała. Tworzenie planu awaryjnego IT dla serwerów WWW →
Plesk: Plesk to popularny panel zarządzania serwerami WWW, w którym można ustawiać domeny, wersje PHP i handlery dla każdej strony. Ma własne pakiety PHP, ale może też używać pakietów PHP dystrybucji. Przy backportach Plesk może nadal pokazywać starszy numer, jak 8.2.34, mimo że system jest załatany. Serwer Plesk: kontrola wersji PHP i instalacja poprawek →
Poprawka (patch): Poprawka (patch) to korekta producenta, która zamyka lukę w kodzie programu. Działa dopiero po zainstalowaniu i po restarcie wszystkich działających procesów. Poprawka nie usuwa złośliwego oprogramowania, które zostało już wprowadzone, i nie dowodzi, że wcześniej nic się nie wydarzyło. Usługa łatania PHP: aktualizacja z restartem i dowodem →
post_max_size: post_max_size określa, jak duża może być łącznie zawartość żądania POST; domyślnie jest to 8 MB. Jako środek tymczasowy przeciw PHP2Shell php.net podaje 8M dla stron bez przesyłania plików i 32M dla stron z przesyłaniem plików. upload_max_filesize musi być niższe. Rozsądne ograniczanie post_max_size i upload_max_filesize →
Poziom ostrzeżenia: BSI klasyfikuje zagrożenie przy ostrzeżeniach bezpieczeństwa w poziomach, oznaczonych także kolorami. Poziom 3 (pomarańczowy) oznacza sytuację krytyczną dla działalności firm, z możliwym poważnym zakłóceniem normalnej pracy. Dla PHP2Shell obowiązuje poziom ostrzeżenia 3 / pomarańczowy. Poziom pomarańczowy BSI: co oznacza ta klasyfikacja →
Proof of Concept: Proof of Concept (PoC) to dowód, że lukę da się wykorzystać, często w postaci prostego kodu demonstracyjnego. Służy producentom i badaczom do oceny, ale może też stanowić wzór dla atakujących. Opublikowany PoC zwykle zwiększa więc pilność instalacji poprawek.
Pula FPM: Pula to grupa procesów PHP-FPM z własną konfiguracją, własnym gniazdem i najlepiej własnym użytkownikiem systemowym. Oddzielna pula dla każdej strony rozdziela strony od siebie, tak aby włamanie na jedną stronę nie sięgało bezpośrednio plików innych. W puli można na stałe zadać ustawienia przez php_admin_value. Izolowanie pul PHP-FPM dla każdej strony →

R

Ransomware: Ransomware szyfruje dane i żąda okupu za ich odszyfrowanie, często z groźbą opublikowania wykradzionych danych. Skompromitowany serwer WWW może być do tego punktem wejścia. Najskuteczniejszą ochroną są oddzielne, przetestowane kopie zapasowe i plan awaryjny. Strategia backupu serwera: backupy według reguły 3-2-1 →
RCE: RCE (Remote Code Execution) oznacza, że atakujący może zdalnie wykonać własny kod na cudzym systemie. Jeśli nie jest do tego potrzebne logowanie, mówi się o unauthenticated RCE, czyli najcięższej klasie luk serwerów WWW. Dzięki RCE atakujący może odczytywać dane, zakładać tylne furtki i dalej nadużywać serwera. Czym jest PHP2Shell? Luka wyjaśniona prosto →
Reagowanie na incydenty: Reagowanie na incydenty (incident response) to uporządkowana obsługa incydentu bezpieczeństwa: rozpoznanie, powstrzymanie, zabezpieczenie śladów, oczyszczenie, przywrócenie i omówienie. Ustalony przebieg zapobiega temu, by w pośpiechu zniszczyć dowody lub przeoczyć tylne furtki. Ważne są jasne odpowiedzialności i pełna dokumentacja. Incident Response przy atakach na serwery →
Reverse Proxy: Reverse proxy przyjmuje żądania z internetu i przekazuje je do jednego lub kilku serwerów za nim. Może przejąć TLS, rozkładać obciążenie i służyć jako miejsce dla reguł filtrujących lub WAF. Chroni tylko wtedy, gdy serwery za nim nie są dodatkowo dostępne bezpośrednio. Filtrowanie żądań uploadu na brzegu: szanse i ryzyka →
RFI: RFI (Remote File Inclusion) to odmiana, w której aplikacja doładowuje i wykonuje kod z obcego adresu. W PHP ustawienie allow_url_include=Off, od dawna domyślne, zapobiega włączaniu zdalnych plików. Stare aplikacje i konfiguracje należy pod tym kątem sprawdzić. Zapobieganie Local File Inclusion w PHP: LFI i RFI →
RODO art. 33: Art. 33 RODO zobowiązuje administratorów do zgłoszenia naruszenia ochrony danych osobowych właściwemu organowi nadzorczemu, o ile to możliwe w ciągu 72 godzin od stwierdzenia naruszenia. Obowiązek odpada tylko wtedy, gdy prawdopodobnie nie ma ryzyka dla osób, których dane dotyczą. W konkretnym przypadku doradzają inspektorzy ochrony danych lub prawnicy. Obowiązek zgłoszenia z RODO: 72 godziny po incydencie →
RODO art. 34: Art. 34 RODO reguluje zawiadamianie samych osób, których dane dotyczą. Jest konieczne, gdy naruszenie ochrony danych prawdopodobnie powoduje wysokie ryzyko naruszenia ich praw lub wolności. To, czy tak jest, należy ocenić z inspektorami ochrony danych lub prawnikami. Obowiązek zgłoszenia z RODO: 72 godziny po incydencie →
Rozszerzenie: Rozszerzenie (extension) uzupełnia PHP o funkcje, na przykład do obsługi baz danych, obrazów lub szyfrowania. Rozszerzenia działają w tym samym procesie co PHP i mają takie same uprawnienia. Wyłączenie niepotrzebnych rozszerzeń zmniejsza powierzchnię ataku. Rozszerzenia PHP (extensions): jak je rozumieć →

S

SAPI: SAPI (Server Application Programming Interface) to interfejs, przez który PHP komunikuje się ze swoim otoczeniem, na przykład z Apache, PHP-FPM lub wierszem poleceń. To, która SAPI jest używana, decyduje o tym, jak procesy PHP są uruchamiane, ponownie wykorzystywane i restartowane. W przypadku PHP2Shell dotknięte są według zespołu PHP różne tryby pracy, a mod_php niesie najwyższe ryzyko. SAPI wyjaśnione: jak PHP rozmawia z serwerem WWW →
SEO spam: SEO spam to wprowadzone strony, linki lub przekierowania, którymi atakujący umieszczają obce oferty w wyszukiwarkach. Często zmanipulowane treści widzą tylko wyszukiwarki lub odwiedzający z Google. Oprócz oczyszczania konieczna jest potem kontrola w Google Search Console. SEO spam i obce strony w indeksie Google →
serialize_handler: session.serialize_handler określa, w jakim formacie PHP zapisuje dane sesji, na przykład php, php_binary lub php_serialize. Wskazówka dotycząca CVE-2026-115560 dotyczy wyłącznie nietypowej konfiguracji, w której ten format jest przełączany w czasie działania, a Session Upload Progress jest aktywny. Środkiem zaradczym do następnego wydania z poprawkami błędów jest session.upload_progress.enabled=0. CVE-2026-115560: wskazówka o session upload progress →
Serwer origin: Serwer origin to właściwy serwer WWW za siecią CDN lub reverse proxy. Jeśli jest dostępny także bezpośrednio przez swój adres IP, atakujący mogą ominąć ochronę umieszczoną przed nim. Dlatego origin powinien przyjmować tylko połączenia od CDN lub proxy. Reguły ochronne Cloudflare przeciw PHP2Shell: co dają, a czego nie →
Serwer root: Serwer root to wynajmowany serwer, na którym klient ma pełne uprawnienia administratora. Tym samym pełna odpowiedzialność za aktualizacje, utwardzanie i nadzór spoczywa na kliencie. Dostawca zapewnia tylko sprzęt i sieć. Samodzielne zabezpieczenie serwera root i vServera →
Serwer zarządzany: W przypadku serwera zarządzanego (managed server) dostawca udostępnia osobny serwer i przejmuje umownie określone części jego eksploatacji, często aktualizacje systemu operacyjnego i PHP. Co dokładnie do tego należy, wynika z umowy i bardzo różni się między dostawcami. W razie wątpliwości odpowiedzialność za poprawki należy potwierdzić na piśmie. Serwer zarządzany: wyjaśnienie odpowiedzialności →
Sesja: Sesja łączy kilka żądań tego samego odwiedzającego, na przykład przy logowaniu lub w koszyku. PHP zapisuje dane po stronie serwera i przekazuje przeglądarce identyfikator sesji, domyślnie w ciasteczku PHPSESSID. Kto zna cudzy identyfikator sesji, może w pewnych okolicznościach podszyć się pod tego użytkownika. Sesje i cookies w PHP →
session.upload_progress: Session Upload Progress to funkcja PHP, która zapisuje w sesji postęp trwających przesyłań plików; domyślnie jest włączona. php.net zaleca tymczasowo session.upload_progress.enabled=0 w php.ini, puli FPM lub konfiguracji serwera, a następnie restart wszystkich procesów worker. Samo to ustawienie nie zamyka według raportów fachowych obu luk PHP2Shell; obowiązkowa pozostaje aktualizacja. Wyłączanie session.upload_progress: poprawnie i na stałe →
SIEM: SIEM (Security Information and Event Management) zbiera centralnie dane logów z wielu systemów i ocenia je pod kątem zdarzeń bezpieczeństwa. Dzięki temu można rozpoznać powiązania, które giną w pojedynczych logach. SIEM wymaga utrzymywanych reguł i ludzi, którzy obsługują komunikaty. Monitoring bezpieczeństwa dla serwerów WWW →
Skimming: Przy skimmingu w sklepach internetowych atakujący wprowadzają do kasy JavaScript, który podsłuchuje dane płatnicze i dane klientów i je wysyła. Kod często znajduje się w plikach motywu, skryptach śledzących lub wpisach w bazie danych. Klienci niczego nie zauważają, sprzedawca często dopiero dzięki informacjom od dostawców płatności. Sklep internetowy zhakowany? Bezpieczeństwo IT dla sprzedawców →
SQL injection: Przy SQL injection atakujący wprowadza przez dane wejściowe własne polecenia bazodanowe do aplikacji. W ten sposób można odczytywać lub zmieniać dane. Ochronę zapewniają przygotowane zapytania (prepared statements) z symbolami zastępczymi zamiast sklejanych tekstów SQL. Jak zapobiegać SQL injection w PHP →
SSRF: SSRF (Server-Side Request Forgery) skłania aplikację do wysyłania w imieniu atakującego żądań pod inne adresy, także do systemów wewnętrznych. W ten sposób stają się dostępne usługi, które z zewnątrz powinny być odizolowane. Ochronę zapewniają listy dozwolonych celów i blokowanie wewnętrznych zakresów adresów. Zapobieganie Server-Side Request Forgery (SSRF) w PHP →
Superglobals: Superglobals to zmienne, które PHP udostępnia w każdym skrypcie, na przykład $_GET, $_POST, $_COOKIE, $_FILES, $_SERVER i $_SESSION. Zawierają dane bieżącego żądania, które w dużej części pochodzą od odwiedzającego. Wszystko, co się w nich znajduje, trzeba traktować jako niegodne zaufania i sprawdzać. Superglobals: $_GET, $_POST, $_FILES i inne →
sury.org: sury.org to repozytorium pakietów Ondřeja Surýego z aktualnymi i starszymi wersjami PHP dla Debiana i Ubuntu. To oferta podmiotu trzeciego, a nie archiwum bezpieczeństwa Debiana. Według raportów udostępniono tam buildy dla wszystkich gałęzi od 5.6 do 8.5. Repozytorium sury.org: pakiety PHP z zewnętrznego źródła →

T

Threat Hunting: Threat hunting to aktywne poszukiwanie atakujących we własnej sieci, bez wcześniejszego ostrzeżenia. Punktem wyjścia są hipotezy, na przykład: czy proces serwera WWW uruchomił powłokę od 20.10.? W ten sposób wykrywa się włamania, które automatyczne narzędzia przeoczyły. Sygnał ostrzegawczy: serwer WWW uruchamia powłokę →
TISAX: TISAX to procedura kontroli i wymiany informacji dotyczących bezpieczeństwa informacji w przemyśle motoryzacyjnym. Opiera się na katalogu wymagań VDA (niemieckiego Verband der Automobilindustrie, stowarzyszenia przemysłu motoryzacyjnego) i jest prowadzona przez ENX Association. Dostawcy muszą za jej pomocą wykazać wobec producentów swój poziom bezpieczeństwa. ISO 27001 i TISAX: czego dotyczą serwery WWW →
TLS: TLS (Transport Layer Security) szyfruje połączenie między przeglądarką a serwerem; rozpoznać je można po HTTPS. Obecnie zalecane są TLS 1.2 i 1.3, starsze wersje protokołu powinny być wyłączone. TLS chroni dane w drodze, ale nie przed lukami na samym serwerze. Prawidłowa konfiguracja TLS i HTTPS →
Type Juggling: Type juggling to automatyczna konwersja typów w PHP, na przykład przy luźnym porównaniu za pomocą ==. Przez to wartości, które nie są takie same, mogą być uznane za równe, co staje się niebezpieczne przy sprawdzaniu haseł lub tokenów. Ochronę zapewniają ścisłe porównania za pomocą === oraz hash_equals() dla tajnych wartości. Type juggling w PHP: luźne porównania jako ryzyko bezpieczeństwa →

U

Ubezpieczenie cyber: Ubezpieczenie cyber pokrywa, zależnie od umowy, koszty po ataku, na przykład informatyki śledczej, odtworzenia lub przerwy w działalności. Wiele umów zawiera obowiązki ubezpieczonego, takie jak terminowe aktualizacje i natychmiastowe zgłoszenie szkody. Co obowiązuje w danym przypadku, należy ustalić z ubezpieczycielem. Cyberubezpieczenie: co liczy się w razie szkody →
Umowa powierzenia: Umowa powierzenia przetwarzania danych (AVV) na podstawie art. 28 RODO jest potrzebna, gdy usługodawca przetwarza w imieniu zleceniodawcy dane osobowe lub może mieć do nich dostęp. Dotyczy to często także firm hostingowych, agencji i usługodawców IT z dostępem do serwera. Umowa reguluje między innymi polecenia, środki ochrony i ścieżki zgłaszania. Powierzenie przetwarzania danych, gdy dostawcy mają dostęp do serwerów →
upload_max_filesize: upload_max_filesize ogranicza rozmiar pojedynczego przesyłanego pliku; domyślnie jest to 2 MB. Wartość musi być mniejsza niż post_max_size, ponieważ plik jest częścią żądania POST. Zbyt hojne wartości zwiększają powierzchnię ataku bez żadnej korzyści. Rozsądne ograniczanie post_max_size i upload_max_filesize →
.user.ini: Pliki .user.ini to ustawienia PHP obowiązujące w poszczególnych katalogach, które odczytują PHP-FPM i CGI. Dzięki nim operatorzy stron mogą zmieniać pojedyncze wartości bez dostępu do serwera, ale tylko te, które PHP na to zezwala. Zgodnie z php.net ustawienia istotne dla bezpieczeństwa, takie jak session.upload_progress.enabled=0 przeciw PHP2Shell, nie powinny być zadawane przez .user.ini. php.ini wyjaśniony: budowa, poziomy i pierwszeństwo →
Utwardzanie: Utwardzanie (hardening) oznacza takie ustawienie systemu, aby oferował jak najmniejszą powierzchnię ataku: tylko niezbędne usługi, skromne uprawnienia, bezpieczne ustawienia domyślne. W przypadku serwerów PHP należą do tego na przykład oddzielne pule, zablokowane funkcje i brak wykonywania PHP w katalogach przesyłanych plików. Utwardzanie ogranicza szkody, ale nie zastępuje aktualizacji. Utwardzanie serwerów WWW z PHP →

V

VdS 10000: VdS 10000 to wytyczna VdS Schadenverhütung (niemieckiej organizacji zajmującej się zapobieganiem szkodom) dotycząca bezpieczeństwa informacji w małych i średnich przedsiębiorstwach. Jest bardziej odchudzona niż ISO 27001 i dopasowana do możliwości MŚP. Możliwa jest certyfikacja według niej. VdS 10000: bezpieczeństwo informacji dla małych i średnich firm →
vServer: vServer (serwer wirtualny) to wirtualny komputer na współdzielonym sprzęcie, z własnym systemem operacyjnym i zwykle z dostępem root. Dla bezpieczeństwa obowiązuje to samo co przy serwerze root: aktualizacje i utwardzanie należą do klienta. Wiele vServerów działa z preinstalowanymi panelami, takimi jak Plesk. Samodzielne zabezpieczenie serwera root i vServera →

W

WAF: WAF (Web Application Firewall) sprawdza żądania HTTP przed aplikacją i blokuje znane wzorce ataków. Może działać jako usługa w chmurze, jako proxy lub jako moduł serwera WWW. Daje czas, ale nie zastępuje aktualizacji i zostaje ominięty, jeśli serwer jest dostępny także bezpośrednio. WAF i wirtualne łatanie dla PHP →
Webshell: Webshell to skrypt, który atakujący umieszczają na serwerze WWW, aby zdalnie sterować nim przez przeglądarkę. Jest często mały, zaciemniony i ukryty w katalogach przesyłanych plików lub pamięci podręcznej. Webshell pozostaje także po aktualizacji PHP lub CMS i trzeba go szukać celowo. Jak wykryć i usunąć webshell →
Wirtualne łatanie: Wirtualne łatanie blokuje ataki na znaną lukę przed aplikacją, zwykle za pomocą WAF, bez zmiany podatnego kodu. Daje czas do momentu, gdy prawdziwa aktualizacja będzie możliwa. W przypadku PHP2Shell ostrzega na przykład Cloudflare, że same reguły oparte na danych żądania nie wystarczają; aktualizacja pozostaje obowiązkowa. WAF i wirtualne łatanie dla PHP →

X

XSS: XSS (Cross-Site Scripting) oznacza, że obcy JavaScript jest wykonywany przez stronę internetową w przeglądarce innych odwiedzających. W ten sposób można przejąć sesje lub podglądać dane wpisywane w formularzach. Ochronę zapewniają konsekwentne kodowanie wszystkich danych wyjściowych i Content Security Policy. Zapobieganie XSS w PHP: skuteczna obrona przed cross-site scripting →
XXE: XXE (XML External Entities) wykorzystuje to, że parsery XML mogą doładowywać zewnętrzne odwołania w dokumentach. W ten sposób można w pewnych okolicznościach odczytywać pliki z serwera lub wywoływać wewnętrzne żądania. Ochronę zapewnia wyłączenie ładowania zewnętrznych encji podczas przetwarzania niezaufanych danych XML. Zapobieganie XML External Entities (XXE) w PHP →

Z

Zabezpieczenie dowodów: Zabezpieczenie dowodów oznacza zabezpieczenie śladów incydentu, zanim zostaną utracone przez oczyszczanie, restart lub ponowną instalację. Należą do tego pliki logów, obrazy nośników danych, a zależnie od przypadku pamięć operacyjna. Prasa fachowa radzi po PHP2Shell przechowywać logi serwera od 20.10.2026. Zabezpieczyć dowody, zanim zainstalują Państwo serwer od nowa →
ZAC: Zentrale Ansprechstellen Cybercrime (ZAC), czyli centralne punkty kontaktowe ds. cyberprzestępczości niemieckiej policji, to wyspecjalizowane punkty dla firm i urzędów, które padły ofiarą cyberataku. Istnieją we wszystkich niemieckich krajach związkowych oraz w BKA. Przyjmują zawiadomienia i doradzają w sprawie dalszego postępowania. Złożenie zawiadomienia: Zentrale Ansprechstellen Cybercrime →
Zend Engine: Zend Engine to rdzeń interpretera PHP. Tłumaczy kod PHP na wewnętrzne polecenia (opcody), wykonuje je i zarządza pamięcią. Błędy w Zend Engine dotyczą każdej aplikacji PHP i można je usunąć wyłącznie aktualizacją PHP. Zend Engine: serce PHP →
Zero-Day: Zero-day to luka, która jest wykorzystywana lub publicznie znana, zanim producent udostępni poprawkę. Operatorzy mają wtedy zero dni zapasu. Do czasu poprawki pomagają tylko środki tymczasowe, odizolowanie i nadzór. Okno czasowe między poprawką a atakiem →

Kontakt natychmiast

Liczy się każda godzina. Proszę napisać do nas teraz.

Proszę krótko opisać system, wersję PHP i obserwacje. Skontaktujemy się z Państwem, ustalimy sytuację i będziemy pracować zdalnie, aż incydent zostanie zamknięty i udokumentowany.

Awaria na WhatsApp Zadzwoń