Lista kontrolna bezpieczeństwa PHP: 8 kroków do wykrycia i usunięcia luk w zabezpieczeniach

php icon.
Kierownik działu Engineering
Zweryfikowany ekspert
Każdy artykuł na stronie Innowise jest tworzony przez autorów posiadających praktyczne doświadczenie. Rozumieją oni dany temat nie tylko z teoretycznego punktu widzenia, ale także dzielą się spostrzeżeniami wynikającymi z rzeczywistych projektów.
7+ lat doświadczenia
Zweryfikowany ekspert
7+ lat doświadczenia
Herman kieruje działami inżynieryjnymi oraz tworzy procesy, struktury zespołów i standardy techniczne niezbędne do ich rozwoju. Jego doświadczenie obejmuje systemy backendowe obsługujące duże obciążenia, zarządzanie wdrażaniem projektów oraz kierowanie zespołami inżynierów.
Wiedza
Systemy o dużym obciążeniu Architektura oprogramowania Bazy danych
Poznajmy się

Najważniejsze wnioski

  • PHP2Shell wymaga pilnej aktualizacji. 21 października 2026 r. PHP naprawiło luki CVE-2026-109618 i CVE-2026-109619. Oba są krytycznymi lukami w zabezpieczeniach środowiska uruchomieniowego (CVSS v4.0: 9,2), które mogą umożliwić zdalne wykonanie kodu bez uwierzytelnienia.
  • Sprawdź wersje z poprawkami. Pierwsze wydania zawierające poprawki to PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12. Dystrybucje Linuksa mogą udostępniać te same poprawki poprzez łatki przeniesione z nowszych wersji.
  • Należy nadać priorytet narażonym środowiskom uruchomieniowym PHP. Największe zgłoszone ryzyko wiąże się z mod_php serwera Apache, ale PHP-FPM i inne konfiguracje obsługujące ruch internetowy również wymagają uwagi. Aktualizacje frameworków i audyt Composer nie naprawią luki PHP2Shell.
  • Nie poprzestawaj na łatanie PHP. Skorzystaj z ośmiopunktowej listy kontrolnej, aby sprawdzić zależności, kod aplikacji, ustawienia serwera i inne słabe punkty bezpieczeństwa.
  • Zweryfikuj poprawkę w środowisku produkcyjnym. Poproś swój zespół o raport pokazujący, które kompilacje PHP faktycznie działają, które obciążenia zostały załatane oraz czy istnieją oznaki wcześniejszego naruszenia bezpieczeństwa.
Podsumuj artykuł za pomocą AI

Według W3Techs, PHP obsługuje około 70% stron internetowych, w przypadku których znany jest język po stronie serwera. Ponieważ PHP jest tak powszechne, luka w zabezpieczeniach interpretera może narazić wiele witryn na ryzyko, nawet jeśli ich własny kod jest bezpieczny.

21 października 2026 r. projekt PHP opublikował awaryjne poprawki dla dwóch krytycznych luk w zabezpieczeniach: CVE-2026-109618 oraz CVE-2026-109619, zwane łącznie PHP2Shell. Oba otrzymały ocenę 9,2 w skali CVSS v4.0 i umożliwiają zdalne wykonanie kodu bez uwierzytelniania. Luki te dotyczą wewnętrznej pamięci PHP oraz obsługi żądań.

Pierwsze poprawki zostały wydane w wersjach PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12. Jeśli Twój system korzysta z jednej z podatnych wersji, natychmiast zaktualizuj PHP i upewnij się, że Twój serwer WWW działa na załatanej wersji. Jednak na tym nie należy poprzestać. Dla zespołów, które tworzą i utrzymują PHP aplikacje, w tym InnowisePHP specjaliści ds. rozwoju, październikowa aktualizacja stanowi również okazję do przeglądu zależności, kodu aplikacji oraz ustawień serwera.

W tym przewodniku przedstawię osiem kroków pozwalających znaleźć i usunąć luki w zabezpieczeniach w Twojej PHP konfiguracji oraz sprawdzić, czy wprowadzone poprawki działają w środowisku produkcyjnym.

Analiza eksperta: czym PHP2Shell różni się od typowego CVE związanego z zależnością

Pakiet Composer zawierający lukę w zabezpieczeniach ma wpływ na kod używany przez Twoją aplikację. PHP2Shell to zupełnie inna sprawa. Obie luki znajdują się w samym interpreterze PHP, a osoba atakująca może je wywołać przed Laravel, Symfony lub innego frameworka. Aktualizacja wtyczek CMS lub zależności Composer nie załata PHP, a audyt Composer nie wykryje tych luk w zabezpieczeniach występujących w czasie wykonywania.

Zespół ds. bezpieczeństwa PHP identyfikuje moduł Apache mod_php jako konfigurację o najwyższym ryzyku w odniesieniu do luki CVE-2026-109618, z wykazanym atakiem, który działa jeszcze przed uruchomieniem kodu aplikacji. PHP-FPM, CGI i inne konfiguracje serwerów WWW również są narażone, choć warunki wykorzystania luki są różne. Badacze zademonstrowali również wykorzystanie luki CVE-2026-109619 w PHP-FPM.

Oto, co idzie nie tak w każdym z tych przypadków:

CVEPrzyczyna źródłowaDlaczego zespoły powinny się tym interesować
CVE-2026-109618Jeśli podczas przetwarzania żądania PHP wyczerpie pamięć, niektóre dane wewnętrzne mogą pozostać w nieprawidłowym stanie. Gdy PHP usuwa nieudane żądanie, może wykorzystać te dane.Jeśli podczas przetwarzania żądania PHP wyczerpie pamięć, niektóre dane wewnętrzne mogą pozostać w nieprawidłowym stanie. Gdy PHP usuwa nieudane żądanie, może wykorzystać te dane.
CVE-2026-109619Proces roboczy PHP może zachować odwołanie do pamięci, która została zwolniona po wcześniejszym żądaniu. Gdy proces ten obsługuje kolejne żądanie, może próbować wykorzystać to stare odwołanie.Problem ten może przenosić się między żądaniami obsługiwanymi przez tego samego pracownika. Sprawdzanie poszczególnych żądań aplikacji niekoniecznie pozwoli go wykryć.

