Ukratko: Kod prava datoteka na web-poslužitelju vrijedi jedno načelo: korisnik pod kojim radi PHP smije čitati vlastiti kod, ali ga ne smije mijenjati. Pravo pisanja dobivaju samo mape za upload, cache i tmp, a tamo se PHP ne izvršava. Prava poput 777 nemaju što tražiti na produkcijskom poslužitelju.
Zašto prava datoteka nakon provale čine razliku
Kad napadači putem ranjivosti izvršavaju kod na poslužitelju, taj kod radi s pravima PHP procesa. Što taj korisnik smije, smije i napadač. Upravo se tu odlučuje hoće li provala postati trajna stražnja vrata.
S PHP2Shellom je taj scenarij u listopadu 2026. postao vrlo konkretan. Ranjivosti CVE-2026-109618 i CVE-2026-109619 omogućuju izvršavanje zlonamjernog koda bez prijave. Ispravljene su od 21.10.2026. u PHP-u 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Dobra prava datoteka ne sprječavaju napad, ali sprječavaju da ubačeni kod trajno prepiše Vašu aplikaciju.
U mnogim instalacijama cijeli kod pripada korisniku web-poslužitelja kako bi ažuriranja radila jednim klikom. To je zgodno, ali upravo je to konstelacija koju napadači traže.
Osnovno načelo: razdvojiti vlasnika i korisnika izvršavanja
Smislena je podjela na dvije uloge. Vlasnik, primjerice deploy korisnik, posjeduje datoteke i primjenjuje ažuriranja. PHP proces radi pod drugim korisnikom i ovlašten je samo čitati, putem grupe.
| Područje | Vlasnik : grupa | Prava datoteka | Prava mapa |
|---|---|---|---|
| Programski kod | deploy : seite1 | 640 | 750 |
| Konfiguracija s lozinkama | deploy : seite1 | 640 | – |
| Uploadi, cache, tmp | seite1 : seite1 | 640 | 750 |
| Logovi | root ili seite1 | 640 | 750 |
Sam web-poslužitelj, primjerice Nginx, uz PHP-FPM treba samo pristup čitanju statičnim datotekama poput slika i CSS-a. To dobivate putem grupe ili ciljanog pravila pristupa. Tko vodi više web-stranica, svakoj daje vlastitog korisnika izvršavanja; kako to funkcionira s poolovima, opisuje vodič open_basedir i izolacija po web-stranici.
Provjera prava datoteka na web-poslužitelju
Prije nego išta promijenite, steknite pregled. Sljedeće naredbe ništa ne mijenjaju.
# Pod kojim korisnikom rade PHP procesi?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c
# Datoteke i mape u koje svi smiju pisati
find /var/www -perm -o+w -ls
# Datoteke koje pripadaju korisniku web-poslužitelja (primjer www-data)
find /var/www -user www-data -type f -name "*.php" | head -50
# Prava konfiguracijskih datoteka
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
Unosi u koje svi smiju pisati gotovo su uvijek pogreška. PHP datoteke koje pripadaju korisniku izvršavanja pokazuju da taj korisnik može mijenjati vlastiti kod. Upadljive su i pojedinačne datoteke čiji vlasnik ili prava odstupaju od susjednih datoteka. To može upućivati na ubačene datoteke, kako opisuje vodič Prepoznavanje i uklanjanje webshellova.
Ispravljanje prava: korak po korak
Prava mijenjajte samo nakon sigurnosne kopije i po mogućnosti najprije na testnom okruženju. Ako postoji sumnja na provalu, prethodno osigurajte tragove jer su vlasnik i vremenske oznake tada dokazni materijal.
SITE=/var/www/seite1
# Vlasnik: deploy korisnik, grupa: korisnik izvršavanja
sudo chown -R deploy:seite1 "$SITE"
# Mape 750, datoteke 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Samo u ove mape PHP smije pisati (putanje prilagodite aplikaciji)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
Zatim potpuno provjerite web-stranicu: početnu stranicu, prijavu, obrasce, upload slika, cacheve. Koje mape aplikacija mora moći pisati, navedeno je u sistemskim zahtjevima proizvođača na njegovoj službenoj stranici.
chmod -R 777 radi brzog rješavanja problema otvara poslužitelj za svakog lokalnog korisnika i svaki ubačeni proces. Umjesto toga ispravite vlasnika i grupu.
Sprječavanje izvršavanja PHP-a u mapama s pravom pisanja
Prava pisanja upola su opasna ako se tamo ne može izvršavati kod. Zabranite izvršavanje PHP-a u mapama za upload i cache na razini web-poslužitelja. Za Apache u konfiguraciji VirtualHosta:
<Directory "/var/www/seite1/public/uploads">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Za Nginx je dovoljan location blok koji odbija zahtjeve prema PHP datotekama u tim mapama. Pravilo pripada u konfiguraciju poslužitelja, a ne u .htaccess u mapi uploada, koji bi napadač s pravom pisanja mogao ponovno promijeniti.
Dodatno se isplati pogledati umask deploy korisnika kako se nove datoteke ne bi automatski stvarale previše otvorene. Vrijednost 027 daje 640 za datoteke i 750 za mape. Na vlastitim poslužiteljima ta odgovornost u cijelosti leži na Vama; što još tamo spada, opisuje vodič Samostalno osiguravanje root poslužitelja i vServera.
Posebni slučajevi: hosting paneli, shared hosting i deploymenti
Nije svaki poslužitelj moguće postaviti po udžbeniku. Hosting paneli poput Plesk ili cPanel stvaraju vlastite korisnike i prava te ih kod nekih radnji vraćaju. Prava tamo mijenjajte po mogućnosti putem funkcija panela ili nakon ažuriranja panela provjerite vrijede li Vaše postavke još.
Kod shared hostinga najčešće imate samo jednog korisnika za sve. Razdvajanje vlasnika i korisnika izvršavanja tada nije moguće. Tim su važnija stroga prava na konfiguracijskim datotekama, nikakva prava 777 i isključivanje izvršavanja PHP-a u mapama za upload, ako to pružatelj hostinga dopušta.
Tko radi s automatskim deploymentima, prava bi trebao postaviti u samoj skripti deploymenta. Inače svaka nova verzija vraća staro, preotvoreno stanje. Kratka provjera na kraju deploymenta, primjerice gornjom naredbom za datoteke s pravom pisanja za sve, pouzdano hvata takve korake unatrag i može se bez većeg truda ugraditi u svaki pipeline.
Kako PHP SOS konkretno pomaže?
- Bilježimo vlasnike, prava i korisnike izvršavanja svih web-stranica na poslužitelju.
- Određujemo koncept prava koji odgovara Vašoj aplikaciji i načinu ažuriranja.
- Provodimo prava i zabrane izvršavanja te potom potpuno testiramo web-stranicu.
- Koncept dokumentiramo kako ga deploymenti i ažuriranja ne bi ponovno oslabili.
Kako je to ugrađeno u trajnu zaštitu, opisuje usluga Ojačavanje poslužitelja za PHP web-poslužitelje.
Česta pitanja
Jesu li prava 777 ikada u redu?
Na produkcijskom poslužitelju praktički nikada. S 777 svaki korisnik sustava smije stvarati i mijenjati datoteke. Ako aplikacija bez 777 ne radi, najčešće je pogrešno postavljen vlasnik, a ne prava premala.
Zašto web-poslužitelj ne bi smio mijenjati vlastite datoteke?
Zato što ubačeni kod radi s pravima web-poslužitelja. Ako web-poslužitelj smije pisati PHP datoteke, napadač može manipulirati postojećim skriptama ili postaviti nova stražnja vrata. Ako se vlasnik i korisnik izvršavanja razdvoje, kod ostaje zaštićen od pisanja.
Kako ažurirati CMS ako web-poslužitelj ne smije pisati?
Ažuriranja tada idu preko vlasnika, primjerice putem WP-CLI-ja, Composera ili deploymenta, a ne preko gumba za ažuriranje u backendu. To je nešto zahtjevnije, ali ubačeni kod tada ne može mijenjati programske datoteke.
Koja prava treba konfiguracijska datoteka s lozinkom baze podataka?
Što manje moguće: čitljiva za PHP korisnika, ni za koga drugog. Uobičajeno je 640 uz odgovarajuću grupu ili 400 ako je PHP korisnik sam vlasnik.