Röviden: Egy fájl, amely csak a phpinfo() függvényt hívja, minden látogatónak megmutatja a PHP verzióját, moduljait, útvonalait és beállításait, gyakran a hozzáférési adatokat tartalmazó környezeti változókat is. A phpinfo-biztonság szempontjából ezért ez érvényes: az ilyen fájlokat soha ne hagyja tartósan a webrootban, használat után törölje, és a PHP állapotát inkább a csomagkezelőn és a konfiguráción keresztül ellenőrizze. A PHP2Shell elleni javítottsági állapotot egy phpinfo-kimenet amúgy sem igazolja.
A tesztfájl, amely ott marad
- október 21. óta adminok ezrei ellenőrzik, melyik PHP-verziót szolgálják ki a weboldalaik. A leggyorsabb út ismert: egy
info.phpfájl létrehozása egyetlen sorral, megnyitás a böngészőben, az eredmény leolvasása. Ez működik. A probléma utána kezdődik, amikor a fájlt elfelejtik.
Az ilyen fájlok meglepően sokáig életben maradnak. Költözéseknél vele mennek, mentésekbe kerülnek, és évek múlva olyan könyvtárakban bukkannak fel, amelyeket már senki sem ismer. Az automatizált szkennerek folyamatosan lekérdezik a tipikus fájlneveket. Ami az adminnak segédeszköz volt, az a támadónak a szerver építési útmutatója.
Különösen érintettek az ügynökségek és a sok ügyfélweboldallal rendelkező tárhelyszolgáltatók. Aki egy kapkodó héten tucatnyi weboldalt ellenőriz, gyorsan tucatnyi tesztfájlt hoz létre. Egyetlen elfelejtett mappa is elég ahhoz, hogy a fájl hónapokkal később még lekérhető legyen.
Mit árul el a phpinfo(), és miért számít ez a biztonság szempontjából
A PHP kézikönyve szerint a phpinfo() a PHP aktuális állapotát írja ki. Konstansokkal szabályozható, mely részek jelennek meg; megadás nélkül minden.
| Terület (konstans) | Tartalom a kézikönyv szerint | Miért kényes |
|---|---|---|
INFO_GENERAL |
build, a php.ini helye, webszerver, rendszer | elárulja az operációs rendszert és az útvonalakat |
INFO_CONFIGURATION |
az összes direktíva helyi és mester értékei | megmutatja, hogy a disable_functions vagy az open_basedir érvényesül-e |
INFO_MODULES |
betöltött bővítmények beállításaikkal | a támadók látják, mely funkciók érhetők el |
INFO_ENVIRONMENT |
környezeti változók | itt gyakran adatbázis- vagy API-hozzáférési adatok állnak |
INFO_VARIABLES |
előre definiált változók (Environment, GET, POST, Cookie, Server) | az aktuális kérés fejléceit és sütiit tartalmazza |
A két utolsó sor a legveszélyesebb. A modern alkalmazások szívesen töltik be a hozzáférési adatokat környezeti változókból, például egy .env fájlból vagy a konténer-konfigurációból. Ezek az értékek ekkor nyílt szövegként állnak a kimenetben. Hogyan védheti alapvetően az ilyen titkokat, azt a Hozzáférési adatok és .env fájlok helyes védelme cikk írja le.
Ehhez jön: a kimenet a futó kérés értékeit mutatja, tehát a sütiket és a fejléceket is. Ha egy támadó egy látogatót az oldalra tud irányítani, és ki tudja olvasni a választ, például máshol lévő cross-site scripting résen keresztül, még a HttpOnly jelölésű sütik is láthatóvá válnak.
Miért nem bizonyíték a phpinfo a PHP2Shell ellen
Sokan éppen azért hozták létre a fájlt, hogy ellenőrizzék a javítottsági állapotot. Erre azonban csak korlátozottan alkalmas. A disztribúciók és a tárhelyszolgáltatók a javításokat gyakran backportként telepítik; beszámolók szerint például az Ubuntu 24.04 a frissítés után is továbbra is 8.3.6-ot mutat. A megjelenített szám tehát keveset mond. Fordítva, egy aktuális szám nem bizonyítja, hogy az összes workert újraindították.
Terhelhető a csomagállapot a changelogban szereplő CVE-számokkal, kiegészítve az összes PHP-folyamat újraindításával. Hogyan megy ez, azt a A PHP-verzió és a javítottsági állapot helyes ellenőrzése cikk magyarázza el.
Egy rövid ideig tartó kimenet a webes környezetben ennek ellenére helyénvaló: megmutatja, mely php.ini és mely értékek érvényesek ténylegesen a weboldalra, mert a parancssor gyakran más konfigurációt olvas. A szintek és az elsőbbség hátterét a A php.ini magyarázata írja le. Ha erre szüksége van, akkor hozzáférés-védelemmel, véletlenszerű fájlnévvel és csak percekre.
A legtöbb kérdésre amúgy is vannak jobb utak. Egy FPM-pool PHP-verziója a konfigurációjában és a folyamatlistában áll. Egyes értékek a webrooton kívüli szkripttel lekérdezhetők az ini_get() segítségével, anélkül hogy mindent felfednének. A tárhelypaneleken pedig a felület megjeleníti a weboldalanként hozzárendelt verziót, igaz, a backportokról nem mond semmit.
Elfelejtett fájlok megtalálása: konkrét ellenőrzési lépések
Így deríti fel a régi maradványokat egy Linux-szerveren. A parancsok csak olvasnak, és nem módosítanak semmit.
- Phpinfo-hívást tartalmazó fájlok keresése (az útvonalat igazítsa):
grep -rlE "phpinfo[[:space:]]*\(" /var/www --include="*.php" 2>/dev/null
- A tipikus fájlnevek ellenőrzése, a tartalmi találat nélkül is:
find /var/www -type f \( -iname "info.php" -o -iname "phpinfo.php" -o -iname "test.php" -o -iname "i.php" \) 2>/dev/null
-
A találatok értékelése: nem minden lelet tesztfájl. Admin-eszközök, panelek vagy keretrendszerek használhatják a
phpinfo()-t bejelentkezés mögött. Az a döntő, hogy a fájl bejelentkezés nélkül elérhető-e az internetről. -
A hozzáférések megnézése a logban, mielőtt töröl:
grep -E "GET /(info|phpinfo|test|i)\.php" /var/log/nginx/access.log* 2>/dev/null | tail -n 50
- Törlés és a titkok cseréje: ha a kimenetben jelszó vagy kulcs állt, és a fájl nyilvános volt, az érték ismertnek számít. Változtassa meg.
Egy ismeretlen létrehozási dátumú lelet, amelyben a phpinfo-hívás mellett feltűnő tartalom is van, hátsó ajtó is lehet. Ilyenkor ne csak törölje, hanem mentse el és vizsgáltassa meg, lásd Webshellek felismerése és eltávolítása.
Tartós megelőzés takarítás helyett
Három intézkedés gondoskodik arról, hogy a téma ne térjen vissza. Először: a phpinfo-t felvenni a webes környezet php.ini fájljának disable_functions listájába. Előtte ellenőrizze, hogy a panelje nem igényli-e a függvényt egy státuszoldalhoz. Hogyan hat a beállítás, és hol vannak a határai, azt a A disable_functions helyes használata írja le.
; php.ini FPM-hez vagy Apache-hoz, utána az összes PHP-folyamatot újraindítani
disable_functions = phpinfo
expose_php = Off
Másodszor: a kitelepítés csak rögzített folyamaton keresztül történjen, például Gittel vagy build-pipeline-nal, hogy egyes fájlok ne kerüljenek kézzel a webrootba. Harmadszor: az állapotinformációk a monitoringba vagy a leltárba valók, nem egy nyilvános oldalra.
Az expose_php = Off ezenkívül eltávolítja azt a fejlécet, amellyel a PHP minden válaszban közli a verzióját. Ez nem helyettesíti a frissítést, de elvesz az automatizált szkennerektől egy kényelmes információt. Aki több embernek ad szerverhozzáférést, egyszerű szabályt is megállapodhat: a tesztfájlokat ugyanabban a munkalépésben törlik, amelyben létrehozták őket, és nem „később”.
Hogyan segít konkrétan a PHP SOS?
- Átvizsgáljuk a webrootjait phpinfo-fájlok, tesztszkriptek és más régi maradványok után, és minden leletet értékelünk.
- Kiértékeljük a talált fájlok elérését, és megmondjuk, mely titkokat érdemes kicserélnie.
- A PHP2Shell elleni javítottsági állapotot a csomag changelogjával és a folyamatindítással igazoljuk, nem egy verziókijelzéssel.
- A
disable_functions, azexpose_phpés további keményítések tartós beállítását a szerverkeményítés keretében végezzük.
Összegzés: Egy phpinfo-fájl másodpercek alatt létrejön, és ugyanilyen gyorsan elfelejtik. Aki most megkeresi és eltávolítja, lezár egy felesleges adatszivárgást, és a javítottsági állapotnál terhelhető bizonyítékokra támaszkodik.
Gyakori kérdések
Önmagában biztonsági rés egy phpinfo-fájl?
Nem nyit hozzáférést, de a támadóknak részletes leírást ad a szerverről: verzió, modulok, útvonalak, beállítások, és a környezettől függően környezeti változók is. Ez megkönnyíti a célzott támadásokat, és hozzáférési adatokat fedhet fel.
Bizonyítja a phpinfo verziószáma, hogy a PHP2Shell javítva van?
Nem. A disztribúciók és a tárhelyszolgáltatók a javításokat gyakran backportként telepítik, a megjelenített szám ilyenkor ugyanaz marad. A javítottsági állapotot a csomag changelogja és a szolgáltató megerősítése igazolja, továbbá az összes PHP-folyamat újraindítása.
Mit tegyek, ha egy phpinfo-fájl hosszabb ideig nyilvános volt?
Törölje a fájlt, az access logban nézze meg, ki kérte le, és cserélje ki az összes titkot, amely a kimenetben állt, például adatbázis-jelszavakat vagy környezeti változókból származó API-kulcsokat.
Teljesen kikapcsolhatom a phpinfo()-t?
Igen, a webes környezet php.ini fájljában a disable_functions segítségével. Előtte ellenőrizze, hogy egy panel vagy egy alkalmazás használja-e a függvényt státuszoldalakhoz, és utána indítsa újra a PHP-folyamatokat.