Obie luki mogą prowadzić do zdalnego wykonania kodu bez konieczności uwierzytelniania. Poprawka dotyczy środowiska uruchomieniowego PHP, a nie zależności aplikacji.

Aby uzyskać bardziej szczegółowe wyjaśnienie techniczne, można zapoznać się z komunikatami projektu PHP dotyczącymi CVE-2026-109618 oraz CVE-2026-109619.

Skąd biorą się luki w zabezpieczeniach PHP?

Jak wspomniałem wcześniej, aktualizacja PHP nie naprawi podatnego na ataki pakietu Composer, a czyste skanowanie zależności nie wykryje problemów w Twoim własnym kodzie. Podczas przeglądu aplikacji PHP zwracam uwagę na cztery źródła zagrożeń bezpieczeństwa, z których każde wiąże się z własnymi potencjalnymi konsekwencjami.

KategoriaPrzykładyGłówne ryzyko
Środowisko uruchomieniowe PHPNiezaktualizowane wersje PHP, luki w zabezpieczeniach interpretera, wersje, dla których nie jest zapewniane wsparcieAtakujący wykorzystują luki w samym PHP, niezależnie od tego, jak bezpiecznie napisano aplikację
Zależności od stron trzecichPakiety Composer, wtyczki CMS, frameworkiKod stron trzecich zawierający luki w zabezpieczeniach naraża aplikacje na ataki, nawet jeśli własny kod jest bezpieczny
Kod aplikacjiWstrzyknięcie kodu SQL, XSS, CSRF, niebezpieczna deseryalizacja, nieprawidłowa kontrola dostępuBłędy w kodzie mogą umożliwić atakującym kradzież danych, wykonanie nieautoryzowanych działań lub naruszenie bezpieczeństwa aplikacji
Konfiguracja i infrastrukturaNiepewne PHP ustawienia, ujawnione pliki, nadmierne uprawnieniaBłędne konfiguracje mogą narazić poufne informacje na ujawnienie lub zapewnić atakującym szerszy dostęp niż zamierzono

Należy usunąć luki w zabezpieczeniach PHP zanim doprowadzą one do poważniejszych konsekwencji

Lista kontrolna bezpieczeństwa PHP: 8 niezbędnych sprawdzeń

Następnie przyjrzyjmy się ośmiu kontrolom bezpieczeństwa, które zastosowałbym w przypadku istniejącej aplikacji PHP. Zacząłbym od środowiska uruchomieniowego PHP obsługującego bieżące żądania, a następnie przejrzałbym kod, zależności i konfigurację pod kątem problemów, których sama aktualizacja PHP nie rozwiąże.

Sprawdź swoją wersję PHP oraz poprawki zabezpieczeń

Najpierw określ, z jakich środowisk uruchomieniowych PHP korzystają Twoje aplikacje: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP czy LiteSpeed. Uwzględnij oddzielne pule FPM, kontenery, instalacje CLI, procesy obsługi kolejek oraz zaplanowane zadania.

Nie polegaj wyłącznie na poleceniach php -v lub php –ini. Polecenie php -v pokazuje wersję CLI, natomiast php –ini pokazuje jej konfigurację. Żadne z nich nie potwierdza, że to właśnie PHP obsługuje żądania internetowe.

Porównaj aktywne środowisko uruchomieniowe i jego konfigurację z oficjalnym PHP komunikatem, w tym z wymienionymi wersjami i warunkami narażenia. Moduł Apache mod_php wykazuje największą potwierdzoną podatność na atak typu PHP2Shell, w tym ścieżkę wykorzystania luki przed uruchomieniem kodu aplikacji. Podatność PHP-FPM zależy od konfiguracji i ścieżek wykonywania. Należy również ocenić inne interfejsy SAPI, ponieważ sam interfejs SAPI nie pozwala ustalić, czy wdrożenie jest bezpieczne.

Pierwsze wydania upstream zawierające obie poprawki to:

Gałąź PHPPierwsza wersja stabilna
8.28.2.35
8.38.3.36
8.48.4.27
8.58.5.12

Wersje te są wymienione w komunikatach dotyczących PHP dotyczących CVE-2026-109618 oraz CVE-2026-109619. Przed aktualizacją sprawdź, czy nie są dostępne nowsze wydania poprawek bezpieczeństwa.

Sprawdź poprawki PHP w systemie Linux i w kontenerach

Sprawdź aktywne środowisko uruchomieniowe. Przejrzyj konfigurację serwera WWW, aby zidentyfikować moduł PHP, pulę FPM lub wbudowany interfejs SAPI obsługujący żądania. Potwierdź jego wersję za pomocą narzędzi diagnostycznych o ograniczonym dostępie, a następnie usuń wszelkie tymczasowe punkty końcowe. Nigdy nie udostępniaj publicznie funkcji phpinfo() ani punktu końcowego wersji.

Sprawdź zainstalowane pakiety. W systemie Ubuntu z PHP 8.3 poniższe polecenia tylko do odczytu wyświetlają zainstalowane pakiety i dostępne wersje:

dpkg-query -W 'php8.3*'
apt-cache policy php8.3-fpm

Dostosuj nazwy pakietów do swojej gałęzi PHP i porównaj zainstalowane wersje z komunikatem bezpieczeństwa dostawcy lub dziennikiem zmian pakietu. Dostawcy systemów Linux mogą przenosić poprawki do starszych PHP wersji. Na przykład Ubuntu wymienia następujące poprawione kompilacje:

  • Ubuntu 24.04: 8.3.6-0ubuntu0.24.04.13

  • Ubuntu 22.04: 8.1.2-1ubuntu2.28

Obie zawierają odpowiednie poprawki pomimo niższych numerów wersji. Sprawdź komunikat dotyczący bezpieczeństwa Ubuntu.

Zastosuj poprawki i ponownie wdróż system. Zainstaluj poprawione pakiety. W przypadku kontenerów zapisz skrót uruchomionego obrazu, zaktualizuj podatne na atak PHP obrazy bazowe, przebuduj i ponownie wdróż dotknięte obciążenia, w tym procesy robocze kolejki.

Zweryfikuj wynik. Uruchom ponownie lub wymień dotknięte pracowniki PHP i upewnij się, że uruchomione procesy oraz kontenery korzystają ze zaktualizowanych kompilacji lub zweryfikowanych backportów dostawców. Zapisz wersje pakietów, skróty uruchomionych obrazów, szczegóły ponownego uruchomienia oraz wyniki weryfikacji.

