Práva k súborom na webovom serveri

Stručne: Pri právach k súborom na webovom serveri platí základná zásada: používateľ, pod ktorým beží PHP, smie vlastný kód čítať, ale nie meniť. Práva na zápis dostávajú iba priečinky pre uploady, cache a tmp a v nich sa nevykonáva žiadne PHP. Práva ako 777 nemajú na produkčnom serveri čo robiť.

Prečo práva k súborom po vniknutí rozhodujú

Keď útočníci cez zraniteľnosť vykonajú kód na serveri, beží tento kód s právami procesu PHP. Čo smie tento používateľ, smie aj útočník. Práve tu sa rozhoduje, či sa z vniknutia stane trvalý backdoor.

S PHP2Shell sa tento scenár v októbri 2026 stal veľmi konkrétnym. Zraniteľnosti CVE-2026-109618 a CVE-2026-109619 umožňujú vykonanie škodlivého kódu bez prihlásenia. Opravené sú od 21. 10. 2026 v PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Dobré práva k súborom útoku nezabránia, ale zabránia tomu, aby zavlečený kód trvalo prepísal vašu aplikáciu.

V mnohých inštaláciách patrí celý kód používateľovi webového servera, aby aktualizácie fungovali jedným kliknutím. Je to pohodlné, ale presne táto konštelácia je to, čo útočníci hľadajú.

Základný princíp: oddeliť vlastníka a používateľa behu

Zmysluplné je rozdelenie do dvoch rolí. Vlastník, napríklad používateľ pre nasadenie, vlastní súbory a nasadzuje aktualizácie. Proces PHP beží pod iným používateľom a je oprávnený iba na čítanie, a to cez skupinu.

Samotný webový server, napríklad Nginx, potrebuje pri PHP-FPM iba prístup na čítanie ku statickým súborom ako obrázky a CSS. Ten získate cez skupinu alebo cielené pravidlo prístupu. Kto prevádzkuje viac webov, dá každému vlastného používateľa behu; ako to spolupôsobí s poolmi, je v príručke open_basedir a izolácia každého webu.

Skontrolovať práva k súborom na webovom serveri

Skôr než niečo zmeníte, urobte si prehľad. Nasledujúce príkazy nič nemenia.

# Pod ktorým používateľom bežia procesy PHP?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c

# Súbory a priečinky zapisovateľné pre všetkých
find /var/www -perm -o+w -ls

# Súbory, ktoré patria používateľovi webového servera (príklad www-data)
find /var/www -user www-data -type f -name "*.php" | head -50

# Práva konfiguračných súborov
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null

Položky zapisovateľné pre všetkých sú takmer vždy chyba. Súbory PHP, ktoré patria používateľovi behu, ukazujú, že môže meniť svoj kód. Nápadné sú aj jednotlivé súbory, ktorých vlastník alebo práva sa líšia od susedných súborov. Môže to byť indícia zavlečených súborov, ako je opísané v príručke Rozpoznať webshell a odstrániť ju.

Opraviť práva: krok za krokom

Práva meňte iba po zálohe a podľa možnosti najprv v testovacom prostredí. Ak existuje podozrenie na vniknutie, zabezpečte najprv stopy, pretože vlastník a časové pečiatky sú potom dôkazné prostriedky.

SITE=/var/www/seite1
# Vlastník: používateľ pre nasadenie, skupina: používateľ behu
sudo chown -R deploy:seite1 "$SITE"
# Priečinky 750, súbory 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Zapisovať smie PHP iba do týchto priečinkov (cesty prispôsobiť aplikácii)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"

Potom web úplne skontrolujte: domovská stránka, prihlásenie, formuláre, upload obrázkov, cache. Do ktorých priečinkov musí aplikácia zapisovať, je uvedené v systémových požiadavkách výrobcu na jeho oficiálnej stránke.

Zabrániť vykonávaniu PHP v zapisovateľných priečinkoch

Práva na zápis sú len napoly také nebezpečné, ak tam nemôže bežať kód. Zablokujte vykonávanie PHP v priečinkoch s uploadmi a cache na úrovni webového servera. Pre Apache v konfigurácii VirtualHost:

<Directory "/var/www/seite1/public/uploads">
    <FilesMatch "\.(php|phtml|phar)$">
        Require all denied
    </FilesMatch>
</Directory>

Pre Nginx stačí blok location, ktorý odmietne požiadavky na súbory PHP v týchto priečinkoch. Pravidlo patrí do konfigurácie servera, nie do .htaccess v priečinku s uploadmi, ktorý by útočník s právami na zápis mohol opäť zmeniť.

Navyše sa oplatí pozrieť sa na umask používateľa pre nasadenie, aby sa nové súbory nezakladali automaticky príliš otvorené. Hodnota 027 vedie k 640 pre súbory a 750 pre priečinky. Na vlastných serveroch leží táto zodpovednosť úplne na vás; čo k tomu ešte patrí, popisuje stránka Zabezpečiť root server a vServer vlastnými silami.

Osobitné prípady: hostingové panely, zdieľaný hosting a nasadenia

Nie každý server sa dá nastaviť podľa učebnice. Hostingové panely ako Plesk alebo cPanel zakladajú vlastných používateľov a práva a pri niektorých akciách ich vracajú späť. Práva tam meňte podľa možnosti cez funkcie panela alebo po aktualizáciách panela skontrolujte, či vaše nastavenia ešte platia.

Pri zdieľanom hostingu máte zvyčajne len jedného používateľa na všetko. Oddelenie vlastníka a používateľa behu potom nie je možné. Tým dôležitejšie sú úzke práva na konfiguračné súbory, žiadne práva 777 a vypnutie vykonávania PHP v priečinkoch s uploadmi, pokiaľ to poskytovateľ povoľuje.

Kto pracuje s automatickými nasadeniami, mal by práva nastavovať priamo v skripte nasadenia. Inak každá nová verzia obnoví starý, príliš otvorený stav. Krátka kontrola na konci nasadenia, napríklad príkazom pre zapisovateľné súbory zhora, takéto kroky späť spoľahlivo zachytí a dá sa bez veľkej námahy zabudovať do každého pipeline.

Ako konkrétne pomáha PHP SOS?

• Zmapujeme vlastníkov, práva a používateľov behu všetkých webov na serveri.
• Určíme koncepciu práv, ktorá sa hodí k vašej aplikácii a spôsobu aktualizácií.
• Práva a blokovanie vykonávania nastavíme a web potom úplne otestujeme.
• Koncepciu zdokumentujeme, aby ju nasadenia a aktualizácie opäť nerozmäkčili.

Ako je to začlenené do trvalého zabezpečenia, popisuje služba Spevnenie servera pre webové servery PHP.

Časté otázky

Zdroje

• OWASP Cheat Sheet Series
• BSI IT-Grundschutz
• php.net: bezpečnostné hlásenia