Krótko: Przy uprawnieniach do plików na serwerze WWW obowiązuje jedna zasada: użytkownik, pod którym działa PHP, może czytać własny kod, ale nie może go zmieniać. Uprawnienia do zapisu otrzymują tylko foldery uploadu, cache i tymczasowe, a w nich nie wykonuje się PHP. Uprawnienia takie jak 777 nie mają czego szukać na serwerze produkcyjnym.
Dlaczego uprawnienia do plików decydują po włamaniu
Gdy atakujący przez lukę wykonują kod na serwerze, kod ten działa z uprawnieniami procesu PHP. Co może ten użytkownik, może także atakujący. Właśnie tu rozstrzyga się, czy z włamania powstanie trwała tylna furtka.
Wraz z PHP2Shell ten scenariusz stał się w październiku 2026 bardzo konkretny. Luki CVE-2026-109618 i CVE-2026-109619 umożliwiają wykonanie złośliwego kodu bez logowania. Naprawione są od 21.10.2026 w PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Dobre uprawnienia do plików nie zapobiegają atakowi, ale zapobiegają temu, by wprowadzony kod trwale przepisał Państwa aplikację.
W wielu instalacjach cały kod należy do użytkownika serwera WWW, aby aktualizacje działały jednym kliknięciem. Jest to wygodne, ale to właśnie układ, którego szukają atakujący.
Zasada podstawowa: rozdzielić właściciela i użytkownika uruchomieniowego
Sensowny jest podział na dwie role. Właściciel, na przykład użytkownik wdrożeniowy (deploy), posiada pliki i wprowadza aktualizacje. Proces PHP działa pod innym użytkownikiem i ma uprawnienia do odczytu tylko przez grupę.
| Obszar | Właściciel : grupa | Uprawnienia plików | Uprawnienia folderów |
|---|---|---|---|
| Kod programu | deploy : seite1 | 640 | 750 |
| Konfiguracja z hasłami | deploy : seite1 | 640 | – |
| Uploady, cache, tmp | seite1 : seite1 | 640 | 750 |
| Logi | root lub seite1 | 640 | 750 |
Sam serwer WWW, na przykład Nginx, potrzebuje przy PHP-FPM tylko dostępu do odczytu plików statycznych, takich jak obrazy i CSS. Uzyskują go Państwo przez grupę lub celową regułę dostępu. Kto prowadzi kilka stron, nadaje każdej własnego użytkownika uruchomieniowego; jak to współgra z pulami, opisuje poradnik open_basedir i izolacja każdej strony.
Sprawdzanie uprawnień do plików na serwerze WWW
Zanim cokolwiek Państwo zmienią, proszę zyskać przegląd. Poniższe polecenia niczego nie zmieniają.
# Pod jakim użytkownikiem działają procesy PHP?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c
# Pliki i foldery zapisywalne dla wszystkich
find /var/www -perm -o+w -ls
# Pliki należące do użytkownika serwera WWW (przykład www-data)
find /var/www -user www-data -type f -name "*.php" | head -50
# Uprawnienia plików konfiguracyjnych
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
Wpisy zapisywalne dla wszystkich są prawie zawsze błędem. Pliki PHP należące do użytkownika uruchomieniowego pokazują, że może on zmieniać swój kod. Podejrzane są ponadto pojedyncze pliki, których właściciel lub uprawnienia odbiegają od plików sąsiednich. Może to wskazywać na wprowadzone pliki, jak opisuje poradnik Jak wykryć i usunąć webshell.
Poprawianie uprawnień krok po kroku
Uprawnienia proszę zmieniać dopiero po wykonaniu kopii zapasowej i możliwie najpierw w środowisku testowym. Jeśli istnieje podejrzenie włamania, proszę wcześniej zabezpieczyć ślady, ponieważ właściciel i znaczniki czasu są wtedy materiałem dowodowym.
SITE=/var/www/seite1
# Właściciel: użytkownik wdrożeniowy, grupa: użytkownik uruchomieniowy
sudo chown -R deploy:seite1 "$SITE"
# Foldery 750, pliki 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Tylko do tych folderów PHP może zapisywać (dostosuj ścieżki do aplikacji)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
Następnie proszę kompletnie sprawdzić stronę: stronę główną, logowanie, formularze, upload obrazów, cache. Które foldery aplikacja musi zapisywać, podają wymagania systemowe producenta na jego oficjalnej stronie.
chmod -R 777 użyte, aby szybko rozwiązać problem, otwiera serwer dla każdego użytkownika lokalnego i każdego wprowadzonego procesu. Proszę zamiast tego poprawić właściciela i grupę.
Zapobieganie wykonywaniu PHP w zapisywalnych folderach
Uprawnienia do zapisu są o połowę mniej groźne, jeśli nie może tam działać kod. Proszę zablokować wykonywanie PHP w folderach uploadu i cache na poziomie serwera WWW. Dla Apache w konfiguracji VirtualHost:
<Directory "/var/www/seite1/public/uploads">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Dla Nginx wystarczy blok location, który odrzuca żądania do plików PHP w tych folderach. Reguła należy do konfiguracji serwera, a nie do .htaccess w folderze uploadu, który atakujący z prawami zapisu mógłby ponownie zmienić.
Uzupełniająco warto spojrzeć na umask użytkownika wdrożeniowego, aby nowe pliki nie były zakładane automatycznie zbyt otwarcie. Wartość 027 daje 640 dla plików i 750 dla folderów. Na własnych serwerach odpowiedzialność za to ponoszą Państwo w całości; co jeszcze do tego należy, opisuje Samodzielne zabezpieczanie serwerów root i vServerów.
Przypadki szczególne: panele hostingowe, shared hosting i wdrożenia
Nie każdy serwer da się skonfigurować według podręcznika. Panele hostingowe, takie jak Plesk czy cPanel, zakładają własnych użytkowników i uprawnienia i przy niektórych akcjach je resetują. Uprawnienia proszę tam zmieniać możliwie przez funkcje panelu lub po aktualizacjach panelu sprawdzać, czy Państwa ustawienia nadal obowiązują.
Na shared hostingu mają Państwo zwykle jednego użytkownika do wszystkiego. Rozdzielenie właściciela i użytkownika uruchomieniowego nie jest wtedy możliwe. Tym ważniejsze są skromne uprawnienia do plików konfiguracyjnych, brak uprawnień 777 i wyłączenie wykonywania PHP w folderach uploadu, o ile pozwala na to dostawca hostingu.
Kto pracuje z automatycznymi wdrożeniami, powinien ustawiać uprawnienia w samym skrypcie wdrożeniowym. W przeciwnym razie każda nowa wersja przywraca dawny, zbyt otwarty stan. Krótka kontrola na końcu wdrożenia, na przykład poleceniem dla zapisywalnych plików z góry, niezawodnie wychwytuje takie kroki wstecz i można ją bez dużego wysiłku wbudować w każdy pipeline.
Jak konkretnie pomaga PHP SOS?
- Ustalamy właściciela, uprawnienia i użytkownika uruchomieniowego wszystkich stron na serwerze.
- Opracowujemy koncepcję uprawnień, która pasuje do Państwa aplikacji i sposobu aktualizacji.
- Wdrażamy uprawnienia i blokady wykonywania, a następnie kompletnie testujemy stronę.
- Dokumentujemy koncepcję, aby wdrożenia i aktualizacje nie osłabiały jej ponownie.
Jak wpisuje się to w trwałe zabezpieczenie, opisuje usługa Utwardzanie serwera dla serwerów WWW z PHP.
Częste pytania
Czy uprawnienia 777 są kiedykolwiek w porządku?
Na serwerze produkcyjnym praktycznie nigdy. Przy 777 każdy użytkownik systemu może zakładać i zmieniać pliki. Jeśli aplikacja bez 777 nie działa, zwykle źle ustawiony jest właściciel, a nie uprawnienia są zbyt skąpe.
Dlaczego serwer WWW nie powinien móc zmieniać własnych plików?
Ponieważ wprowadzony kod działa z uprawnieniami serwera WWW. Jeśli serwer WWW może zapisywać pliki PHP, atakujący może manipulować istniejącymi skryptami lub zakładać nowe tylne furtki. Gdy oddzieli się właściciela od użytkownika uruchomieniowego, kod pozostaje chroniony przed zapisem.
Jak aktualizować CMS, skoro serwer WWW nie może zapisywać?
Aktualizacje przebiegają wtedy przez właściciela, na przykład za pomocą WP-CLI, Composera lub wdrożenia, a nie przyciskiem aktualizacji w panelu. Jest to nieco bardziej pracochłonne, ale wprowadzony kod nie może zmieniać plików programu.
Jakich uprawnień wymaga plik konfiguracyjny z hasłem do bazy danych?
Jak najmniejszych: do odczytu dla użytkownika PHP i dla nikogo więcej. Zwykle jest to 640 z odpowiednią grupą lub 400, jeśli użytkownik PHP jest sam właścicielem.