PHP 8.1 i starsze wersje nie są już obsługiwane przez główny projekt, chociaż niektórzy dostawcy nadal zapewniają backporty zabezpieczeń. Sprawdź, czy zainstalowana kompilacja jest objęta wsparciem, a jeśli nie, zaktualizuj ją. Wsparcie bezpieczeństwa dla PHP 8.2 kończy się 31 grudnia 2026 r., więc każda krótkoterminowa poprawka powinna iść w parze z planem aktualizacji. Pełny harmonogram wsparcia można znaleźć w harmonogramie wsparcia PHP.

Zależności i frameworki audytowe

Zacznij od pliku composer.lock. Zawiera on wersje pakietów, od których zależy Twoja aplikacja, w tym te zainstalowane pośrednio poprzez inne pakiety. Uruchom te dwa polecenia:

composer audit --locked
composer outdated

composer audit --locked sprawdza zablokowane wersje pod kątem znanych komunikatów dotyczących bezpieczeństwa i może oznaczyć porzucone pakiety. composer outdated pokazuje, które aktualizacje są dostępne, ale przestarzały pakiet niekoniecznie jest podatny na ataki. Sprawdź również Laravel lub Symfony komunikaty dotyczące bezpieczeństwa, zwłaszcza jeśli wersja Twojego frameworka nie jest już obsługiwana.

Porównaj pakiety wdrożone w środowisku produkcyjnym z wersjami zawartymi w sprawdzonym pliku lock. Wyniki audytu oraz spis zainstalowanych pakietów przechowuj wraz z dokumentacją wydania.

Jeśli znajdziesz podatne na ataki pakiety, zaktualizuj je do kompatybilnych, załatanych wersji i przetestuj funkcje, których to dotyczy. Wymień biblioteki, które nie otrzymują już poprawek bezpieczeństwa. Jeśli problemy z kompatybilnością uniemożliwiają aktualizację frameworka, udokumentuj je wraz z niezbędnymi działaniami migracyjnymi. Nie pomijaj wtyczek CMS ani bibliotek zainstalowanych poza Composerem.

Pomyślny audyt Composer nie potwierdza, że luka PHP2Shell została załatana. Audyt sprawdza pakiety Composer, podczas gdy PHP2Shell wymaga oddzielnej kontroli interpretera PHP i jego poprawek. Aby ocenić samą aplikację, użyj SAST do analizy kodu źródłowego oraz DAST do testowania działającej aplikacji.

Przegląd PHP oraz konfiguracji serwera

Sprawdź PHP ustawienia faktycznie stosowane przez Twój serwer WWW, w tym PHP-FPM nadpisania puli oraz załadowane rozszerzenia. Pamiętaj, że php --ini pokazuje konfigurację CLI, która może różnić się od konfiguracji aplikacji w środowisku produkcyjnym.

W środowisku produkcyjnym zacznij od:

display_errors = Off
log_errors = On

Przechowuj logi poza katalogami dostępnymi publicznie i ogranicz do nich dostęp. Usuń publiczne strony phpinfo() oraz punkty końcowe debugowania, a także sprawdź ustawienie expose_php, niepotrzebne rozszerzenia oraz uprawnienia do systemu plików.

Wyłączenie display_errors ogranicza ujawnianie informacji, ale nie eliminuje luki CVE-2026-109619. Podatna ścieżka kodu może zostać wykonana, zanim PHP przetworzy komunikat o błędzie.

Środki tymczasowe w przypadku opóźnienia w wydaniu poprawki dla PHP

Jeśli wprowadzenie poprawki musi poczekać, postępuj zgodnie z oficjalnym poradnikiem PHP dotyczącym danej konfiguracji.

  • CVE-2026-109619: Wyłącz session.upload_progress.enabled, a w PHP 8.5 ustaw fatal_error_backtraces=0. Zastosuj te ustawienia przed przetwarzaniem żądań poprzez konfigurację serwera lub puli, a następnie uruchom ponownie dotknięte tym problemem procesy robocze. Mogą pozostać inne ścieżki wykorzystania luki.

  • CVE-2026-109618: Wymuś ustawienie memory_limit=-1 na poziomie serwera lub puli i uruchom ponownie dotknięte tym problemem procesy robocze. Eliminuje to przewidywalną ścieżkę awarii limitu pamięci w PHP, ale pozostawia możliwość wystąpienia innych błędów alokacji. Należy sprawdzić limity żądań oraz zabezpieczenia pamięci hosta lub kontenera, aby zmniejszyć ryzyko ataków typu denial-of-service.

PHP opublikowało również osobny komunikat dotyczący luki CVE-2026-115560 23 października. Dotyczy to aplikacji, które przełączają session.serialize_handler z php_binary lub php_serialize na php za pomocą funkcji ini_set() przed wywołaniem funkcji session_start(), przy włączonym monitorowaniu postępu przesyłania plików. W dotkniętych tym problemem konfiguracjach należy wyłączyć wskaźnik postępu przesyłania do czasu wprowadzenia poprawki.

Wybierz plan aktualizacji dla starszych aplikacji PHP, od których zależy funkcjonowanie Twojej firmy

Sprawdź, czy nie występują wstrzyknięcia kodu SQL, ataki XSS oraz niebezpieczne wykonanie kodu

Niewłaściwe przetwarzanie danych wprowadzanych przez użytkownika może narazić poufne dane na ujawnienie lub umożliwić atakującym uruchomienie złośliwego kodu. Zalecam przeprowadzanie przeglądu kodu w celu wykrycia ryzykownych ścieżek wprowadzania danych oraz stosowanie testów SAST w celu zidentyfikowania potencjalnych luk w zabezpieczeniach. Autoryzowane testy DAST sprawdzają działającą aplikację, natomiast testy penetracyjne pomagają określić, które słabe punkty mogliby wykorzystać atakujący. Aplikacje tworzone metodą vibe coding mogą zawierać te same wady i wymagają takich samych kontroli.

Wstrzyknięcie kodu SQL

Wstrzyknięcie kodu SQL ma miejsce, gdy dane wprowadzone przez użytkownika zmieniają strukturę zapytania do bazy danych. Sprawdź, w jaki sposób Twoja aplikacja tworzy zapytania, zwłaszcza w formularzach wyszukiwania i raportach.

Aby oddzielić dane wprowadzane przez użytkownika od polecenia SQL, należy używać przygotowanych instrukcji PDO:

$stmt = $pdo->prepare(
    'SELECT id FROM users WHERE email = :email'
);
$stmt->execute(['email' => $email]);

Zadeklarowane zapytania oddzielają wartości danych od SQL składni, tak jak robi to w przykładzie symbol zastępczy :email. Zastępcze jednak nie mogą reprezentować nazw tabel ani kolumn. Na przykład, jeśli użytkownicy mogą sortować raport, wybierz dozwolone kolumny z listy zdefiniowanej w aplikacji. Po wprowadzeniu zmian przetestuj odpowiednie zapytania.

Skrypty międzywitrynowe

Atak typu cross-site scripting (XSS) ma miejsce, gdy aplikacja wyświetla niezaufane dane, które przeglądarka może wykonać jako kod. Sprawdź szablony PHP, czy dane wprowadzone przez użytkownika są wyświetlane bez odpowiedniej eskapowania, zwłaszcza tam, gdzie automatyczne eskapowanie jest wyłączone.

Na przykład, jeśli aplikacja wyświetla imię użytkownika jako tekst HTML, należy użyć funkcji htmlspecialchars(), aby przekonwertować znaki specjalne tak, by przeglądarka traktowała je jako tekst:

echo htmlspecialchars(
    $name,
    ENT_QUOTES | ENT_SUBSTITUTE,
    'UTF-8'
);

Właściwa ochrona zależy od tego, gdzie dane się pojawiają. JavaScript, adresy URL oraz atrybuty HTML wymagają kontroli i kodowania dostosowanych do kontekstu. Jeśli użytkownicy mogą przesyłać sformatowany HTML, należy użyć narzędzia do oczyszczania HTML, aby usunąć niebezpieczne elementy, zachowując jednocześnie dozwolone formatowanie.

Niebezpieczny kod i wykonywanie poleceń

Some PHP functions can execute system commands or PHP code. Check whether untrusted input reaches exec(), shell_exec(), or eval(). Also review dynamic file inclusion and the use of unserialize() with data from untrusted sources.

Where possible, use a PHP API instead of running a shell command. If you need to start an external program, specify the executable and pass its arguments separately. Here’s an example using Symfony Process:

use Symfony\Component\Process\Process;

// Validate $filePath against approved paths first.
$process = new Process([
    '/usr/bin/file',
    '--',
    $filePath
]);
$process->mustRun();

This example uses the file utility to identify a file’s type. Symfony Process passes $filePath as a separate argument rather than inserting it into a shell command string. You still need to validate the path, restrict the service account’s filesystem access, and allow only the operations your application requires.

Deserialization needs a separate check. Avoid passing untrusted data to unserialize(), even with allowed_classes restrictions. Where suitable, use JSON instead and validate the decoded values.

Omówienie uwierzytelniania, sesji i kontroli dostępu

Zacznij od haseł. Nie powinny one być przechowywane w postaci czytelnej. Sprawdź, czy Twoja aplikacja korzysta z funkcji PHP password_hash() i password_verify() lub ich odpowiedników w frameworku. Poszukaj starszego kodu do haszowania, który może już nie być bezpieczny.

Następnie sprawdź, co się dzieje, gdy ktoś się loguje. Aplikacja powinna generować nowy identyfikator sesji, tak aby identyfikator uzyskany przed zalogowaniem się nie mógł zostać ponownie wykorzystany do uzyskania dostępu do konta. Sprawdź ustawienia session.use_strict_mode oraz plików cookie, takie jak Secure, HttpOnly i SameSite. Przetestuj regenerację identyfikatora sesji za pośrednictwem frameworka, w tym w sytuacji, gdy jednocześnie napływa wiele żądań.

Teraz sprawdź, czy użytkownicy mogą przeglądać dane, które nie należą do nich. Utwórz dwa konta testowe, każde z własną fakturą. Zaloguj się na pierwsze konto i zmień identyfikator faktury w żądaniu na ten należący do drugiego konta. Serwer powinien odmówić dostępu, chyba że użytkownik ten posiada odpowiednie uprawnienia.

Powtórz test dla edycji faktur, pobierania plików i żądań API. Sprawdź, czy zwykli użytkownicy nie mają dostępu do funkcji administracyjnych. Bycie zalogowanym nie daje automatycznie uprawnień do dostępu do wszystkich rekordów. Serwer musi sprawdzać uprawnienia dla każdego żądania dotyczącego chronionego rekordu lub punktu końcowego API.

Sprawdź zabezpieczenie przed atakami CSRF

Atak CSRF polega na nakłonieniu przeglądarki zalogowanego użytkownika do wykonania czynności, na którą nie wyraził zgody, takiej jak zmiana danych konta. Zacznij od sprawdzenia formularzy i żądań modyfikujących dane, zwłaszcza tych uwierzytelnianych za pomocą plików cookie sesji.

Sprawdź zabezpieczenia przed atakami CSRF w swojej aplikacji Laravel lub Symfony i upewnij się, czy żadna z tras nie została wykluczona. Tam, gdzie stosowana jest walidacja tokenów, przetestuj żądania z brakującymi lub nieprawidłowymi tokenami. Sprawdź również, czy sfałszowane żądania z innej strony internetowej nie mogą zmienić danych użytkownika. Sprawdź również ustawienie SameSite w plikach cookie sesji.

W Laravel Blade, @csrf dodaje ukryte pole tokenu do formularza:


    @csrf
    

W Laravel 13 znajduje się ważny szczegół. Jego middleware CSRF najpierw sprawdza nagłówek Sec-Fetch-Site. Żądanie pochodzące z tego samego źródła może zostać dopuszczone bez tokenu, podczas gdy inne żądania domyślnie podlegają weryfikacji tokenu. Laravel domyślnie wyłącza również ochronę przed atakami CSRF podczas testów automatycznych, więc upewnij się, że jest ona włączona podczas testowania tych zabezpieczeń.

W przypadku interfejsów API istotna jest metoda uwierzytelniania. Bezstanowy interfejs API wykorzystujący tokeny typu „bearer” w nagłówkach autoryzacyjnych zazwyczaj narażony jest na inne rodzaje zagrożeń związanych z atakami CSRF. Jeśli jednak aplikacja typu SPA opiera się na plikach cookie sesji, nadal wymaga ochrony przed sfałszowanymi żądaniami.

Bezpieczne przesyłanie plików i dostęp do plików

Przesyłanie plików staje się zagrożeniem dla bezpieczeństwa, gdy osoby atakujące mogą przesyłać pliki wykonywalne lub uzyskać dostęp do danych, do których nie powinny mieć wglądu. Sprawdź, jakie typy i rozmiary plików akceptuje Twoja aplikacja, gdzie są przechowywane przesłane pliki oraz kto może je pobrać. Przetestuj trasy przesyłania i pobierania pod kątem ataków typu 'path traversal', upewnij się, że przesłane pliki nie mogą być uruchamiane jako PHP, oraz sprawdź, czy pliki .env, .git oraz pliki kopii zapasowych nie są publicznie dostępne.

Poniżej znajduje się przykład w języku PHP sprawdzający typ MIME przesłanego pliku i zapisujący go pod losowo wygenerowaną nazwą:

if (($_FILES['file']['error'] ?? null) !== UPLOAD_ERR_OK) {
    throw new RuntimeException('Przesyłanie nie powiodło się');
}

$tmp = $_FILES['file']['tmp_name'];
$allowed = ['image/jpeg' => 'jpg', 'image/png' => 'png'];
$mime = (new finfo(FILEINFO_MIME_TYPE))->file($tmp);

if (!isset($allowed[$mime])) {
    throw new RuntimeException('Nieobsługiwany typ pliku');
}

$name = bin2hex(random_bytes(16)) . '.' . $allowed[$mime];
$target = '/var/app/private-uploads/' . $name;

if (!move_uploaded_file($tmp, $target)) {
    throw new RuntimeException('Nie można zapisać przesłanego pliku');
}

Przykład zakłada przesłanie pojedynczego pliku oraz istnienie prywatnego katalogu z odpowiednimi uprawnieniami. Funkcja move_uploaded_file() w PHP potwierdza, że plik źródłowy został przesłany za pomocą mechanizmu HTTP POST w PHP.

Sama weryfikacja typu MIME nie wystarcza, aby zapewnić bezpieczeństwo przesyłanych plików. Kod produkcyjny wymaga również narzuconych przez serwer limitów rozmiaru plików, uprawnień do przesyłania i pobierania oraz weryfikacji rzeczywistej zawartości plików. W stosownych przypadkach należy ponownie zakodować obrazy i rozważyć skanowanie w poszukiwaniu złośliwego oprogramowania w przypadku plików o podwyższonym ryzyku. W miarę możliwości przechowuj pliki poza katalogiem głównym serwisu, ogranicz dostęp do systemu plików i zapobiegaj uruchamianiu przesłanych plików jako PHP.

Chroń poufne dane i dane uwierzytelniające

Ujawnione hasła do baz danych, klucze API i tokeny dostępu mogą umożliwić atakującym dostęp do Twojej aplikacji lub poufnych danych. Sprawdź kod źródłowy i historię Git pod kątem obecności tych poufnych danych. Narzędzia takie jak Gitleaks mogą pomóc w ich wykryciu. Upewnij się, że pliki .env nie są przechowywane w Git ani dostępne w sieci. Sprawdź również, kto ma dostęp do danych poufnych w pipelinach CI/CD, oraz przejrzyj obrazy kontenerów i logi aplikacji pod kątem informacji wrażliwych.

Przechowuj sekrety w menedżerze sekretów lub innym systemie o ograniczonym dostępie, a nie w kodzie aplikacji. Ogranicz krąg osób, które mogą je przeglądać lub zmieniać, i przyznaj każdej aplikacji tylko te uprawnienia, których potrzebuje.

Jeśli dane uwierzytelniające zostaną ujawnione, należy je unieważnić lub zastąpić oraz zaktualizować usługi, które z nich korzystają. Należy usunąć ujawnione kopie, zbadać, czy ktoś nie wykorzystał ich bez upoważnienia, oraz zapobiec pojawianiu się sekretów w przyszłych logach. Usunięcie sekretu z kodu nie powoduje jego dezaktywacji ani usunięcia ze starych commitów w Git.

Skorzystaj z profesjonalnej oceny bezpieczeństwa PHP

Jak ustalać priorytety, wdrażać i weryfikować poprawki bezpieczeństwa PHP

01
Ustal priorytety luk w zabezpieczeniach

Należy nadać priorytet systemom narażonym na ataki. Należy rozważyć wynik CVSS w połączeniu z PHP SAPI, ekspozycją na Internet, istniejącymi zabezpieczeniami oraz wpływem na działalność firmy. Niezałatane środowiska mod_php połączone z Internetem wymagają pilnej uwagi, podczas gdy inne interfejsy SAPI nadal wymagają oceny.

02
Bezpieczne wdrażanie poprawek

Zarejestruj aplikacje, których dotyczy problem, pule procesów PHP oraz skróty obrazów kontenerów. Przeprowadź testy w środowisku stagingowym i przygotuj plan przywrócenia przed wdrożeniem. Zainstaluj poprawki dla podatnych pakietów lub odbuduj obrazy, a następnie uruchom ponownie lub wymień wszystkie podatne procesy robocze. Reguły WAF i środki zaradcze w konfiguracji mogą ograniczyć narażenie na określone ścieżki ataku. Nie zapewniają one jednak poprawki podatnego środowiska uruchomieniowego.

03
Sprawdź, czy problem został rozwiązany

Sprawdź, która wersja PHP obsługuje bieżące żądania, i zweryfikuj jej stan aktualizacji, w tym ewentualne poprawki dostarczone przez producenta. Upewnij się, że dotknięte tym problemem procesy robocze zostały ponownie uruchomione lub zastąpione, przeprowadź testy regresyjne i powtórz kontrolę bezpieczeństwa, która wcześniej zakończyła się niepowodzeniem. Monitoruj środowisko produkcyjne pod kątem błędów po wdrożeniu.

04
Zbadać ewentualne naruszenie bezpieczeństwa

Zainstalowanie poprawki eliminuje tę lukę. Wszelkie wcześniejsze naruszenia bezpieczeństwa nadal wymagają zbadania. Należy przeanalizować logi serwera, awarie procesów roboczych, nieznane pliki oraz podejrzaną aktywność sieciową. W przypadku mod_php atak PHP2Shell może zostać przeprowadzony, zanim rozpocznie się rejestrowanie zdarzeń przez aplikację, więc nawet czyste logi frameworka nie wykluczają ataku. Należy zgłosić sygnały ostrzegawcze zespołowi reagowania na incydenty i zabezpieczyć dowody.

05
Dbaj o bezpieczeństwo

Należy śledzić nowe luki w zabezpieczeniach języka PHP oraz jego bibliotek, a także wprowadzić kontrole bezpieczeństwa do procesu CI/CD. Regularne oceny należy opierać na narażeniu aplikacji i ryzyku biznesowym, a po wprowadzeniu istotnych zmian lub ujawnieniu krytycznych informacji należy przeprowadzać ponowną ocenę.

arrow-icon.arrow-icon.
01 Ustal priorytety luk w zabezpieczeniach

Należy nadać priorytet systemom narażonym na ataki. Należy rozważyć wynik CVSS w połączeniu z PHP SAPI, ekspozycją na Internet, istniejącymi zabezpieczeniami oraz wpływem na działalność firmy. Niezałatane środowiska mod_php połączone z Internetem wymagają pilnej uwagi, podczas gdy inne interfejsy SAPI nadal wymagają oceny.

arrow-icon.arrow-icon.
02 Bezpieczne wdrażanie poprawek

Zarejestruj aplikacje, których dotyczy problem, pule procesów PHP oraz skróty obrazów kontenerów. Przeprowadź testy w środowisku stagingowym i przygotuj plan przywrócenia przed wdrożeniem. Zainstaluj poprawki dla podatnych pakietów lub odbuduj obrazy, a następnie uruchom ponownie lub wymień wszystkie podatne procesy robocze. Reguły WAF i środki zaradcze w konfiguracji mogą ograniczyć narażenie na określone ścieżki ataku. Nie zapewniają one jednak poprawki podatnego środowiska uruchomieniowego.

arrow-icon.arrow-icon.
03 Sprawdź, czy problem został rozwiązany

Sprawdź, która wersja PHP obsługuje bieżące żądania, i zweryfikuj jej stan aktualizacji, w tym ewentualne poprawki dostarczone przez producenta. Upewnij się, że dotknięte tym problemem procesy robocze zostały ponownie uruchomione lub zastąpione, przeprowadź testy regresyjne i powtórz kontrolę bezpieczeństwa, która wcześniej zakończyła się niepowodzeniem. Monitoruj środowisko produkcyjne pod kątem błędów po wdrożeniu.

arrow-icon.arrow-icon.
04 Zbadać ewentualne naruszenie bezpieczeństwa

Zainstalowanie poprawki eliminuje tę lukę. Wszelkie wcześniejsze naruszenia bezpieczeństwa nadal wymagają zbadania. Należy przeanalizować logi serwera, awarie procesów roboczych, nieznane pliki oraz podejrzaną aktywność sieciową. W przypadku mod_php atak PHP2Shell może zostać przeprowadzony, zanim rozpocznie się rejestrowanie zdarzeń przez aplikację, więc nawet czyste logi frameworka nie wykluczają ataku. Należy zgłosić sygnały ostrzegawcze zespołowi reagowania na incydenty i zabezpieczyć dowody.

arrow-icon.arrow-icon.
05 Dbaj o bezpieczeństwo

Należy śledzić nowe luki w zabezpieczeniach języka PHP oraz jego bibliotek, a także wprowadzić kontrole bezpieczeństwa do procesu CI/CD. Regularne oceny należy opierać na narażeniu aplikacji i ryzyku biznesowym, a po wprowadzeniu istotnych zmian lub ujawnieniu krytycznych informacji należy przeprowadzać ponowną ocenę.

Przykład z praktyki: poprawka produkcyjna, która wydaje się udana, ale w rzeczywistości taka nie jest

Sklep oparty na Symfony działa na PHP 8.3 z serwerem nginx i PHP-FPM. Administrator aktualizuje pakiety systemu operacyjnego i uruchamia polecenie php -v. Polecenie to pokazuje wersję z poprawkami, więc wszystko wygląda w porządku. Jednak polecenie php -v sprawdza jedynie plik wykonywalny PHP z wiersza poleceń.

Żądania klientów nadal przechodzą przez serwer nginx do procesów roboczych PHP-FPM, które zostały uruchomione przed aktualizacją. Zadania w tle również działają w oddzielnym kontenerze z podatną na ataki PHP warstwą bazową. Pakiety na serwerze mogą być zaktualizowane, ale te obciążenia nadal działają na starym kodzie.

PHP build checks for web, workers, and CLI.

Aby zakończyć wdrażanie poprawki, zespół musi zidentyfikować wszystkie aplikacje i pule procesów, których dotyczy problem, ponownie uruchomić procesy FPM oraz ponownie wdrożyć kontener kolejki przy użyciu poprawionego obrazu. Następnie musi sprawdzić, czy uruchomione procesy PHP korzystają ze skompilowanych wersji z poprawkami lub zweryfikowanych backportów dostawców.

Należy przetestować pobieranie i przesyłanie plików w środowisku stagingowym, przeprowadzić testy smoke w środowisku produkcyjnym oraz powtórzyć kontrole bezpieczeństwa, które wcześniej zakończyły się niepowodzeniem. Dokumentacja wdrożenia powinna zawierać informacje o PHP SAPI obsługującym ruch internetowy, zweryfikowane wersje pakietów lub skróty obrazów, dowody ponownego uruchomienia i testów oraz dane właściciela.

Pozytywny wynik audytu Composer nie stanowi dowodu, że luka PHP2Shell została naprawiona. Polecenie to sprawdza zależności, a nie interpreter PHP obsługujący żądania internetowe.

Należy sprawdzić identyfikator użytkownika PHP worker, katalogi z prawem zapisu, zamontowane sekrety, uprawnienia do bazy danych oraz dostęp do sieci wychodzącej. Czynniki te decydują o tym, czy osoba atakująca mogłaby modyfikować pliki aplikacji, odczytywać dane uwierzytelniające lub uzyskać dostęp do innych systemów. Zasada minimalnych uprawnień i segmentacja sieci mogą ograniczyć szkody w przypadku naruszenia bezpieczeństwa procesu roboczego, jednak nadal konieczne jest załatanie interpretera.

Polecenie `php -v` wyświetla wersję PHP w wierszu poleceń, ale nie pozwala ustalić, który interpreter obsługuje ruch produkcyjny ani czy długotrwale działające procesy typu worker nadal korzystają z podatnej na atak kompilacji. Dzięki narzędziu PHP2Shell najpierw weryfikujemy aktywne środowisko uruchomieniowe, a następnie sprawdzamy zależności i kod aplikacji. Uznajemy naprawę za zakończoną dopiero po potwierdzeniu, że wersja z poprawką faktycznie obsługuje żądania produkcyjne.
Stanislav Kazanov, Head of GRC and Cybersecurity.
Stanislav Kazanov
Kierownik Działu Zrównoważonego Rozwoju

W jaki sposób Innowise może pomóc w zabezpieczeniu Twoich aplikacji PHP

W Innowise łączymy doświadczenie w zakresie tworzenia oprogramowania w języku PHP z wiedzą specjalistyczną w dziedzinie bezpieczeństwa. Ponad 100 naszych programistów PHP zrealizowało ponad 250 projektów, a ponad 50 inżynierów ds. cyberbezpieczeństwa pomaga identyfikować i eliminować luki w zabezpieczeniach. Nasza działalność jest również poparta certyfikatami ISO/IEC 27001:2022 oraz ISO 9001:2015.

Sprawdzamy Państwa aplikacje PHP pod kątem problemów związanych z bezpieczeństwem, w tym podatnych na ataki zależności i przestarzałych komponentów. Nasi programiści zajmują się niezbędnymi poprawkami i aktualizacjami, a inżynierowie ds. bezpieczeństwa testują zmiany przed ich wdrożeniem. Jeśli nie wiesz, od czego zacząć, nasz zespół konsultantów ds. bezpieczeństwa IT może ocenić ryzyko i pomóc w ustaleniu priorytetów prac.

ISO 27001 icon.
ISO-27017-2015.
ISO-27018 icon.
ISO 9001 icon.

Nasze projekty PHP

Przeprojektowanie i przebudowa strony internetowej MedSpa Network
Firma Innowise przebudowała stronę internetową MedSpa Network w oparciu o platformę WordPress, zapewniając zespołowi tej firmy możliwość samodzielnego wprowadzania codziennych aktualizacji treści.
2 miesiące od rozpoczęcia projektu do uruchomienia
3-5 leadów tygodniowo zamiast 1 leada miesięcznie
Zobacz studium przypadku
Client review logo. Opinia klienta
MedSpa Network website redesign and rebuild.
Bot oparty na sztucznej inteligencji na potrzeby kampanii marketingowej TBC Banku
Firma Innowise stworzyła dwujęzycznego bota na Telegramie, który generuje selfie tworzone przez sztuczną inteligencję z udziałem gwiazdy piłki nożnej, pełniącej rolę ambasadora marki TBC Bank.
3,000 zaangażowani użytkownicy
2 obsługiwane języki
Zobacz studium przypadku
Client review logo. Opinia klienta
AI Telegram bot..
Określenie strategii produktowej dla platformy pożyczkowej Bitlendex opartej na bitcoinie
Firma Innowise przeprowadziła fazę analizy wstępnej dla Bitlendex, pomagając klientowi przekształcić koncepcję produktu na wczesnym etapie rozwoju w sprawdzony model biznesowy oraz jasno zdefiniowany MVP.
1 miesiąc na cały etap rozpoznania
System doradztwa finansowego dla Bonnfinanz
Firma Innowise pomogła Bonnfinanz w stworzeniu internetowego systemu doradztwa i administracji, który umożliwia pracę mobilną oraz bezpośrednią interakcję z klientem.
Platforma do ładowania pojazdów elektrycznych z elastycznym systemem rozliczeń
Firma Innowise przyczyniła się do modernizacji platformy e-mobilności SMART/LAB poprzez ulepszenie jej funkcji związanych z rozliczeniami, płatnościami, zarządzaniem transakcjami oraz raportowaniem.
>50% szybsze rozliczanie i przetwarzanie płatności
Transformacja cloud-native DevOps firmy FinXP
Innowise pomogło firmie FinXP zmodernizować infrastrukturę usług finansowych poprzez migrację starszych interfejsów API i aplikacji opartych na języku PHP do architektury natywnej dla chmury.
11 aplikacji przeniesiono do Azure App Service
100% Infrastruktura jako kod
Techniczne SEO dla platformy e-commerce
W ramach projektu Innowise rozwiązano kluczowe problemy techniczne związane z SEO i wydajnością platformy e-commerce firmy Officine 08.
<500 ms czas odpowiedzi serwera
5 miesięcy na realizację projektu
Zobacz studium przypadku
Client review logo. Opinia klienta
Techniczne SEO dla platformy e-commerce.
Ciągły rozwój platformy oferującej subskrypcję perfum
Innowise pomogło firmie Scentbird rozszerzyć jej platformę subskrypcyjną, aby umożliwić oferowanie nowych doświadczeń zakupowych oraz rozwój na rynkach międzynarodowych.
4 lata nieprzerwanego wsparcia
Zobacz studium przypadku
Client review logo. Opinia klienta
Continuous development of a fragrance subscription platform.
01 / 01
Close popup icon

Podsumowanie

Luka PHP2Shell ujawniła poważne zagrożenie w samym interpreterze PHP. Aktualizacje frameworków i sprawdzanie zależności nie usuną luk na tym poziomie. Firmy muszą zidentyfikować wszystkie środowiska uruchomieniowe PHP obsługujące żądania internetowe, zainstalować aktualizacje zabezpieczeń oraz sprawdzić, czy serwery produkcyjne działają w załatanych wersjach.

Bezpieczeństwo PHP wymaga również regularnych kontroli kodu aplikacji, konfiguracji i mechanizmów kontroli dostępu, szczególnie po ujawnieniu krytycznych luk w zabezpieczeniach lub wprowadzeniu znaczących aktualizacji. Jeśli potrzebujesz pomocy w ocenie narażenia lub weryfikacji poprawek, Innowise oferuje IT oraz oceny cyberbezpieczeństwa firmy Innowise mogą wesprzeć te działania.

FAQ

Twoja aplikacja może być narażona na ryzyko, jeśli na serwerze działa wersja PHP, która nie została załatana pod kątem luk CVE-2026-109618 i CVE-2026-109619. Sprawdź, która wersja PHP jest faktycznie używana i czy Twój dostawca usług hostingowych zastosował poprawki. Najwyższe potwierdzone ryzyko dotyczy modułu Apache mod_php, ale należy również sprawdzić PHP-FPM. Ponieważ luki znajdują się w samym PHP, aktualizacja WordPressa lub innego frameworka ich nie usunie.

Poprawki dotyczące luki PHP2Shell są dostępne w wersjach PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12. Niektórzy dostawcy systemów Linux wprowadzili te poprawki do starszych kompilacji, więc sprawdź komunikaty swojego dostawcy. Upewnij się, że uruchomione procesy PHP korzystają z poprawionej kompilacji. W systemie Windows zainstaluj zaktualizowane 26 października pakiety kończące się na -1, które naprawiają również oddzielną lukę w zabezpieczeniach Brotli.

Jeśli nie możesz od razu zaktualizować PHP, w miarę możliwości ogranicz publiczny dostęp do aplikacji, których dotyczy ta luka. W przypadku witryn, które muszą pozostać online, administrator serwera może zastosować tymczasowe środki opisane w poradniku bezpieczeństwa dotyczącym PHP, takie jak ograniczenie rozmiarów żądań lub wyłączenie śledzenia postępu przesyłania plików w sesji. Przetestuj te zmiany, aby upewnić się, że strona nadal działa. Ograniczają one jedynie ryzyko, więc instalacja poprawionej wersji PHP pozostaje sprawą pilną.

Nie. Aktualizacja PHP usuwa luki w zabezpieczeniach środowiska uruchomieniowego PHP, ale nie naprawi problemów związanych z bezpieczeństwem w kodzie aplikacji, przestarzałych wtyczkach ani konfiguracji serwera. Musisz je sprawdzić i rozwiązać osobno.

Zalecam sprawdzanie aplikacji PHP pod kątem znanych luk w zabezpieczeniach co najmniej raz w miesiącu, a w przypadku systemów wysokiego ryzyka – częściej. Należy na bieżąco śledzić PHP komunikaty dotyczące bezpieczeństwa oraz zależności, a także planować bardziej szczegółowe audyty w oparciu o narażenie aplikacji i ryzyko biznesowe. Dodatkowe testy są ważne po wprowadzeniu poważnych aktualizacji lub ujawnieniu krytycznych luk w zabezpieczeniach.

Sprawdź porady dotyczące bezpieczeństwa PHP oraz biuletyny dostawcy usług hostingowych lub systemu operacyjnego pod kątem znanych luk w zabezpieczeniach. Użyj polecenia `composer audit --locked`, aby sprawdzić zależności, przeprowadź analizę statyczną i przegląd kodu w celu wykrycia problemów na poziomie aplikacji, a także skorzystaj z narzędzia OWASP ZAP, aby przetestować swoją aplikację internetową z odpowiednimi uprawnieniami. Aby zweryfikować poprawki bezpieczeństwa, sprawdź wersję PHP działającą w środowisku produkcyjnym oraz wszelkie poprawki przeniesione wstecz przez dostawcę.

Tak. Aktualizacje mogą powodować problemy z kompatybilnością ze starszym kodem lub rozszerzeniami. Przed aktualizacją aplikacji produkcyjnej przetestuj je w środowisku testowym i przygotuj plan awaryjny na wypadek, gdyby coś przestało działać.

Należy skorelować logi serwera proxy odwrotnego, Apache/nginx, PHP-FPM oraz EDR/hostu. Poszukaj awarii procesów roboczych, podejrzanych plików lub procesów, nieoczekiwanego ruchu wychodzącego oraz oznak ujawnienia danych uwierzytelniających. W logach aplikacji mogą zostać pominięte luki w zabezpieczeniach środowiska uruchomieniowego PHP, które występują przed rozpoczęciem rejestrowania zdarzeń przez framework. Jeśli wykryjesz podejrzaną aktywność, zainicjuj procedurę reagowania na incydent i zabezpiecz dowody kryminalistyczne.

Pokaż więcej Pokaż mniej

Spis treści

Dowiedz się, które obciążenia PHP wymagają aktualizacji zabezpieczeń w pierwszej kolejności

    Skontaktuj się z nami

    Umów się na rozmowę lub wypełnij poniższy formularz, a my odezwiemy się do Ciebie po przetworzeniu Twojego zgłoszenia.

    Wyślij nam wiadomość głosową
    Załącz dokumenty
    Prześlij plik

    Można załączyć 1 plik o rozmiarze do 2 MB. Prawidłowe formaty plików: pdf, jpg, jpeg, png.

    Klikając "Wyślij", wyrażasz zgodę na przetwarzanie Twoich danych osobowych przez Innowise zgodnie z naszą Polityką prywatności w celu przekazania Ci odpowiednich informacji. Podając numer telefonu, zgadzasz się na kontakt za pośrednictwem połączeń głosowych, SMS-ów lub komunikatorów. Mogą obowiązywać opłaty za połączenia, wiadomości i transmisję danych.

    Możesz także wysłać swoje zapytanie
    na contact@innowise.com
    Co dalej?
    1

    Po otrzymaniu i przeanalizowaniu Twojego zapytania skontaktujemy się z Tobą, aby omówić szczegółowe wymagania dotyczące projektu i podpisać umowę o zachowaniu poufności (NDA).

    2

    Po zapoznaniu się z Twoimi potrzebami i oczekiwaniami nasz zespół przygotuje propozycję realizacji projektu, uwzględniającą zakres prac, liczebność zespołu, przewidywany czas realizacji i szacunkowe koszty.

    3

    Zorganizujemy spotkanie w celu omówienia oferty i ustalenia szczegółów.

    4

    Na koniec podpiszemy umowę, błyskawicznie rozpoczynając pracę nad projektem.

    Interesują Cię inne usługi?

    arrow